Cloud Deploy

解決する課題

コンテナをビルドした後、それを開発・ステージング・本番と複数環境へ順に展開する「デリバリ」の工程は、シェルスクリプトや CI ジョブの寄せ集めになりがちです。誰がどの環境へ何を出したのか追えず、本番への昇格や切り戻しが手作業に依存します。Cloud Deploy はこの「ビルド後の届け方」をマネージドに引き受けます。

• 同じ成果物を環境ごとに順番にプロモーションする流れを、宣言的なパイプラインとして固定したい
• 本番へ出す前に承認ゲートを挟み、誰がいつ承認したかを記録に残したい
• 問題が起きたときに直前の安定版へワンクリックでロールバックしたい
• カナリアなど段階的なロールアウトを、自前のスクリプトではなくマネージドな仕組みで行いたい
• ビルド（CI）と切り離して、デリバリ（CD）だけを専任で担うサービスが欲しい

主要概念と用語

• デリバリパイプライン（Delivery Pipeline）: リリースが通過する一連のステージ（環境）の順序を定義する最上位の構成。開発からステージング、本番へという昇格経路を表す
• ターゲット（Target）: デプロイ先の環境を表す定義。GKE クラスタ、Cloud Run、または GKE Enterprise のフリート等を指す。複数のパイプラインから共有できる
• リリース（Release）: ある時点のレンダリング済みマニフェストと成果物（コンテナイメージ）をひとまとめにした不変のスナップショット。パイプラインに対して 1 回作成し、各ターゲットへ昇格していく
• ロールアウト（Rollout）: リリースを特定のターゲットへ実際に適用する操作。1 リリースはターゲットごとにロールアウトを持つ
• プロモーション（Promotion）: あるターゲットで成功したリリースを、パイプラインの次のステージへ進める操作
• 承認（Approval）: ロールアウト実行前に人手の承認を必須にするゲート。本番ターゲットなどに設定する
• デプロイ戦略（Strategy）: 標準（一括）かカナリアか、といった反映の進め方。カナリアでは段階的に比率を上げていく
• スキャフォールド／レンダリング: パイプライン実行時に Skaffold を使ってマニフェストを環境ごとに具体化（レンダリング）し、その結果をリリースに固定する処理

仕様・制限・クォータ

• CD 専任サービス: ソースのビルドは行わない。コンテナイメージのビルドは Cloud Build 等で済ませた前提で、その成果物のデリバリを担う
• 対応ターゲット: GKE、Cloud Run、GKE Enterprise（フリート／マルチクラスタ）などをデプロイ先にできる。対応範囲の最新は公式ドキュメントで確認する
• Skaffold ベース: マニフェストのレンダリングとデプロイ実行に Skaffold を内部利用する。skaffold.yaml と Kubernetes マニフェストまたは Cloud Run サービス定義を入力にする
• リリースは不変: 一度作成したリリースのレンダリング結果は固定され、各ターゲットへは同じ成果物が昇格する。これが環境間の一貫性を担保する
• デプロイ戦略: 標準（一括反映）とカナリア（段階的）をサポート。カナリアの比率や検証の挟み込み方を構成できる
• クォータ: パイプライン数・同時ロールアウト数・API レートなどにプロジェクト単位の上限があり、具体値は変動し得るため公式ドキュメントで確認する

内部の仕組み

Cloud Deploy は、宣言的なパイプライン定義に沿ってリリースをステージ間で昇格させるオーケストレーターです。実際のクラスタ操作は Skaffold と各ターゲットの API を通じて行われます。

• リリース作成時、Skaffold が各ターゲット向けにマニフェストをレンダリングし、その成果（適用される具体的な定義）をリリースに保存する
• 最初のステージのターゲットに対してロールアウトを実行し、レンダリング済み定義を適用する
• そのロールアウトが成功すると、ユーザーは次のステージへプロモーションできる。承認ゲートがあれば承認後に進む
• カナリア戦略では、まず一部に新バージョンを出し、段階的に比率を上げてから全面反映する
• デプロイ実行は内部的に Cloud Build の実行環境を利用し、ログやステータスを通じて各フェーズを追跡できる
• 操作（リリース作成・プロモーション・承認・ロールバック）は Cloud Audit Logs に記録され、誰がいつ何を出したかを監査できる

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

• パイプライン定義を Git で管理し、clouddeploy.yaml や skaffold.yaml をコードレビューと履歴管理の対象にする
• 同一リリースを昇格させ、環境ごとにイメージを再ビルドしない。開発で検証した成果物そのものを本番へ届けることで差異を排除する
• 本番ターゲットには承認ゲートを設定し、自動で本番へ流れ込まないようにする
• 本番に近い環境ではカナリア戦略を採り、メトリクスを観測しながら段階的に比率を上げる
• ターゲットごとに専用のサービスアカウントと最小権限を割り当て、デリバリ権限を環境単位で分離する
• Cloud Build（CI）と Cloud Deploy（CD）を連携させ、ビルド成功を契機にリリースを自動作成する流れを組む
• ロールバック手順を事前に確認し、切り戻しが確実に効くことを平時にテストしておく

