Docker レイヤーキャッシュ

Latchkey Docker Cache Build は docker buildx をレジストリバックのレイヤーキャッシュでラップします。そのため、繰り返しのイメージビルドでは、エフェメラルなランナーをまたいで変更されていないすべてのレイヤーを再利用します。

すべての Latchkey ランナーは、新しく分離されたインスタンスです。これはセキュリティには良い一方、ランナーとともに消えてしまう Docker のローカルレイヤーキャッシュには不都合です。Latchkey Docker Cache Build は、Latchkey が組織向けに管理するプライベートコンテナレジストリに保存されたレイヤーキャッシュでこれを解決します。以前のビルドと一致するレイヤーが再利用され、更新されたキャッシュは次回の実行のために書き戻されます。

ワークフローに追加する#

.github/workflows/build.yml

jobs:
  build:
    runs-on: latchkey-medium
    steps:
      - uses: actions/checkout@v4
      - uses: latchkey-dev/docker-cache-action@v1
        with:
          context: .
          tags: myapp:latest
          push: true

これで統合は完了です。任意の Docker ビルドに渡すのと同じ入力を指定するだけで、Latchkey がレジストリ、認証情報、キャッシュの接続を処理します。デフォルトでは、この action は cache-mode: max を使用し、マルチステージビルドの中間レイヤーを含むすべてのレイヤーをキャッシュします。push: false の単一プラットフォームビルドでは、ビルドされたイメージをランナーのローカル Docker デーモンにロードします。

入力と出力#

入力	デフォルト	動作
`tags`	必須	ビルドされたイメージのタグ
`context`	`.`	ビルドコンテキストのパス
`dockerfile`	`Dockerfile`	Dockerfile へのパス
`push`	`false`	ビルドされたイメージをプッシュする
`build-args`	なし	ビルド引数。シークレットを含む可能性があるため、値はログでマスクされます
`target`	なし	マルチステージビルドのターゲットステージ
`platforms`	なし	ビルドのターゲットプラットフォーム
`cache-mode`	`max`	キャッシュのスコープ: `min` または `max` (max はマルチステージの中間レイヤーを含むすべてのレイヤーをキャッシュします)
`cache-tag`	`cache`	レイヤーキャッシュに使われるレジストリタグ
`extra-cache-from` / `extra-cache-to`	なし	ビルドに渡される追加のキャッシュソースおよびキャッシュ先

出力	意味
`cache-configured`	ビルドでレジストリレイヤーキャッシュが有効だった場合は `true`、それ以外は `false`
`image-digest`	ビルドされたイメージのダイジェスト

どのランナーでも安全#

Latchkey 以外のランナー (たとえば GitHub ホストランナー) では、action はキャッシュレジストリが利用できないことを検出し、キャッシュフラグなしで通常どおりビルドします。1 つのワークフローファイルがランナーの種類をまたいでポータブルなまま保たれます。
リポジトリの最初のビルドではキャッシュは空です。その最初の実行でキャッシュ付きビルドが失敗した場合、action は自動的にキャッシュなしで再試行します。最初の実行がキャッシュのせいで壊れることはありません。
build-arg の値はログでマスクされるため、ビルド引数として渡されたシークレットがジョブ出力に漏れることはありません。
キャッシュは組織ごとに分離されます。