Google PCD: 継続的デリバリー、設定、インフラストラクチャの自動化 — 学習ガイド

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Developer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Cloudでの継続的デリバリーは、ビルドの自動化、アーティファクト管理、デプロイのオーケストレーション、Infrastructure as Code、および強力なガバナンスを統合し、変更を安全に繰り返し提供します。堅牢なパイプラインは、不変（イミュータブル）なアーティファクトと宣言的な構成を、ポリシーと監査可能性と組み合わせます。このセクションでは、Cloud Build、Cloud Deploy、Artifact Registry、Terraform、Kubernetes、フィーチャーフラグ、およびガバナンス制御をエンドツーエンドで実装する際の、設計上の選択肢、運用プラクティス、および一般的な障害モードについて説明します。

ビルドとデプロイのオーケストレーション

Cloud Build

トリガー: ビルドをソースイベント（ブランチのプッシュ、タグ、PR）またはスケジュールに接続します。意図したrefのみが起動するように、ブランチまたはタグの正規表現を使用することを推奨します。トリガーは、最小権限を強制するために特定のサービスアカウントとして実行できます。ビルドが広範なAPIアクセスを必要とする場合は、デフォルトに依存しないでください。
ビルドステップ: 各ステップはコンテナ内で実行されます。デフォルトのツールチェーンが不十分な場合は、専用ビルダー（docker、gcloud）またはカスタムビルダーを使用します。コンパイル、単体テスト、統合テスト、リント、セキュリティスキャン、アーティファクトのパッケージングのステップを分離し、障害の原因特定を容易にし、効果的にキャッシュされるようにします。
置換: パラメータ化されたビルドには、組み込み変数（PROJECT_ID、SHORT_SHA）とカスタム置換（$_で始まる）を使用します。環境固有の値はビルドロジックから分離し、置換として渡すか、デプロイ時に後で解決します。
サービスアカウント: Cloud Buildサービスアカウント（PROJECT_NUMBER@cloudbuild.gserviceaccount.com）には、明示的なロール（例: Artifact Registryへの書き込み、Cloud Deployのリリース管理者）が必要です。プロジェクトごとに最小限のロールとスコープを割り当てます。プライベートリソースには、VPC接続を持つプライベートプールを使用します。
アーティファクト: 不変なイメージをArtifact Registryに公開し、オプションでartifactsセクションを介してコンテナ以外のアーティファクトをCloud Storageにアップロードします。イメージにはセマンティックバージョンとコミットダイジェストの両方でタグを付けます。デプロイではイメージダイジェストを使用して、タグのドリフトを回避します。

Cloud Build構成の例:

cloudbuild.yaml: steps:
- name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
- name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
- name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com
トリガーの例: gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

デリバリーパイプラインは、順序付けられたステージとターゲットを定義します。ターゲットは、GKEクラスタ、Cloud Runサービス、またはその他のサポートされているランタイムを参照します。本番ステージにはrequireApprovalを設定して、プロモーションをゲート（制御）します。
ロールアウトはリリースをターゲットにマッピングし、プロモーションはリリースをターゲット間で進めます。プログレッシブデリバリー（カナリア、ブルー/グリーン）と、デプロイ前/デプロイ後のチェックのためのフックを使用します。
障害モード: 可変タグを使用すると意図しないアップグレードが発生するため、常にダイジェストを固定します。デプロイ担当アカウントのIAMが不足していると、ロールアウトがブロックされます。レンダリング不能なマニフェストや環境固有の構成ドリフトは、プロモーションの失敗につながります。ビルド中にマニフェストを検証してください。

Cloud Deploy定義の例:

delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:
- targetId: dev
- targetId: prod strategy: standard: verify: true requireApproval: true
targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER
本番ターゲットの定義
apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER
リリースとプロモーション: gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

アーティファクトとサプライチェーンの整合性

Artifact Registry

