コンテンツに移動
デベロッパー

マルチ環境サービスのオーケストレーション

2022年9月21日
Google Cloud Japan Team

※この投稿は米国時間 2022 年 9 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。

前回の投稿では、GitOps のアプローチを使用して、サービス オーケストレーションのデプロイ ライフサイクルを管理する方法を紹介しました。このアプローチにより、ワークフローの変更を簡単にステージング環境にデプロイし、テストを実行し、これらの変更を徐々に本番環境にロールアウトできます。

GitOps はデプロイのライフサイクルを管理するのに役立ちますが、それだけでは不十分です。異なる環境にデプロイする前に、ワークフローの変更が必要な場合があります。そのため複数の環境を想定してワークフローを設計する必要があります。

たとえば、ワークフローから呼び出される URL をハードコードする代わりに、ワークフローがデプロイされる場所に応じて、URL をステージング URL と本番環境 URL に置き換える必要があります。

ここでは、ワークフローにおける URL の置き換えについて、3 つの方法をご紹介します。

オプション 1: 実行時の引数として URL を渡す

https://storage.googleapis.com/gweb-cloudblog-publish/images/GOB2_-_1.max-500x500.png

オプション 1:

最初のオプションでは,実行時の引数として URL を定義し、サービスを呼び出す必要があるときはいつでもそれを使用します。

読み込んでいます...

例として、workflow1.yaml をデプロイします。

読み込んでいます...

ステージング環境において、ステージング URL を用いてワークフローを実行します。

読み込んでいます...

そして、本番環境において本番環境の URL を使用してワークフローを実行します。

読み込んでいます...

注: これらのランタイム引数は、API、クライアント ライブラリ、スケジュール トリガーを使用してトリガーする場合にも渡すことができますが、Eventarc でトリガーする場合には渡すことができません。

オプション 2: Cloud Build を使用して複数のバージョンをデプロイする

https://storage.googleapis.com/gweb-cloudblog-publish/images/GOB2_-_2.max-700x700.png

オプション 2

2 番目のオプションでは、Cloud Build を使用して、適切なステージングと本番環境の URL をデプロイ時に置き換えて、複数のバージョンのワークフローをデプロイできます。

setup.sh を実行して、必要なサービスを有効にし、必要なロールを付与します。

URL のプレースホルダ値を持つ YAML (例として workflow2.yaml を参照)を定義します。

読み込んでいます...

プレースホルダの URL を置き換えるステップとデプロイのステップがある cloubuild.yaml を定義します。

読み込んでいます...


ステージング環境において、ステージング URL を用いてワークフローをデプロイします。

読み込んでいます...

本番環境において、本番環境 URL を使用してワークフローをデプロイします。

読み込んでいます...

これで、ステージング環境と本番環境で、2 つのワークフローを実行する準備ができました。

読み込んでいます...

オプション 3: Terraform を使用して複数のバージョンをデプロイする

https://storage.googleapis.com/gweb-cloudblog-publish/images/GOB2_-_3.max-700x700.png

オプション 3

3 番目のオプションでは、Terraform を使用して、適切なステージングと本番環境の URL をデプロイ時に置き換えて、複数のバージョンのワークフローをデプロイできます。

URL のプレースホルダ値を持つ YAML (例として workflow3.yaml を参照)を定義します。

読み込んでいます...

ステージングと本番環境のワークフローを作成する main.tf を定義します。

読み込んでいます...

Terraform を初期化します。

読み込んでいます...

予定されている変更を確認します。

読み込んでいます...

ワークフローを、ステージング URL を使用してステージング環境に、また本番環境 URL を使用して本番環境にデプロイします。

読み込んでいます...

これで、ステージング環境と本番環境で、2 つのワークフローを実行する準備ができました。

読み込んでいます...

長所と短所

この時点で、どのオプションがベストなのか、知りたいと思われるかもしれません。

オプション 1 は、セットアップが簡単(1 つのワークフローをデプロイする)ですが、実行ごとに URL を渡す必要があるため、実行が複雑になります。多くの URL がある場合、URL の実行時引数をすべて使用すると、実行が冗長になりすぎることがあります。また、ワークフローがどの URL を呼び出すかは、実際にワークフローを実行してみないとわかりません。

オプション 2 は、Cloud Build で複数のワークフローをデプロイするため、より複雑な設定になります。ワークフローには呼び出される URL が含まれています。その結果、実行とデバッグがよりシンプルになります。

オプション 3 は、オプション 2 とほぼ同じですが、Terraform のユーザー向けです。もしすでに Terraform を使っている場合、異なる環境の URL を置き換えるために Terraform に依存することも理にかなっています。

この記事では、マルチ環境ワークフローを実現するための例を紹介しました。ご質問やご意見がありましたら、Twitter の @meteatamel までお気軽にご連絡ください。

- デベロッパー アドボケイト、Mete Atamel

投稿先