ビルドを高速化する際のおすすめの方法

このページでは、Cloud Build ビルドを高速化する際のおすすめの方法について説明します。

よりスリムなコンテナのビルド

アプリケーションをコンテナ化する際に、ビルド時の依存関係や中間ファイルといった、ランタイムに不要なファイルが誤ってコンテナ イメージに含まれることがあります。こうした不要なファイルによってコンテナ イメージのサイズが拡大し、コンテナ イメージ レジストリとコンテナのランタイムとの間でイメージを移動するときに余計な時間と費用がかかる可能性があります。

コンテナ イメージのサイズを小さくするには、アプリケーションのビルドをビルド用のツールとともに、ランタイム コンテナの組み立てから分離します。

詳しくは、よりスリムなコンテナのビルドをご覧ください。

Kaniko キャッシュの使用

Kaniko キャッシュは、Cloud Build の機能の 1 つであり、コンテナビルドのアーティファクトをキャッシュに保存します。キャッシュ保存の際は、コンテナ イメージ レジストリ(Google 独自の Container Registry など)内に中間レイヤが保存され、インデックス付けされます。レジストリ内のレイヤは、以降のビルドに利用できます。詳しくは、Kaniko キャッシュの使用をご覧ください。

キャッシュされた Docker イメージの使用

Docker イメージビルドの速度を上げる最も簡単な方法は、後続のビルドに使用できるようにキャッシュ イメージを指定することです。ビルド構成ファイルに --cache-from 引数を追加すると、キャッシュされたイメージを指定できます。これにより、Docker はこのイメージをキャッシュソースとしてビルドします。

Docker イメージは、スタックレイヤから構成されています。--cache-from を使用すると、ビルドの最後になるまで、変更されたレイヤからすべてのレイヤが再構築されます。したがって、Docker ビルドの初期段階でレイヤを変更する場合には、--cache-from の使用は得策ではありません。

ビルドに --cache-from を常に使用することをおすすめしますが、次の点に注意してください。

  • キャッシュから取得するには、以前にビルドした Docker イメージが必要です。
  • --cache-from は Docker ビルドにのみ使用できます。他の種類のアーティファクトを作成するビルダーには使用できません。
  • キャッシュされたイメージはレジストリから取得する必要があります。このため、ビルドにかかる時間が長くなることがあります。

次の例では、以前にキャッシュされたイメージを使用してビルドする方法を説明します。

YAML

  1. ビルド構成に、次の処理を追加します。

    • キャッシュされたイメージを Container Registry から pull します。下記の docker pull ビルドステップでは、entrypointbash に設定し、コマンドの実行で返されるエラーを無視できるようにしています。初めてイメージをビルドする際は、docker pull で pull できる既存のイメージがないため、このように設定する必要があります。
    • 再ビルドでイメージを使用できるように --cache-from 引数を追加します。

      steps:
       - name: 'gcr.io/cloud-builders/docker'
         entrypoint: 'bash'
         args:
         - '-c'
         - |
           docker pull gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest || exit 0
      - name: 'gcr.io/cloud-builders/docker'
        args: [
                  'build',
                  '-t', 'gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest',
                  '--cache-from', 'gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest',
                  '.'
              ]
      images: ['gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest']
      

      [IMAGE_NAME] はイメージの名前です。

  2. 上記のビルド構成でイメージをビルドします。

    gcloud builds submit --config cloudbuild.yaml .
    

JSON

  1. ビルド構成に、次の処理を追加します。

    • キャッシュされたイメージを Container Registry から pull します。下記の docker pull ビルドステップでは、entrypointbash に設定し、コマンドの実行で返されるエラーを無視できるようにしています。初めてイメージをビルドする際は、docker pull で pull できる既存のイメージがないため、このように設定する必要があります。
    • 再ビルドでイメージを使用できるように --cache-from 引数を追加します。

      {
          "steps": [
          {
              "name": "gcr.io/cloud-builders/docker",
              "entrypoint": "bash",
              "args": ["-c", "docker pull gcr.io/$PROJECT_ID/quickstart-image:latest || exit 0"]
          },
          {
              "name": "gcr.io/cloud-builders/docker",
              "args": [
                  "build",
                  "-t",
                  "gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest",
                  "--cache-from",
                  "gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest",
                  "."
              ]
          }
          ],
          "images": ["gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest"]
      }
      

      [IMAGE_NAME] はイメージの名前です。

  2. 上記のビルド構成でイメージをビルドします。

    gcloud builds submit --config cloudbuild.json .
    

Google Cloud Storage でのディレクトリのキャッシュ

ビルドの速度を上げるには、以前のビルドの結果を再利用します。以前のビルドの結果を Google Cloud Storage バケットにコピーし、その結果から計算を行い、新しい結果をコピーしてバケットに戻すことができます。ビルドに時間がかかるときに、生成されるファイル数が少なく、Google Cloud Storage とのコピーに時間がかからない場合は、この方法を使用します。

