おなじみの画像 JavaやScalaといったJVM言語のDockerイメージは、JVMを同梱しなければならない都合で肥大化しがちである。特に何もしなくても、例えば一般的なamazoncorretto:21のイメージサイズは217.7 MBもある。 hub.docker.com これにさらにビルド済みのJARファイルが載ってくるので、結構大きくなってしまうのだ。 そこで、Scalaのコンテナイメージのサイズをなんとか小さくできないかと、考えた。すると、JVMを使ったまま70 MiBくらいに縮めることができた。 github.com コンテナイメージのサイズを小さくするために、何をしたかを書いていく。ちなみに題材としたアプリケーションはちょっとしたHello, Worldをするだけのもので、ライブラリはCatsに依存させた。 JVM使う編 マルチステージビルドを行う Alpineなどの軽量ラン
はじめに やめろ、ではなく、やめたほうがいい。です。自分のユースケースに合ってるか今一度確認することを推奨します。基本的にはAlpineは避けたほうが良い、というのが2021年時点での私の認識です。 なんで？ libcに一般的な互換性が不足しているからです。Ruby、Python、Node.jsなどでNativeモジュールをバンドルしているアプリケーションの場合、パフォーマンスの劣化や互換性の問題にぶち当たる場合があります。 superuser.com あとは他のベースイメージの軽量化もそれなりに進んできていて、Alpineが定番軽量イメージと言う認識は2018年頃には消えつつあったかなという認識でいます。 どうすりゃええねん ※Debian Slimがあるやんってツッコミ結構もらったんですが、Slimは当たり前過ぎてもう紹介しなくていいかなっていう甘えで省略していました。よろしくおねがい
なお、distrolessのイメージは2種類（3通りの名前）がありますが、Python 3.5はバグ修正はせず、セキュリティ修正のみでサポート期限が2020/9/13というステータスなので、本エントリーでは3.7の方のみを扱います。 gcr.io/distroless/python3: Python 3.5.3 gcr.io/distroless/python3-debian9: Python 3.5.3(上のイメージと同一) gcr.io/distroless/python3-debian10: Python 3.7.3 一応サンプル等もありますが、どれも1ファイルで構成されたサンプルスクリプトばかりです。前回のsite-packagesにコピーする方法を軽く試したところうまく動かず、シェルもpipもensurepipもないため、ビルドイメージにすることもできません。いろいろ調べた結果、
Introduction to Dockerizing for Production Improve your DevOps skills: learn an iterative process for Dockerizing your code. Get your free ebook Using Alpine can make Python Docker builds 50× slower by Itamar Turner-Trauring Last updated 21 Mar 2023, originally created 29 Jan 2020 When you’re choosing a base image for your Docker image, Alpine Linux is often recommended. Using Alpine, you’re told,
Golangはシングルバイナリ(単体で動く実行ファイル)を出力してくれてありがたいのですが、それをコンテナ向けの軽量LinuxであるalpineやBusyBoxを使って動かそうとすると、ハマることが多い。 シングルバイナリじゃなかったのか、と思ってしまうのだが、どうやらデフォルトで一部のライブラリがダイナミックリンクになっているからである。 このあたりが参考になった。 golangでビルドしたバイナリをスタティックリンク (static link)にする これ、割とググればいろいろ出てくるのですが結局のところイマイチ最適解が見つからない。 何故かっていうと、中身に入っているライブラリなどで割かしビルド条件を変える必要があるため。 また、コンテナのサイズも小さくしたいので、いろいろとオプションを調べて、自分はこんな感じで落ち着いた。 ※ちなみに今回想定しているシングルバイナリは、Golang
これからデータベースやストレージなどGo以外も使って開発していくので、そのまま自分のPC上にこれらの環境を構築していくのはいいものではありません。そこでDockerを使ってコンテナ上で開発をしていこうと思います。 今回のデータはgithubの07go_dockerにあります。 Dockerとは コンテナという技術を使って仮想環境を構築できるツールです。例えば私が使っているMacOS上にWindowsのソフトが使えるような場所を作成します。これが仮想環境です。 仮想環境といえばVMWareやVirtualBoxなどがありますが、それらと異なりゲストOSを挟まないので軽量に動作する利点があります。 私もここら辺は全然詳しくないのですが、Dockerは開発環境を持つコンテナを簡単に立ち上げたり潰したりできるので重宝しています。またいろいろなものがコンテナ内で閉じているので自分のPC環境を汚すこと
Multi-Stage Build docs.docker.com Docker の 17.05 (ce) から multi-stage build 機能が追加されました。 multi-stage build とは、ベースイメージを複数利用し、多段階で build を行う機能です。 利用シーンはビルド環境とランタイム環境の分離が挙げられます。 ビルド環境とランタイム環境を分けるとランタイムがネイティブである Go のような言語では Docker image を劇的に小さくすることができます。 golang の ベースイメージは 数百 MB ありますが、alpine のような 軽量 Linux イメージ単体では 数 MB のため、効果としては 90 % 以上のダイエットに繋がります。 Docker image サイズを小さくするメリットや、一般的なプラクティスについてはページ下部のリンクが非
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こちらはDjangoのチュートリアル「はじめての Django アプリ作成、その１」のPolls(投票)アプリを Amazon Web Service(AWS) の Elastic Container Service(ECS) へデプロイするサンプル（のようなもの）です。 nginx + uwsgi + python + django + MySQL DB という構成で docker-compose を使っています。 また、デプロイには AWS CLI と ECS CLI を使い AWSコンソールは(ほとんど)使いません。（E
前書き 以前「Common Lisp開発環境 on Docker - eshamster’s diary」で紹介した開発用環境とは別に、Common Lispを実行するためだけの環境を作ってみました*1。が、手元でdocker imagesを見ると800MB、Docker Hubで見ても212MBと巨大でした。これをベースにいくつもコンテナ起こすには辛いサイズだろう…と思い、軽量化を試みました。 CentOSをやめて、ベースにもっと軽いOSを使おうと調べてみると、Alpine Linux（紹介記事：「Alpine Linux で Docker イメージを劇的に小さくする - Qiita」）というOSが軽さを武器にシェアを広げているようでした。ということで、そこにCommon Lisp実行用コンテナを乗せ換えてみましたという記事です。 Dockerコンテナ作成 目標 下記が入った状態にします
オフィシャルでない Alpine イメージを使うなら 上の表の通り、最近はオフィシャルでも Alpine 版があったりしますが なければ、サイズの小さなサードパーティ製でも全然よいと思います。 選ぶなら、最低限 Automated Build で作成されており Dockerfile から操作履歴が明瞭なもの4 がよさそうです。 ADD / COPY をしているものは GitHub に行けば中身を確かめることもできます。 もしくは、まるっとコピーして自分でイメージを作るのも手です。 アプリのベースイメージに Alpine いずれにせよ、特定 OS のシェルを直接叩くようなアプリでない限り、 Alpine はとてもいい選択肢と言えそうです。 Golang 製でもなければ5、Alpine でよさそう。 参考資料でサイバーエージェント山田さんが 書かれている ように 重いイメージはほんとにいいこと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