運用・監視

• 各**ロールアウトの状態（実行中・成功・失敗）**とリリースの昇格状況をダッシュボードで把握する
• 失敗時は**実行ログ（Cloud Build/Skaffold 由来）**を辿り、マニフェスト適用やヘルスチェックの失敗原因を特定する
• 問題発生時は対象ターゲットを直前の安定リリースへロールバックする。ロールバックも 1 つのロールアウトとして記録される
• 承認・プロモーション・ロールバックの操作は Cloud Audit Logs に残るため、リリース履歴の棚卸しに使う
• デプロイ結果や進行は Cloud Monitoring/Logging と組み合わせ、ロールアウト後のアプリ挙動（エラー率・レイテンシ）まで含めて観測する
• カナリア中は中間フェーズのメトリクスを監視し、異常があれば比率を上げる前に止める

コスト

Cloud Deploy 自体はアクティブなデリバリパイプライン単位での課金という考え方が基本で、これに加えてデプロイ実行に使う Cloud Build の実行や、出力先のログ保管などの周辺費用が発生し得ます。実際に動かすワークロード（GKE クラスタや Cloud Run）の費用とは分けて捉えます。

具体的な料金体系は変動し得るため、断定的な金額ではなく上記の構造で捉え、最新は公式の料金ページで確認してください。

セキュリティ

• ターゲットごとの実行サービスアカウントの権限が、そのデリバリの作用範囲の上限になる。本番ターゲットには本番のみ触れる最小権限を割り当てる
• 本番への承認権限を IAM で限定し、リリース作成・プロモーション・承認・ロールバックといった操作を役割ごとに分離する
• Binary Authorization と組み合わせ、署名済み・検査済みのイメージだけがデプロイされるよう関門を設ける
• パイプライン定義やマニフェストの格納先（Git／Cloud Storage／Artifact Registry）へのアクセスを保護し、改ざんを防ぐ
• 機密値はマニフェストへ直書きせず、Secret Manager を参照する形にして平文の散在を避ける
• 操作は Cloud Audit Logs で監査し、誰がどの環境へ何を出したかを追跡できるようにする

Well-Architected の観点

• 運用上の優秀性（operational）: デリバリ手順を宣言的なパイプラインとしてコード化し、環境間で同一成果物を昇格させることで、リリースの再現性と一貫性を高める。承認やロールアウト履歴が監査可能になり、手作業デプロイを排除できる
• 信頼性（reliability）: カナリアなど段階的なロールアウトで影響範囲を絞り、異常時には直前の安定リリースへ素早くロールバックできる。本番への承認ゲートが、検証不十分な変更の流入を防ぐ

試験で問われるポイント

関連サービス・比較

Cloud Deploy は単体で完結せず、CI（Cloud Build）や検証（Binary Authorization）、成果物保管（Artifact Registry）と連携して CD の役割に専念します。AWS では CodeDeploy が近い位置づけで、ビルドは CodeBuild、全体のオーケストレーションは CodePipeline が担います。

ハンズオン / CLI例

# 必要な API を有効化
gcloud services enable clouddeploy.googleapis.com

# パイプライン定義（clouddeploy.yaml）とターゲット定義を登録する
# clouddeploy.yaml にデリバリパイプラインとターゲット（dev/staging/prod）を記述
gcloud deploy apply \
  --file clouddeploy.yaml \
  --region asia-northeast1

# リリースを作成する（skaffold.yaml とイメージを指定し、最初のターゲットへロールアウト）
gcloud deploy releases create rel-001 \
  --delivery-pipeline my-app-pipeline \
  --region asia-northeast1 \
  --skaffold-file skaffold.yaml \
  --images app=asia-northeast1-docker.pkg.dev/PROJECT_ID/repo/app@sha256:DIGEST

# 次のステージへプロモーションする（例: dev で成功したリリースを staging へ）
gcloud deploy releases promote \
  --release rel-001 \
  --delivery-pipeline my-app-pipeline \
  --region asia-northeast1

# 本番ターゲットなどで承認待ちのロールアウトを承認する
gcloud deploy rollouts approve rel-001-to-prod-0001 \
  --release rel-001 \
  --delivery-pipeline my-app-pipeline \
  --region asia-northeast1

# 問題発生時に対象ターゲットを直前の安定リリースへロールバックする
gcloud deploy targets rollback prod \
  --delivery-pipeline my-app-pipeline \
  --region asia-northeast1