Docker ビルド専用の --cache-from とは異なり、Google Cloud Storage のキャッシュは、Cloud Build でサポートされているすべてのビルダーで使用できます。

Google Cloud Storage を使用してディレクトリをキャッシュするには、次の手順を行います。

YAML

  1. ビルド構成ファイルに、次の処理を追加します。

    • Google Cloud Storage バケットから前のビルドの結果をコピーします。
    • 現在のビルドの結果を使用します。
    • 新しい結果をバケットにコピーします。

      steps:
      - name: gcr.io/cloud-builders/gsutil
        args: ['cp', 'gs://mybucket/results.zip', 'previous_results.zip']
      # operations that use previous_results.zip and produce new_results.zip
      - name: gcr.io/cloud-builders/gsutil
        args: ['cp', 'new_results.zip', 'gs://mybucket/results.zip']
      
  2. 上記のビルド構成を使用して、コードをビルドします。

    gcloud builds submit --config cloudbuild.yaml .
    

JSON

  1. ビルド構成ファイルに、次の処理を追加します。

    • Google Cloud Storage バケットから前のビルドの結果をコピーします。
    • 現在のビルドの結果を使用します。
    • 新しい結果をバケットにコピーします。

      {
          "steps": [
          {
              "name": "gcr.io/cloud-builders/gsutil",
              "args": ["cp", "gs://mybucket/results.zip", "previous_results.zip"]
          },
          {
              // operations that use previous_results.zip and produce new_results.zip
          },
          {
              "name": "gcr.io/cloud-builders/gsutil",
              "args": ["cp", "new_results.zip", "gs://mybucket/results.zip"]
          }
          ]
      }
      
  2. 上記のビルド構成を使用して、コードをビルドします。

    gcloud builds submit --config cloudbuild.json .
    

カスタム仮想マシンサイズを使用する

Cloud Build では、標準のマシンタイプ以外にも、2 つの高 CPU 仮想マシンタイプでビルドを実行できます。ビルドの速度を上げるには、CPU の性能が高い仮想マシンを選択します。高 CPU マシンを要求すると、Cloud Build はオンデマンドでしかこれらのマシンを起動しないので、ビルドの起動時間が長くなる可能性があります。

カスタム ディスクサイズの選択については、diskSize をご覧ください。

次の例では、ビルドにカスタム VM サイズを指定する方法を説明します。

gcloud

カスタム VM サイズを指定するには、--machine-type 引数を使用します。

gcloud builds submit --config=cloudbuild.yaml \
    --machine-type=n1-highcpu-8 .

YAML

  1. ビルド構成ファイルに VM サイズを指定します。

    steps:
    - name: 'gcr.io/cloud-builders/docker'
      args: ['build', '-t', 'gcr.io/my-project/image1', '.']
      # operations that take a long time to build
    - name: 'gcr.io/cloud-builders/docker'
      args: ['build', '-t', 'gcr.io/my-project/image2', '.']
    options:
      machineType: 'N1_HIGHCPU_8'
    
  2. 上記のビルド構成でビルドします。

    gcloud builds submit --config cloudbuild.yaml .
    

JSON

  1. ビルド構成ファイルに VM サイズを指定します。

    {
        "steps": [
        {
            "name": "gcr.io/cloud-builders/docker",
            "args": ["build", "-t", "gcr.io/my-project/image1", "."]
        },
        // operations that take a long time to build
        {
            "name": "gcr.io/cloud-builders/docker",
            "args": ["build", "-t", "gcr.io/my-project/image2", "."]
        }
        ],
        "options": {
            "machineType": "N1_HIGHCPU_8"
        }
    }
    
  2. 上記のビルド構成でビルドします。

    gcloud builds submit --config cloudbuild.json .
    

不要なファイルのアップロードの回避

ビルドがトリガーされると、Cloud Build で使用するためにコードのディレクトリがアップロードされます。

アップロード時間を最適化するには、.gcloudignore ファイルを使用して、ビルドに不要なファイルを除外します。

たとえば、一般に次のファイルは除外します。

  • プロジェクト デベロッパー用のドキュメントとサンプルコード
  • 生成されたスキャフォールディング コード、バイナリ、*.jar ファイルや、開発で使用したコンパイル済みウェブアセット
  • ローカル開発用に組み込まれたサードパーティの依存関係

これらのファイルの除外に対応する .gcloudignore ファイルを準備するには、プロジェクト ルートにファイルを作成し、次の内容を含めます。

.git
dist
node_modules
vendor
*.jar

コンパイル済みコードとサードパーティの依存関係を除外すると、より一貫したビルドプロセスになります。さらに、まだ開発中のコードを誤ってデプロイするリスクも軽減されます。

フィードバックを送信...