リポジトリ: IAMとクリーンアップのスコープを限定するために、チームまたは環境ごとに個別のリポジトリを作成します。ビルダーとランタイムの近くにあるリージョンリポジトリを使用して、下り（egress）とレイテンシを削減します。パッケージ形式には、Dockerイメージや言語パッケージ（Maven、npm、PyPI）が含まれます。
保持期間: 参照されていないタグや古いタグを削除するためのクリーンアップポリシーを定義し、ロールバックのための安全期間を確保します。最後の正常なバージョンを削除してしまうような、積極的すぎる保持ポリシーは避けてください。
来歴（Provenance）とSBOM: ビルドの来歴を有効にして、イメージがSLSA準拠の証明書を持つようにします。ビルド中にSBOMを生成し、証明書として保存することで、脆弱性のトリアージを改善します。
脆弱性スキャン: コンテナ分析を有効にし、利用可能な修正やポリシーの例外がない高深刻度のCVEが検出された場合に、ビルドを失敗させるかプロモーションをブロックします。
トレードオフ: すべてのアーティファクトを単一のプロジェクトに集約するとガバナンスは簡素化されますが、影響範囲（ブラスト半径）が大きくなる可能性があります。環境ごとまたはアプリケーションごとのリポジトリはリスクを低減しますが、管理オーバーヘッドが増加します。

サプライチェーンの強制

GKEのBinary Authorizationは、証明書（例: 「プロジェクトXのCloud Buildによってビルドされた」、「重大なCVEがない」）を要求できます。Cloud Deployのゲートと統合して、非準拠のリリースを停止します。
障害モード: 可変タグ、無効化されたスキャン、または認証されていないプルに依存すると、未検証のソフトウェアが本番環境に到達する可能性があります。ダイジェストを固定し、証明書を要求します。

コードとしてのインフラストラクチャと GitOps

Terraform

設定とモジュール: 明確な入力/出力とセマンティックバージョニングを持つ再利用可能なモジュールを切り出します。モジュールは共有リポジトリやレジストリで公開し、予期せぬ変更を避けるためにバージョンを固定します。
状態 (State): リモートステートには GCS バックエンドを使用し、バケットレベルの IAM、オブジェクトのバージョニング、CMEK を活用します。手動での編集からステートを保護し、ステートの暗号化を徹底します。適用時に Secret Manager から読み取ることでステートにシークレットが含まれるのを避け、データソースの使用は最小限に抑えます。

undefined

プランと適用 (Plan と Apply): terraform plan を -out 付きで実行し、人間または自動化されたゲートで差分をレビューします。適用は、事前に承認されたプランのみに対して行います。ドリフト検出ジョブでは -refresh-only または -detailed-exitcode を使用します。
環境の分離: 環境ごとに個別のプロジェクト、ステートバケット、サービスアカウントを使用します。複雑な組織では、ワークスペースよりも、変数ファイルを使用した環境ごとのディレクトリ構成を推奨します。環境間でステートを共有してはいけません。
障害モード: 同時適用はステートを破損させます。CI/CD とロック (GCS はオブジェクトの事前条件を使用) によって直列化を強制します。コンソールからの手動変更はドリフトを引き起こします。直接的な変更を制限し、定期的に plan ジョブを実行します。

Kubernetes の宣言的設定

マニフェスト: Kubernetes オブジェクトは宣言的に保ち、本番環境のフローでは kubectl の命令的なコマンドを避けます。イメージダイジェストとリソースの requests/limits を固定します。
Kustomize: base + overlays を使用して、チャートをフォークすることなく環境固有のパッチを扱います。 kustomization.yaml (オーバーレイ):

undefined

Helm: 環境ごとに values ファイルを使用し、優先順位 (コマンドラインの値が values ファイルを上書きし、values ファイルがチャートのデフォルトを上書きする) を文書化します。CI でテンプレート化とレンダリング (skaffold render または helm template) を行い、デプロイ時の設定が不変になるようにします。
GitOps: 望ましい状態を Git に保存します。Cloud Deploy または Config Sync を使用して、クラスターを Git の状態に一致させます。PR が、監査証跡とポリシーチェックを備えた変更管理のインターフェースとなります。Git でキャプチャされない kubectl exec による変更は避けます。

リリースの安全性、構成、ガバナンス

機能フラグとランタイム構成

機能フラグはデプロイとリリースを分離します。休眠状態のコードをシップし、コホート、パーセンテージ、またはリージョンごとに有効化します。フラグの定義は、低レイテンシで高可用性なシステム（Firestore, Memorystore）に保存し、短いTTLでキャッシュします。トレーサビリティのために評価をログに記録します。
段階的なロールアウト: トラフィックスプリッティング（Cloud Run）やカナリアサブセット（GKE）を機能フラグと組み合わせることで、影響範囲（ブラスト半径）を最小化します。健全性メトリクスとSLOベースの自動ロールバックトリガーを使用します。
安全なロールバック: 機能フラグによる迅速な無効化を推奨します。バイナリのロールバックには、最後の正常なリリースを昇格させるか、以前のマニフェストダイジェストを再適用します。

