ある企業は AWS CodeBuild で複数のマイクロサービスのコンテナイメージをビルドし、ECR へプッシュしています。各 Dockerfile は OS パッケージや言語ランタイムの導入など変化の少ないレイヤーを多

Question

ある企業は AWS CodeBuild で複数のマイクロサービスのコンテナイメージをビルドし、ECR へプッシュしています。各 Dockerfile は OS パッケージや言語ランタイムの導入など変化の少ないレイヤーを多数含みますが、ビルドは on-demand のコンピューティングで実行され、毎回すべてのレイヤーを再構築するため 1 ビルドあたり 12 分以上かかっています。チームは buildspec やビルド環境の大きな書き換えを避けつつ、連続するビルド間で変化のない Docker レイヤーを再利用してビルド時間を短縮したいと考えています。最も適切な構成はどれですか。

Accepted Answer

正解: キャッシュタイプにローカルキャッシュを選択し、キャッシュモードに DOCKER_LAYER_CACHE を指定したうえでプロジェクトの特権モード（privileged）を有効化する。CodeBuild のローカルキャッシュには複数のモードがあり、Docker のビルドレイヤーをキャッシュするには DOCKER_LAYER_CACHE モードを使う。このモードは Docker デーモンが管理するレイヤーをビルドホスト上に保持し、後続ビルドで再利用するため、変化のないレイヤーの再構築を省略できる。ただしレイヤーキャッシュの読み書きには Docker デーモンへの特権アクセスが必要なため、プロジェクトの特権モード（privileged）を有効化することが前提となる。buildspec の大きな改変も不要。

選択肢の S3 キャッシュは buildspec の cache.paths に列挙したファイル/ディレクトリのみを保存する仕組みで、Docker デーモンが内部管理するレイヤーストレージはパス列挙では確実に取り扱えない。
選択肢の SOURCE_CACHE はフルクローン時の Git メタデータをキャッシュするモードで、Docker レイヤーは対象外。
選択肢のコンピューティング拡張は CPU/メモリを増やすだけで、毎回全レイヤーを再構築する点は変わらない。

Answer

キャッシュタイプに S3 キャッシュを選択し、buildspec の cache.paths に Docker デーモンのレイヤー格納ディレクトリを列挙してビルド間で共有する — S3 キャッシュは buildspec の cache.paths に明示したファイルやディレクトリのみを S3 に保存・復元する仕組み。Docker デーモンが内部で管理するレイヤーストレージはパス列挙で確実に保存・復元できず、レイヤー再利用の目的には適さないため要件を満たさない。

Answer

キャッシュタイプにローカルキャッシュを選択し、キャッシュモードに SOURCE_CACHE を指定してソースと Docker レイヤーをまとめて再利用する — SOURCE_CACHE はローカルキャッシュのモードのひとつだが、フルクローン時の Git メタデータ（.git 配下）を再利用してソース取得を速くするためのもの。Docker のビルドレイヤーはキャッシュ対象外であり、レイヤー再構築時間の短縮にはつながらない。

Answer

コンピューティングタイプをより大きいインスタンスに変更し、ビルド内の並列度を上げてレイヤーの再構築を高速化する — コンピューティングタイプの拡張は CPU やメモリを増やして個々の処理を速くするだけで、変化のないレイヤーを再利用する仕組みではない。毎回すべてのレイヤーを再構築する点は変わらず、根本的なビルド時間短縮の要件を満たさない。

解説

解説