Cloud Build

解決する課題

ソースコードからアーティファクトを作り、テストして本番へ届けるまでの一連の作業を、自前のビルドサーバーを運用せずに自動化できます。

• コードを push するたびにビルドとテストを自動実行し、品質を継続的に検証したい
• ビルドした成果物（コンテナイメージや成果ファイル）を Artifact Registry に保存し、Cloud Run / GKE へ自動デプロイしたい
• Jenkins などのビルドサーバーを自前で運用したくない（スケールやパッチ適用の手間を避けたい）
• ビルド処理ごとに異なるツール（言語ランタイム、CLI） を使い分けたい
• 誰がいつ何をビルド・デプロイしたかを監査ログとして残したい

主要概念と用語

• ビルド（build）: 1回の実行単位。ソースを取得し、定義した一連のステップを順に実行する処理全体
• ビルドステップ（build step）: パイプライン内の1つの工程。各ステップはコンテナイメージとして実行され、その中で任意のコマンドを動かす
• ビルダーイメージ（builder）: ステップの実行に使うコンテナイメージ。docker・gcloud・mvn・npm など Google 提供のものや任意の公開イメージを指定できる
• ビルド構成ファイル（cloudbuild.yaml）: ステップ・置換変数・成果物などを宣言的に記述する設定ファイル。Dockerfile だけでビルドする簡易方式も使える
• トリガー（trigger）: ソースリポジトリへの push やタグ作成などのイベントを起点にビルドを自動起動する仕組み
• 置換変数（substitution）: $PROJECT_ID や $COMMIT_SHA などビルド時に展開される変数。ユーザー定義変数も使える
• アーティファクト（artifacts）: ビルドの成果物。コンテナイメージは Artifact Registry、ファイルは Cloud Storage に保存できる
• サービスアカウント: ビルドが他サービスにアクセスする際の実行 ID。このアカウントの IAM 権限がビルドの権限になる

仕様・制限・クォータ

• ステップは既定で定義順に直列実行される。waitFor を指定すると依存関係を表現して並列実行できる
• ステップ間では作業ディレクトリ（既定で /workspace）が共有され、前のステップの成果物を次へ受け渡せる
• ビルドにはタイムアウトがあり、既定値を超える長時間ビルドには明示的な延長設定が必要
• 同時実行ビルド数やビルド時間などにクォータ/上限があり、必要に応じて引き上げ申請ができる
• ビルドを実行するマシンのスペック（vCPU/メモリ） を選択でき、重いビルドには高性能なマシンタイプを指定できる
• VPC 内の非公開リソースへアクセスするビルドはプライベートプール（private pool） を利用する

内部の仕組み

Cloud Build は、指定したソースを取得したうえで、ビルド構成に書かれた各ステップをコンテナとして順に起動するマネージドな実行基盤です。すべてのステップが同じ作業ディレクトリ /workspace を共有するため、チェックアウト・依存解決・コンパイル・テスト・イメージ作成・デプロイといった工程を1本のパイプラインとしてつなげられます。

• 各ステップは独立したコンテナなので、ステップごとに必要なツールだけを含むイメージを選べる（言語やバージョンの混在が容易）
• 既定では Google 管理のマネージドプールでビルドが実行される。VPC 内リソースへのアクセスが必要ならプライベートプールを使う
• 成果物のうちコンテナイメージは Artifact Registry、ファイルは Cloud Storage に保存するよう構成できる
• ビルドは指定したサービスアカウントの権限で動作し、デプロイ先（Cloud Run / GKE など）への操作はその IAM ロールで制御される

AWS でいえば、ビルド・テストの実行エンジン部分が AWS CodeBuild、トリガーからビルド・デプロイまでを段階的につなぐオーケストレーション部分が AWS CodePipeline に相当します。Cloud Build は両者の役割を1つのサービスで担う形に近く、ステップを並べることでパイプライン全体を表現します。

設計パターン / ベストプラクティス

• ビルド構成は cloudbuild.yaml としてリポジトリに置き、コードと一緒にバージョン管理する（パイプラインの再現性・レビュー性が上がる）
• ブランチやタグの push をトリガーに自動ビルドし、本番デプロイはタグやリリースブランチに限定する
• ビルドの実行サービスアカウントは最小権限にし、デプロイに必要なロールだけを付与する
• 環境差分（プロジェクト ID・リージョンなど）は置換変数で吸収し、同じ構成を複数環境で再利用する
• コンテナイメージはダイジェスト（sha256） で参照・デプロイし、再現性を担保する
• ビルドを高速化したいときはキャッシュ（依存物や中間イメージ）の活用とステップの並列化（waitFor） を検討する
• VPC 内の DB やプライベートな依存リポジトリにアクセスするビルドはプライベートプールを使う

運用・監視

• ビルドのログは Cloud Logging に出力され、コンソールや CLI から実行履歴・失敗箇所を追える
• Cloud Audit Logs で誰がビルドを起動・設定変更したかを監査する
• ビルド結果は Pub/Sub 通知（cloud-builds トピック）で受け取り、Slack 連携や後続処理に使える
• よくある失敗は実行サービスアカウントの権限不足（デプロイ先やレジストリへのロール不足）とタイムアウト超過
• 長時間ビルドはタイムアウト延長やマシンタイプの引き上げ、ステップ並列化で対処する

コスト

主に「ビルドの実行時間」に対して、使用したマシンタイプ（vCPU/メモリ）の単価で課金されます。多くの場合、低スペックのマシンには無料枠の範囲があり、それを超えた分や高性能マシン・プライベートプールの利用に応じて費用が増えます。あわせて、成果物の保存先である Artifact Registry や Cloud Storage の保管費用も発生します。

セキュリティ

• ビルドはサービスアカウントの権限で動く。デプロイやレジストリ push に必要な最小限のロールだけを付与する
• トリガーやビルド構成の編集権限を絞り、本番デプロイにつながるパイプラインの変更を管理する
• ビルド構成内にシークレットを直書きしない。Secret Manager から実行時に読み込む方式を使う
• VPC 内の非公開リソースへアクセスする場合はプライベートプールで経路を閉じる
• ビルドしたイメージを脆弱性スキャンし、Binary Authorization と組み合わせて署名・検証済みイメージだけをデプロイするよう強制できる

Well-Architected の観点

• 運用上の優秀性: ビルド構成をコードとして管理し、トリガーでビルド・テスト・デプロイを自動化することで、手作業を排して再現性とリリース速度を高める。ログと監査でパイプラインの可観測性も確保できる
• セキュリティ: 実行サービスアカウントの最小権限、Secret Manager によるシークレット管理、脆弱性スキャンと Binary Authorization の連携により、ビルドからデプロイまでのサプライチェーンを保護する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# カレントディレクトリのソースを使い、構成ファイルでビルドを実行
gcloud builds submit --config=cloudbuild.yaml .

# 構成ファイルなしで Dockerfile から直接イメージをビルドして Artifact Registry へ push
gcloud builds submit \
  --tag=asia-northeast1-docker.pkg.dev/PROJECT_ID/my-repo/web:latest .

# main ブランチへの push を起点にビルドを自動起動するトリガーを作成
gcloud builds triggers create github \
  --name="web-on-push" \
  --repo-name="my-app" \
  --repo-owner="my-org" \
  --branch-pattern="^main$" \
  --build-config="cloudbuild.yaml"

# 直近のビルド一覧と、特定ビルドのログ確認
gcloud builds list --limit=5
gcloud builds log BUILD_ID