はじめに
この記事は、以下の記事の内容を参考に、Dokcerファイルを作成する際のベストプラクティスをまとめていますので、ご参考ください。
すべてを記載しているわけではなく、個人的に重要と思った項目を抜粋してますので、必要な方は原文をお読みください。
再ビルド時間を増やさない方法
開発時は、Dockerイメージをビルドして、コードを変更して再ビルドする際に、キャッシュを活用することが重要です。キャッシュを利用することで、必要のないビルドステップを再実行しないようにでき、ビルド時間の短縮を図れます。
ビルドステップの順番を工夫する
必要なものだけをコピーする
このビルドステップで必要なのは、ビルドされたapp.jarです。
そのため、COPY . /appでコピーすると不要なファイルまでコピーされ、
app.jar以外のファイルに変更があった場合、キャッシュが無効となってしまいます。
そのため、必要なファイルだけをコピーするようにします。
Dockerイメージサイズを削減する
Dockerイメージが小さいほど展開が早くなるため、Dockerイメージサイズの削減は重要な項目です。
不要な依存関係を削除する
不要な依存関係を削除し、デバッグツールをインストールしないでください。
必要に応じて、後でデバッグツールをいつでもインストールできます。
aptなどの特定のパッケージマネージャーは、パッケージが推奨するパッケージを自動的にインストールし、サイズを増加させます。Aptには–no-install-recommends フラグがあり、実際には必要のない依存関係がインストールされないようにします。必要な場合は、明示的に追加してください。
パッケージマネージャーキャッシュを削除する
パッケージマネージャーは独自のキャッシュを保持し、キャッシュがイメージに含まれる場合があります。キャッシュがイメージに含まれることで、Dockerイメージのサイズ増につながり、再ビルドに時間がかかる可能性があります。
これに対処する1つの方法は、パッケージをインストールしたのと同じRUN命令でキャッシュを削除することです。別のRUN命令で削除しても、イメージサイズは縮小されません。
保守性を高める
可能な場合は公式のイメージを使用する
公式イメージは、すべてのインストール手順が実行され、最適化されるため、メンテナンスに費やす時間を節約できます。
より具体的なタグを使用する
最新のタグを使用しないでください。
Docker Hubの公式イメージで常に利用できるという利便性があります。
しかし、時間の経過とともに破壊的な変更が発生する可能性があります。
キャッシュなしでDockerfileを再構築する時間間隔によっては、ビルドが失敗する場合があります。
そのため、より具体的なタグを使用してください。この場合、openjdkを使用しています。より多くのタグが利用できるので 、既存のすべてのタグをリストするそのイメージのDocker Hubドキュメントを確認して利用してください。
より最小の種類のイメージを探す
同一のバージョンのDockerイメージでも、タグが分けられている場合があります。
それぞれSDKが含まれていたり、違うディストリビューションのイメージがもとになっていたりとしますが、用途に応じて最小限の種類のイメージを探し、それを使用すると良いです。
再現性を高める
これまでのところ、上記のDockerfilesは、jarの成果物がホスト上に構築されていると想定しています。コンテナが提供する一貫した環境の利点を失うため、これは理想的ではありません。たとえば、Javaアプリケーションが特定のライブラリに依存している場合、アプリケーションが構築されているPCによっては、望ましくない矛盾が発生する可能性があります。
一貫した環境でソースからビルドする
ホストの環境に依存しないためにも、ソースコードをビルドする環境をDockerイメージ内に配置して、ソースコードをDockerイメージのビルド時に生成することで、Dockerのホスト環境に依存しないようにすることができます。
さいごに
Dockerfileのベストプラクティスについて解説しましたが、以下のDokcerのサイトにも記載がありますので参考にしてください。(こちらは日本語訳されています)
コメント