Docker のビルド結果をキャッシュする¶
Docker のビルドキャッシュを別の実行環境でも再利用できるよう、buildxで保存先と読み込み元を指定します。保存先ごとの違いと、コンテナレジストリへキャッシュを保存するコマンドを紹介します。
この記事は、2023 年 5 月以前に調べた内容の記録です。バックエンドの対応状況と引用文は当時のもので、正確な調査日は記録していません。
キャッシュのバックエンド¶
キャッシュの保存先には複数のバックエンドが用意されています。主な選択肢は次のとおりです。
- inline: image エクスポーターの場合に、ビルドキャッシュをイメージ自体へ埋め込む
- registry: 専用の別イメージへキャッシュを書き出す
- local: ローカルディスクへキャッシュを書き出す
- gha(ベータ): GitHub Actions のキャッシュを使う
- s3(未リリース): AWS S3 を使う
- azblob(未リリース): Azure Blob Storage を使う
当時のDocker 公式ドキュメント(キャッシュストレージバックエンド)には、それぞれ次のように説明されていました。
- inline: embeds the build cache into the image.
The inline cache gets pushed to the same location as the main output result. Note that this only works for the image exporter.
- registry: embeds the build cache into a separate image, and pushes to a dedicated location separate from the main output.
- local: writes the build cache to a local directory on the filesystem.
- gha: uploads the build cache to GitHub Actions cache (beta).
- s3: uploads the build cache to an AWS S3 bucket (unreleased).
- azblob: uploads the build cache to Azure Blob Storage (unreleased).
レジストリへ保存するコマンド¶
Docker の registry キャッシュの設定例を基に、ビルドしたイメージとキャッシュを別のタグへ保存します。次の例では、書き込み権限があるコンテナレジストリへログイン済みで、buildxの builder が registry バックエンドを使える状態を前提とします。
ghcr.io/example/appは自分のイメージ名へ置き換えます。--cache-fromは前回のキャッシュの読み込み元、--cache-toは今回の保存先です。
mode=maxを指定すると、中間ステージのキャッシュも保存されます。初回は読み込み元のキャッシュがなくてもビルドはそのまま続き、2 回目以降は前回保存したキャッシュを再利用できます。
GitHub Actions での利用例¶
GitHub Actions で使う例はDocker 公式ドキュメントの GitHub Actions でのキャッシュ設定です。docker/build-push-action@v3でビルドしたイメージを後続のステップで使うにはoutputs: type=dockerを設定します。type=dockerを指定すると、ビルド結果をローカルのイメージストアへ読み込む分だけ build と push が遅くなります。後続のステップでビルドしたイメージを使わないなら、指定しない方がよいです。