Google Cloud Deploy を使用して Cloud Run で本番前環境を本番環境に昇格
Google Cloud Japan Team
※この投稿は米国時間 2023 年 4 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
Cloud Run にコンテナを初めてデプロイすることがたいへんわかりやすいことは、よく知られています。gcloud run deploy と入力するとコンテナが実行される様子は魔法のようで、いつも新鮮な感覚があります。
そうはいっても、ワークロードを本番前環境から本番環境に昇格する作業には、Cloud Run のようなサーバーレス プラットフォームであってもなんらかの難しさが伴います。使用量の面と開発に携わるチームメンバーの人数の面で規模が大きくなりつつあるサービスでは、なおさらのことです。
ここでは、実装に関わる 2 つの要点を見ていきます。これは、Cloud Run でサービスを使用して確認できます。
テストやステージングなどの本番前環境を Cloud Run の独立したサービスとして分離するワークロードを
本番環境へ昇格する前に、Google Cloud Deploy を使用して本番前環境と本番環境の間でそのバージョンを昇格する
このトピックに関するインタラクティブなチュートリアルへ直接移動する場合は、こちらをご利用ください。
Cloud Run で本番前環境を分離する
定番の方法である gcloud run deploy を使用する場合、どのような既成概念を打破するかの検討から入ると効果的なことがあります。
デフォルトでは、Cloud Run の各サービスにはリビジョンの概念があり、それぞれに複数のリビジョンがあります。Cloud Run には、このような複数のリビジョンにわたるトラフィック パターンの機能が用意されています。この機能は、パターンの実装に構成作業をほとんど必要としないので、A/B Testing やカナリア デプロイなどできわめて有用です。
しかし、開発/テスト、QA、ステージングなどの本番前環境を本番環境から分離する手段としてリビジョンを使用することには、わずかな不確実性があり得ます。理論的には、この手法を使用して本番環境から本番前環境を分離することで一定の効果が得られます。この場合は、目的のリビジョンをデプロイして、それに 0% トラフィックを送信します。そのサービスをテストするための固有な URL を提供するトラフィック タグを使用して、サービスをテストします。
1 回限りのテストや簡単な QA プロセスであれば、この方法で十分です。しかし、多数の人間が関与する開発で本番前環境と本番環境との間に厳格な分離を必要とする場合、この方法では問題が発生することがあります。
たとえば、IAM のロールで最も細密な管理単位は、Cloud Run のリビジョンではなく、Cloud Run のサービスにとどまります。したがって、最小権限の原則の実現を目的として、ワークロードのこのような本番前環境バージョンをその固有の Cloud Run サービスに分離することで、セキュリティ保護の観点からはるかに多くの利点が得られます。
本番前環境と本番環境の表現手段として個々の Cloud Run サービスを実装している場合は、その環境の間で各バージョンをどのように昇格するかというもっともな疑問が浮かんできます。
Cloud Deploy を使用して Cloud Run で本番前環境を本番環境に昇格する
こうした課題を解決するのが Cloud Deploy です。Cloud Deploy は、サーバーレスの継続的デリバリー プラットフォームを提供します。本番前環境と本番環境に分離した Cloud Run 環境間でコンテナ化アプリケーションのバージョンを昇格する処理を自動化および体系化できるパイプラインを、このプラットフォーム上で運用します。
Cloud Deploy では、多用する昇格シーケンスをデリバリー パイプラインに定義できます。このパイプラインは、ワークロードの新しいバージョンの昇格（リリース）に使用するさまざまなターゲットを参照します。このパイプラインを使用してターゲットにワークロードの新しいバージョンをデプロイする操作をロールアウトと呼びます。このような各リソースの視覚的な表現を次の図に示します。
当然のことながら、「開発と本番の等価性」の実現を至上として尊重するのであれば、このような環境へ実際に移行するために、なんらかの構成や環境変数の変更が必要になることが普通です。Skaffold の skaffold.yaml ファイルを使用して、このような相違を Cloud Deploy に通知できます。この構成ファイルで、profiles スタンザを定義できます。リリースをさまざまなターゲットに昇格してロールアウトを作成すると、Cloud Deploy ではこのスタンザを使用して変更が表現されます。
この例では、Cloud Run に Knative API との互換性があることから、Knative の仕様を使用して Cloud Run サービスを定義し、環境ごとの .yaml ファイルの spec.template.spec.containers.env フィールドに環境固有の環境変数を定義しています。
これらのプロファイルが、それぞれデプロイ先の Cloud Run 環境のターゲットに適合していることがわかります。これらのプロファイルは、manifests.rawYaml でそれぞれ異なる .yaml ファイルも参照します。これは、各環境に発生したわずかな変更も確実に認識できるようにするためです。ここでは、わかりやすいチュートリアルにするためにこの方法を使用していますが、実際には、Kustomize などのツールを使用して、このような環境固有のマニフェスト作成を自動化します。
最後に、Cloud Deploy では手動承認プロセスを用意することもできます。このプロセスで IAM ロールを使用して、リリースを本番環境へ実際に昇格できる開発者または管理者のグループを指名できます。これにより、テストスイートで実施するさまざまなテストで本番前環境が示す挙動を承認者が観測する時間を確保できます。
このように Cloud Run と Cloud Deploy で設定することで、本番前環境から本番環境へエンドツーエンドで全面的に移行する体勢が整います。
次のステップ
本番前環境と本番環境の Cloud Run をデザインする際に考慮すべき、次の 2 つの要点をさまざまな角度から見てきました。
テストやステージングなどの本番前環境を Cloud Run の独立したサービスとして分離する本番環境にワークロードを昇格する前に、すべての本番前環境にわたり、Cloud Deploy を使用してワークロードのバージョンを昇格する
これを実際にテストするには、Google のインタラクティブなチュートリアルをご覧ください。
本ブログ投稿の監修をしてくれた Henry Bell、S. Bogdan、Rakesh Dhoopar に感謝します。