環境変数、優先順位、シークレット

優先順位は一般的に、ランタイムフラグ > 環境変数 > 構成ファイル > コードのデフォルト、の順に従います。これを文書化し、サービス間で標準化します。
ConfigMapsと環境変数で構成を注入します。機密性の高い値にはSecret ManagerまたはKubernetes Secretsを使用します。定期的にローテーションし、イメージにシークレットを焼き込むことは避けます。
シークレット注入の例:
- Cloud Run 環境変数:

undefined

GKE Secret Manager CSI:

undefined

CI/CDにおける品質ゲート

ユニットテストはコミットごとに実行します。迅速なフィードバックが最重要です。
インテグレーションテストは、データを投入した一時的な環境またはサンドボックスに対して実行します。
セキュリティチェック: SAST、依存関係スキャン、コンテナ脆弱性スキャン、IaCポリシーチェック（Conftest, Policy Controller）。重大な検出結果があった場合は、マージや昇格をブロックします。
デプロイメントチェック: Cloud Deployのpredeployおよびpostdeployアクションで、準備状況、データベースマイグレーションの安全性、スモークテストを検証します。

ブランチ戦略、コードレビュー、バージョニング、トレーサビリティ

短命なフィーチャーブランチと必須のPRレビューを伴うトランクベース開発を推奨します。監査可能性のために、必須のチェックとリニアな履歴を強制します。
バージョニング: リリースにはセマンティックバージョンのタグを使用し、不変性のためにイメージダイジェストとコミットSHAを使用します。本番環境のデプロイでは、latestのような移動するタグの使用を避けます。
トレーサビリティ: ビルドとリリースにコミット、PR、チケットIDをアノテーションとして付与します。デプロイイベントをLoggingに出力し、コストと所有者のためにリソースにラベルを付けます。

インフラストラクチャのドリフト、ポリシー、監査、変更管理

ドリフト検出: terraform plan -detailed-exitcodeをスケジュール実行し、ゼロ以外のコードでアラートを発生させます。クラスタについては、Config SyncがGitへの最終的な収束を保証します。
ポリシーの強制: ガードレールにはOrganization Policy（例: 外部IPの制限）、KRM制約にはPolicy Controller、イメージポリシーにはBinary Authorizationを使用します。
監査ログ: 管理アクティビティログとデータアクセスログを有効にし、コンプライアンスに合わせたシンクと保持期間を持つ中央集権的なプロジェクトにルーティングします。Cloud Asset Inventoryは、変更履歴とアクセス分析の情報を提供します。
変更管理: 本番環境への昇格には手動承認を必須とし、正当な理由をアノテーションとして記録します。フリーズ期間は、CI/CDのポリシーチェックとしてエンコードできます。緊急ロールバックの経路が文書化され、訓練されていることを確認します。

実践的な問題シナリオ

Acme Retail社は、安全なカナリアロールアウト、厳格なポリシー適用、完全なリリーストレーサビリティを備えた新しいorder-serviceを、dev環境とprod環境のGKEにデプロイする必要があります。チームは、Terraformで管理されるインフラストラクチャ、Kustomizeによる宣言的なKubernetes構成、そしてCloud BuildとCloud Deployを使用した監査可能なCI/CDを標準化しなければなりません。

アプローチ：

アーティファクトリポジトリとIDを確立する

リージョンArtifact Registryリポジトリorder-docker-devとorder-docker-prodを作成します。アプリプロジェクトのCloud Buildサービスアカウントに、適切なリポジトリに対するroles/artifactregistry.writerを、GKEランタイムノードにroles/artifactregistry.readerを付与します。
論理的根拠: リポジトリを分離することで、影響範囲を縮小し、ライフサイクルポリシーを簡素化できます。明示的なIAMにより、過剰な権限を持つデフォルト設定を回避できます。

環境分離を伴うインフラストラクチャをTerraformで定義する

