Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。3,700件66Dockerfileで実行できるコマンド数を減らす方法に関して、なにか知ってれば教えて下さい。16:02dockerにはレイヤー数が127までと制限されており、何も考えずに、ミドルのインストールからアプリ(rails等)のインストールまで行うと超えてしまったりするので、なるべくコマンド数を減らしたいという次第です。加えて、なるべく綺麗に書きたいという意図も含まれてます。質問を投稿した後にも編集して補足情報を追加できます。下のコメントで書かれてる具体的な構成など、これから質問を見て回答を考える人にも情報共有しておきたいようなことがある場合に便利です。Imagesこのページでまとめられているのが有力なものです。以下では、これに加えて私がイメージを作る際に周囲からもらったアドバイスや試してみたことなども含めて書いてみます。可能な限り、必要最小限のサイズのイメージからスタートする上記ページにも記載があるように、例えばUbuntuよりもDebianを使います。私の場合は趣味的にはUbuntuが好きなのですが、配布用のDockerイメージはDebianのwheezyベースなどで作っています。上記ページにもあるように、これだけで100MBぐらい違ったりします。RUNでのコマンドをチェーンさせてステージ数を減らすtorusさんの回答にあるものです。DockerではRUNの単位でファイルシステムの更新をおこなうので、仮にあるステージで大きなファイルを追加、その後のステージで当該ファイルを削除しても容量は食いっぱなしとなります。install、その後にソース一式を削除するところまでをひとつにチェーンさせることで容量削減できました。installしたままソースコードを残していたことがありました。これは、ソースを残しておいたほうが何かといじりやすいと考えての対応でした。cloneしていました。これは様々な実験をおこなう際には便利ですし開発環境のDockerイメージを提供しようという際には良いのです。バイナリ配布でサクッと導入してもらえるようなイメージの構築においてはただの無駄ということで納得しました。installが終わったら消しましょう。ソースが本当に必要な人は、Dockerfileをforkして自前でなんとかしてくれます多分。cloneしないもっと言うと、不要ならgitコマンドをインストールしない(いくらgitのない世界が不安で仕方なくても)。これも私がとあるイメージを作成していた時にもらった指摘に関するものです。cloneしてくるのが普通だろうという開発脳なのですが、Dockerのイメージを作る際には「えっ、ほんとにgitいる?」と疑うのが肝心です。Debianでgit-coreパッケージをインストールするだけでも数十MBの追加容量が必要となるので、指定リリースの*.tar.gzファイルを拾ってきて展開すれば十分なケースではgitのインストールすら避けるのが良いでしょう。繰り返しとなりますが、チーム用などに開発用環境を用意する際は別です。事情がなければディストリビューションのバイナリ配布物を利用するソフトウェアパッケージのビルドには多くの追加パッケージが必要です。gcc、libstdc++6-dev、make、autotools、cmakeなどなど。build-essentialをえいやっと追加すると一気にディスク容量が膨らみます。いうわけで、もし特殊な事情がなければ、なるべくディストリビューションの提供するバイナリ配布物を使うようにDockerfileを記述すべきです。ディストリビューションの公式パッケージに入っていないものやバージョンが古いもの・互換性のないものなどについては仕方ありません。追加容量が最小限で済むように留意しつつ、パッケージをインストールしましょう。process)で紹介されていました。これもDockerの構造がステージごとにファイルシステム状態を記録することに関連します。このblogでは、特定ディレクトリへのchownをビルドフェーズでおこなったところ、72MBもの容量増につながったという話が紹介されています。代替策として、chownをCOMMANDでの起動シーケンスへと移動したということです。ONBUILDを利用して一部処理をイメージ実行時へ逃がす利用できるシーンが一定限られますが、例えば「あるシステムの実行のために大量の静的ファイル(しかもそれなりに頻繁な更新がおこなわれる)を拾ってくる必要がある」といった場合に有効です。Hubでのビルドをおこなうのはあまり効率的と言えません。そこで用意されているのがONBUILDコマンドです。RUNコマンドがイメージ生成時に実行されるコマンドであるのに対して、ONBUILDコマンド(マニュアル)は当該処理をコンテナ生成時まで後回しするものです。既存の巨大イメージをダイエットする基本的にはDockerfileを編集してイメージ作り工程を改善するお話ですが、仮にDockerfileへアクセスできなくてもとれる策がこれです(これも上記ページで紹介されています)。name>で、イメージのビルド時にステージごとに生成されたレイヤがごっそり統合されます。結果として、ベースイメージからの差分保持すらされなくなるため、場合によっては当該イメージ単体のサイズは増えるかもしれません。他方、パフォーマンス面では実行時にアクセスするfsレイヤを減らせるのでファイルI/O面は多少有利になるかもしれません。メリットとデメリットを把握して利用する必要のある策です。個の銅バッジ1ビルドツール群まで削除対象にするという発想は、まさに目からウロコでした。バイナリから確保すればたしかに必要でなくなりますね。加えて、chownをすると容量増に繋がるというのは結構衝撃的ですね。ONBUILDで逃がせるものは逃がしてみたいと思います。cleanをするといいという記事をどこかでみました。自分用メモという意味も含め、書き残しておきます。コンテナを節約する有効手段は、シェルスクリプトにまとめるというのが正攻法なんですかね。自分は、これ以外思いつかなかったです。動作に不要な.dockerignoreでnode_modulesや.gitをコンテナ内にコピーしないようにする必要があります。--depth=1をしたとしても.gitにかなりの容量を食われていたりします。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。