Dockerリビルド時の効率改善

[m-pyon23]

概要(Overview・Refs Issue)

現行のDockerfileを用いてDockerイメージをビルドする場合、どれかファイルを1つ変更された状態だとcomposer installが再度実行されるため、再ビルドのコストが重い。

Dockerのキャッシュを意識した処理順序にすることで、再ビルド時にはcomposer.json及びcomposer.lockが変更された時以外はcomposer installをによるパッケージのダウンロード処理が行われないようにした(本PR作成者環境で80秒程度)

ビルド速度の変化

条件	初回ビルド速度	comoposer.* 以外変更時
変更前	211 s	112 s
変更後	227 s	34 s

• ※ 作成者環境での速度
• ※ 初回ビルドに関しては、所有者・パーミッション設定の処理が5~10秒程のコスト増となってしまっている
  • 28b85c5 を適用して再分析したところ、処理の変更による影響は2秒程度。ネットワーク環境などの影響による誤差にほうがはるかに大きい

方針(Policy)

• composer.json及びcomposer.lock以外の更新時はビルドキャッシュを利用するようにした
• 上記タイミング調整に伴うパーミッション・所有者設定手順を調整
• 本PRによる外部仕様の変更はなし

実装に関する補足(Appendix)

Dockerビルドのキャッシュについて

参考: https://blog.hanhans.net/2017/02/25/docker-cache-composer-install/

Dockerのビルドにおいては、主にCOPY,ADD句により渡されるファイルのチェックサムが異なる場合に、以降の処理はキャッシュを使用しないという性質がある。

現行ではCOPY句でプロジェクトフォルダ全体を転送した後にcomposer installを実行していたため、以降のキャッシュが一切効かないという状況。

本PRでは、composer installに必要なcomposer.jsonとcomposer.lock`のみ先にCOPY句で転送してパッケージのダウンロードを行い、その後に変更が大きいプロジェクトフォルダ全体をCOPY句で転送するようにしたことで、パッケージダウンロードまでのキャッシュが働くようにした。

composer dumpautoloadに関しては、ファイルが出そろったタイミングでの実行。

所有者の設定について

vendor以下のchmodについては、www-dataユーザでcomposer installを実行しているため所有者の変更必要なし。時間短縮のために除外

テスト（Test)

Dockerビルド関連のテスト

• docker build . が正常に完了すること

• ルート直下ファイル、app以下、src以下のファイルの変更時はcomposer installを含むステップにキャッシュが適用されること

• composer.json,composer.lockの変更時はcomposer installを含むステップにキャッシュが適用されず、再ダウンロードが発生すること

パーミッション・所有者関連の確認

• コンテナイメージの/var/www/html以下のファイル・ディレクトリ(vendor含む)の所有者がwww-dataのままであること
• コンテナイメージの/var/www/html以下のファイル・ディレクトリ(vendor含む)のパーミッションに差分がないこと

アプリ動作の確認

• トップページの表示確認

相談（Discussion）

• 初回ビルドが少し延びるのと、再ビルドが大幅に短縮されるのではどちらを取るべきか、若干迷います

• vendor以下に対してchmodを実行する必要があるか？(数秒の短縮は見込めると思います)

  • 実行する場合、vendor以下のディレクトリのパーミッションがdrwxr-sr-xになる(現行)
  • 実行しない場合、vendor以下のディレクトリのパーミッションがdrwxr-xr-xになる

マイナーバージョン互換性保持のための制限事項チェックリスト

• 既存機能の仕様変更
• フックポイントの呼び出しタイミングの変更
• フックポイントのパラメータの削除・データ型の変更
• twigファイルに渡しているパラメータの削除・データ型の変更
• Serviceクラスの公開関数の、引数の削除・データ型の変更
• 入出力ファイル(CSVなど)のフォーマット変更

レビュワー確認項目

• 動作確認
• コードレビュー
• E2E/Unit テスト確認(テストの追加・変更が必要かどうか)
• 互換性が保持されているか
• セキュリティ上の問題がないか

[nanasess]

以前の議論では、初回ビルドの速度を優先させようということになっています。

#4333 (comment)

(個人的には、リビルドが速い方が嬉しいですが)

[m-pyon23]

@nanasess

なるほど…完全に既出でした。見落としていました…ありがとうございます！！
初回ビルド速度を優先という方針について承知しました！

ただ一応今回に関しては/tmpフォルダではなく、/var/www/html/vendorに対してのインストールを直接行っているため、コピーの処理時間がありません。もう少し詰めたら初回ビルドの増加も解消できる気がしてきました。
(ちなみに私も最初は/tmpでやっていましたが、コピーに時間がかかって方針転換しました…)

↓↓

先にvendorディレクトリに対してchmod g+sを行っておけば、配下に対してchmodを改めて行う必要がない気がしてきました。これで初回ビルドの増加量を誤差レベルにできないか試してみます

[m-pyon23]

先にvendorディレクトリに対してchmod g+sを行っておけば、配下に対してchmodを改めて行う必要がない気がしてきました。これで初回ビルドの増加量を誤差レベルにできないか試してみます

適用してみました。これにより、chmod関連の処理増加量としては現行の2-3秒増し程度になっています。

全体ビルド処理時間

--no-cacheオプションを用いてビルドを5回行いました。

※FROM句はキャッシュされているため、それ以降のビルド処理

• 212 s
• 182 s
• 198 s
• 230 s
• 221 s

以上の通り、かなりブレのある結果になりました。
誤差の内訳はほぼaptやcomposer でのネットワーク環境が関わるものでした。

本PRの適用は処理パーツとしては2-3秒の増加が認められるものの、全体でみればそれ以外の環境要素が大部分を占める誤差レベルと考えています。

開発時のリビルドや、やや限定的ですがDockerのレイヤーキャッシュが効くCIサービス(セルフホストランナー、CycleCI、GCPのCloud Build等)に対してはかなり効率化が見込めるため、ご検討いただければと思います

[kiy0taka]

初回ビルド時間に影響がなく、リビルド時間が短縮されていることが確認できました。ありがとうございました。