Docker レイヤーキャッシュ

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

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

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

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 デーモンにロードします。

レイヤーキャッシュにどれだけの価値があるか: 実例#

実測のベンチマークではなく、説明用の数字です。キャッシュなしで約 8 分かかるマルチステージの Node.js イメージを考えてみましょう: ベースイメージ、システムパッケージ、依存関係のインストール、コンパイル、アセンブルという構成です。レイヤーキャッシュがあれば、ソースのみの変更は最後のレイヤーだけを無効化します。それより上のすべてはレジストリキャッシュからプルされ、再ビルドは 1 分から 2 分の範囲 に収まります。依存関係のステージに触れるコミットはより多くのレイヤーを無効化してより多くを再ビルドするため、効果は、典型的な変更が Dockerfile のどれだけを手つかずのまま残すかに応じて変わります。デフォルトの cache-mode: max は、中間ステージのレイヤーもキャッシュされるため、ビルド後のより大きなキャッシュプッシュと引き換えに、まさにこうしたマルチステージ再ビルドでのヒット率を高めます。

入力と出力#

どのランナーでも安全#

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