このページでは、Cloud Build でビルドを開始するために使用できるビルド構成ファイルを作成する方法について説明します。
ビルド構成ファイルでは、Cloud Build がタスクを実行するために必要なフィールドを定義します。gcloud コマンドライン ツールまたはビルドトリガーを使用してビルドを開始する場合、ビルド構成ファイルが必要です。ビルド構成ファイルは YAML または JSON 構文で記述します。
始める前に
ビルド構成ファイルに含めることができるフィールドの詳細については、ビルド構成の概要をご覧ください。
ビルド構成の作成
次の手順では、基本的なビルド構成ファイルを作成する方法について説明しています。ビルド構成ファイルの各フィールドで、実行するタスクの一部を定義します。ビルド構成ファイルの唯一の必須フィールドは、ステップの name フィールドです。それ以外のフィールドはすべて省略可能です。
YAML
ビルド構成ファイルを作成します。プロジェクトのルート ディレクトリに、
cloudbuild.yamlという名前のファイルを作成します。これが、Cloud Build の構成ファイルです。steps フィールドを追加します。ビルド構成ファイルの
stepsセクションには、Cloud Build で実行するビルドステップが含まれています。steps:最初のステップを追加します。
steps:で、nameフィールドを追加して、タスクを実行するコンテナ イメージを指すように指定します。Cloud Build とそのデベロッパー コミュニティは、一般的なツールと言語がインストールされたいくつかのコンテナ イメージを提供しています。このようなイメージ（クラウド ビルダーとも呼ばれます）のいずれか、または一般公開されているイメージをビルドステップで使用できます。ビルドステップで使用できるさまざまなタイプのコンテナ イメージについては、クラウド ビルダーをご覧ください。次のスニペットは、
dockerビルダーgcr.io/cloud-builders/dockerを含むビルドステップを示しています。これは、Docker を実行するコンテナ イメージです。steps: - name: 'gcr.io/cloud-builders/docker'ステップの引数を追加します。ステップの
argsフィールドには、引数のリストが入れられます。引数は、nameフィールドによって参照されるビルダーに渡されます。nameフィールドのビルダーにエントリポイントがある場合、リスト内のargsがそのエントリポイントへのアクセスに使用されます。nameフィールドのビルダーにエントリポイントがない場合、argsの最初の要素がエントリポイントとして使用されます。下記の例で、
buildは Docker クラウド ビルダーのエントリポイントです。-tは Docker タグです。us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-imageは Artifact Registry でビルドされるイメージの名前です。ビルドステップでは、プロジェクト ID のデフォルトの置換を使用するため、この値はビルド時に自動的に置換されます。.は、ソースコードの場所です。これは、ソースコードが現在の作業ディレクトリにあることを示します。steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-image', '.']
ステップを追加します。
nameフィールドを追加してクラウド ビルダーを指すように指定すると、ビルド構成ファイルに任意の数のビルドステップを追加できます。次のスニペットには、ビルド構成ファイルに対する 2 つのステップが含まれています。
- docker ビルドステップ。
docker pushコマンドを起動して、前のステップのイメージビルドを Artifact Registry に push します。 Artifact Registry のコンテナ イメージから Compute Engine インスタンスを作成する、
gcloudエントリポイントが指定された Google Cloud SDK コマンドのビルドステップ。Compute Engine ゾーンとリージョンを指定するenvフィールドが含まれています。- name: 'gcr.io/cloud-builders/docker' args: ['push', 'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-image'] - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk' entrypoint: 'gcloud' args: ['compute', 'instances', 'create-with-container', 'my-vm-name', '--container-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-image'] env: - 'CLOUDSDK_COMPUTE_REGION=us-central1' - 'CLOUDSDK_COMPUTE_ZONE=us-central1-a'
- docker ビルドステップ。
追加のビルド構成フィールドを含めます。
machineType、tags、timeoutなどのフィールドを追加すると、ビルドをさらに構成できます。ビルド構成ファイルに含めることができるフィールドの完全なリストについては、ビルド構成の概要をご覧ください。次の例では、
gcr.io/google.com/cloudsdktool/cloud-sdkビルドステップが 240 秒後にタイムアウトします。- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk' entrypoint: 'gcloud' timeout: 240s args: ['compute', 'instances', 'create-with-container', 'my-vm-name', '--container-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-image'] env: - 'CLOUDSDK_COMPUTE_REGION=us-central1' - 'CLOUDSDK_COMPUTE_ZONE=us-central1-a'基本的なビルド構成ファイルの完全版サンプルについては、次のスニペットをご覧ください。
この例では、コンテナ イメージが Artifact Registry に保存されます。ビルドでコンテナ以外のアーティファクトが生成された場合は、
artifactsフィールドを使用すると Cloud Storage に保存できます。この手順については、イメージとアーティファクトの保存をご覧ください。
JSON
ビルド構成ファイルを作成します。プロジェクトのルート ディレクトリに、
cloudbuild.jsonという名前のファイルを作成します。これが、Cloud Build の構成ファイルです。steps フィールドを追加します。ビルド構成ファイルの
stepsセクションには、Cloud Build で実行するビルドステップが含まれています。{ "steps": }最初のステップを追加します。
steps:で、nameフィールドを追加して、タスクを実行するコンテナ イメージを指すように指定します。Cloud Build とそのデベロッパー コミュニティは、一般的なツールと言語がインストールされたいくつかのコンテナ イメージを提供しています。このようなイメージ（クラウド ビルダーとも呼ばれます）のいずれか、または一般公開されているイメージをビルドステップで使用できます。ビルドステップで使用できるさまざまなタイプのコンテナ イメージについては、クラウド ビルダーをご覧ください。次のスニペットは、
dockerビルダーgcr.io/cloud-builders/dockerを含むビルドステップを示しています。これは、Docker を実行するコンテナ イメージです。{ "steps": [ { "name": "gcr.io/cloud-builders/docker" } ] }ステップの引数を追加します。ステップの
argsフィールドには、引数のリストが入れられます。引数は、nameフィールドによって参照されるビルダーに渡されます。nameフィールドのビルダーにエントリポイントがある場合、リスト内のargsがそのエントリポイントへのアクセスに使用されます。nameフィールドのビルダーにエントリポイントがない場合、argsの最初の要素がエントリポイントとして使用されます。下記の例で、
buildは Docker クラウド ビルダーのエントリポイントです。-tは Docker タグです。us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-imageは Artifact Registry でビルドされるイメージの名前です。ビルドステップでは、プロジェクト ID のデフォルトの置換を使用するため、この値はビルド時に自動的に置換されます。.は、ソースコードの場所です。これは、ソースコードが現在の作業ディレクトリにあることを示します。{ "steps": [ { "name": "gcr.io/cloud-builders/docker", "args": [ "build", "-t", "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage", "." ] } ] }
ステップを追加します。
nameフィールドを追加してクラウド ビルダーを指すように指定すると、ビルド構成ファイルに任意の数のビルドステップを追加できます。次のスニペットには、ビルド構成ファイルに対する 2 つのステップが含まれています。
- docker ビルドステップ。
docker pushコマンドを起動して、前のステップのイメージビルドを Artifact Registry に push します。 Artifact Registry のコンテナ イメージから Compute Engine インスタンスを作成する、
gcloudエントリポイントが指定された Google Cloud SDK コマンドのビルドステップ。Compute Engine ゾーンとリージョンを指定するenvフィールドが含まれています。{ "name": "gcr.io/cloud-builders/docker", "args": [ "push", "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage" ] }, { "name": "gcr.io/google.com/cloudsdktool/cloud-sdk", "entrypoint": "gcloud", "args": [ "compute", "instances", "create-with-container", "my-vm-name", "--container-image", "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage" ], "env": [ "CLOUDSDK_COMPUTE_REGION=us-central1", "CLOUDSDK_COMPUTE_ZONE=us-central1-a" ] }
- docker ビルドステップ。
追加のビルド構成フィールドを含めます。
machineType、tags、timeoutなどのフィールドを追加すると、ビルドをさらに構成できます。ビルド構成ファイルに含めることができるフィールドの完全なリストについては、ビルド構成の概要をご覧ください。次の例では、
gcr.io/google.com/cloudsdktool/cloud-sdkビルドステップが 240 秒後にタイムアウトします。{ "name": "gcr.io/google.com/cloudsdktool/cloud-sdk", "entrypoint": "gcloud", "timeout": "240s", "args": [ "compute", "instances", "create-with-container", "my-vm-name", "--container-image", "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage" ], "env": [ "CLOUDSDK_COMPUTE_REGION=us-central1", "CLOUDSDK_COMPUTE_ZONE=us-central1-a" ] }基本的なビルド構成ファイルの完全版サンプルについては、次のスニペットをご覧ください。
この例では、コンテナ イメージが Artifact Registry に保存されます。ビルドでコンテナ以外のアーティファクトが生成された場合は、
artifactsフィールドを使用すると Cloud Storage に保存できます。この手順については、イメージとアーティファクトの保存をご覧ください。
次のステップ
- ビルドを手動で実行する方法とビルド構成ファイルでトリガーを使用して実行する方法を学習する。
- 依存関係を含めて、アーティファクトをビルド、テスト、デプロイするためのビルド構成を作成する方法を学習する。