terraform/envs/devとterraform/envs/prodディレクトリを作成します。各構成には、個別のステートバケットを持つGCSバックエンド、GKEクラスタモジュール、Cloud Deployサービスアカウント用のIAMバインディングが含まれます。環境ごとにゲート付きのCIジョブでterraform init、plan -out=plan.bin、apply plan.binを実行します。
論理的根拠: 環境ごとのステートとプロジェクトは、偶発的な環境間の影響を防ぎます。プランファイルはレビューと監査可能な変更管理をサポートします。

宣言的なKubernetesベースとKustomizeオーバーレイを作成する

Kubernetesマニフェストをk8s/baseに配置し、Deployment、Service、HPAのイメージをダイジェストで固定します。k8s/overlays/devとk8s/overlays/prodを作成し、レプリカ数、リソースリクエスト、構成パッチを設定します。データベース認証情報にはSecret Manager CSIクラスを使用します。
論理的根拠: オーバーレイを持つ単一の信頼できる情報源（Single source of truth）はドリフトを排除し、構成をDRYに保ちながら、安全な環境固有の差異を可能にします。

個別のテストおよびパッケージステップを持つCloud Buildを実装する

cloudbuild.yamlには、リントとユニットテスト、使い捨てのdev名前空間に対するインテグレーションテスト、コンテナのビルドと環境リポジトリへのプッシュ、SBOMと脆弱性スキャン、来歴生成のステップが含まれます。トリガーは、テストのためにmainへのPRで実行され、パッケージングのためにマージ時に実行されます。ビルドは、最小権限のcb-deployerサービスアカウントとして実行されます。
論理的根拠: 早期の失敗は安価です。関心事を分離することで、可観測性が向上し、対象を絞った再試行が可能になります。最小権限はサプライチェーンリスクを低減します。

手動の本番承認とカナリア戦略を持つCloud Deployデリバリーパイプラインを構成する

devとprodのターゲットを持つDeliveryPipelineを定義します。prodステージは承認を必要とし、カナリア戦略（例: 10%、その後100%）を使用します。スキーマ互換性チェックとスモークテストにはpredeployフックを使用し、postdeployではSLOを検証します。
論理的根拠: プログレッシブデリバリーは影響範囲を限定し、自動化された品質ゲートを導入します。一方、手動承認は本番環境に対する人間による介在を強制します。

GitOpsとポリシー適用を連携させる

必須のレビューと合格したチェックでmainブランチを保護します。Policy Controllerの制約を使用して、特権付きPodをブロックし、変更可能なタグを禁止します。Binary Authorizationを有効にして、アドミッションの前にCloud Buildの来歴と「重大なCVEがない」ことの証明書を要求します。
論理的根拠: Policy-as-codeは、リスクの高い構成がクラスタに到達するのを防ぎ、一貫した適用を提供します。

安全なリリースのために構成と機能フラグを管理する

シークレットではないランタイム構成はConfigMapsに保存し、シークレットはSecret Manager CSIを介して提供します。prodで1%の初期ロールアウトを行う機能フラグorder_new_flowを導入し、Firestoreから読み取ります。フラグは短いTTLでキャッシュされ、ログに記録されます。
論理的根拠: フラグはリリースとデプロイを分離し、問題が発生した場合にバイナリをロールバックすることなく即座に無効化できます。

可観測性、ドリフト検出、トレーサビリティを確保する

ビルドとリリースにコミットSHA、PR番号、変更チケットをアノテーションとして付与します。Cloud DeployイベントとGKE監査ログを中央のLoggingプロジェクトにルーティングします。夜間のterraform planジョブがドリフトを警告し、Config SyncはKRMの乖離を監視してGitと一致するように調整します。
論理的根拠: 完全な来歴と監査証跡はインシデント対応を迅速化し、継続的なドリフト検出はインフラストラクチャの整合性を維持します。

ロールバックと変更管理を運用する

インシデント発生時は、まずフラグを介してorder_new_flowを無効にします。必要であれば、Cloud Deployで以前の成功したリリースをdevとprodに昇格させます。すべてのprodへの昇格には、リリースアノテーション内のチケット参照と、オンコールのSREからの承認が必要です。
論理的根拠: フラグは即時の緩和策を提供し、不変のリリースは予測可能なロールバックを可能にします。承認とアノテーションは、運用ガバナンスとコンプライアンスを満たします。

← ID、認証、アプリケーションセキュリティ · すべてのドメイン · 可観測性、デバッグ、サイト信頼性オペレーション →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →