GitOps でサービスをオーケストレーションする

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

GitOps は、バージョン管理や CI / CD のようなアプリケーション開発に使用される DevOps のベスト プラクティスをインフラストラクチャの自動化に適用しています。GitOps では、Git リポジトリを信頼できる情報源とし、CD パイプラインが、アプリケーション コードと基本的なインフラストラクチャの構築、テスト、デプロイの責任を担います。

昨今では、アプリケーションとは、所有し運用するインフラストラクチャ上で運用される単なるコードではありません。これは、通常、イベント ドリブンなアーキテクチャ内で、もしくは Workflows のような一元的なサービス オーケストレーターと連携する、ファーストパーティとサードパーティ マイクロサービスのセットとなっています。

独自の定義ファイルとデプロイ サイクルを持つサービス オーケストレーションは、GitOps アプローチの恩恵を受けることができます。このブログ投稿では、Cloud Build を使用し、Workflows のためのシンプルな Git ドリブン開発の設定、テスト、パイプラインをデプロイする方法について説明します。

アーキテクチャ

全体のアプローチを見てみましょう。

このアプローチでは、ステージング ブランチでワークフローに変更を加えます。これにより、テスト ステージング ワークフローをデプロイし、それに対するステージング テストを実行する Cloud Build 構成がトリガーされます。すべてのテストに合格すると、Cloud Build はステージング ワークフローをデプロイします。ステージング ワークフローの手動テストの後、ステージング ブランチからメインブランチへ変更を統合します。これにより、同じ Cloud Build 構成でテスト用の本番環境ワークフローをデプロイし、本番環境テストを行います。そしてすべてに合格すると、本番環境ワークフローがデプロイされます。

このアプローチにより、最小限のリスクで、ワークフローの変化を自動的かつ段階的に公開することができます。

構成

自動化されたワークフロー デプロイ パイプラインの設定は単純です。

まず始めに、自動化の恩恵を受けることのできるワークフローの定義ファイルが必要です。ご自身のワークフロー定義ファイル、もしくは Hello World と表示するだけの workflow.yaml を使用できます。

次に、すべてのステージで Cloud Build 構成ファイル（cloudbuild.yaml 参照）を定義します。この構成では、Cloud Build は、ブランチ名とコミット ハッシュを含むテスト用ワークフローのデプロイ、ワークフローの実行と出力のキャプチャ、テスト用ワークフローの削除、提供されたテスト スクリプトによるワークフローのテストを行います。すべてのテストに合格すると、ブランチに最終のワークフローがデプロイされます。

ブランチのテストは、適切な test-{branchname}.sh ファイルで定義されています。たとえば、test-staging.sh は、ステージング ブランチにデプロイされたワークフローに対して実行され、ワークフロー実行状態の確認のみ行います。一方、test-main.sh は、メインブランチに対して実行され、ワークフローの実行状態だけでなく実行結果の出力の確認も行います。また、適宜テストを追加することも可能です。

リポジトリを Cloud Build に接続する

基本的な構成ができたので、トリガーを作成する前に、ご自身（もしくは workflows-demos）のリポジトリを Cloud Build に接続します。この手順に沿ってください。

Cloud Build トリガーを作成する

メインブランチとステージング ブランチへの commit を確認するために、Cloud Build トリガーを作成します。一般的な手順については、こちらをご覧ください。

コンソール内にある Cloud Build の [トリガーの作成] セクションへ移動し、以下の手順に沿ってトリガーを作成してください。

• 名前: workflows-trigger

• イベント: ブランチに push する

• リポジトリ: GoogleCloudPlatform/workflows-demos

• ブランチ: ^main$|^staging$

• 含まれるファイル フィルタ: gitops/workflow.yaml

• 構成タイプ: Cloud Build 構成ファイル

• Cloud Build 構成ファイルの場所: / cloudbuild.yaml

• Key-Value に置換変数を追加: _WORKFLOW_NAME と workflows-gitops

ステージング ワークフローをテストする

これでステージング ブランチを使用したビルド パイプラインをテストする準備が整いました。

ステージング ブランチに切り替えます。

git checkout staging

ステージング ブランチへの変更を commit し、push します。

トリガーが実行されているのが確認できるはずです。

数秒後、ビルド（すべてのステージを含む）が完了します。

ステージング ワークフローがデプロイされました。

本番環境ワークフローをテストする

ステージング ワークフローを本番環境にデプロイする準備ができたら、ステージング ブランチをメインブランチに統合します。

しかしこの場合、ビルドには失敗します。

test-main.sh の本番環境ワークフローのテスト スクリプトが、ワークフローの出力として Hello World を予測しているためです。

ステージング ブランチを確認し、ビルドの成功が確認できたら、メインブランチに統合します。最後に、ビルドが成功したことを確認し、本番環境ワークフローがステージング ブランチにデプロイされていることを確認します。

次のステップ

この投稿では、Cloud Build を使用し、Workflows のための Git ドリブン開発の設定、テスト、パイプラインをデプロイする方法について説明しました。詳細やサンプル構成ファイルについては、workflows-demos/gitops リポジトリをご確認ください。

もちろん、Cloud Build だけが、このようなパイプラインを設定する方法ではありません。GitHub Actions は、同様のサービス オーケストレーション パイプラインの設定に役立つ便利なツールです。ぜひ、GitHub Actions ベースのパイプラインで私たちのリポジトリに貢献いただき、ご質問やフィードバックは Twitter @meteatamel までご連絡ください。

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