Cloud Build によるデプロイ自動化の手引き

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

対象読者:（中級レベル）このドキュメントは、これまで Google Cloud を操作したことがなくても、継続的インテグレーション、パッケージ管理、初級レベルのコンテナ、メッセージングを設計した経験がある方を対象としています。またこのドキュメントでは、読者の方が既存のフロントエンド アプリケーションおよびサポート API サーバーをローカル環境にお持ちであることを前提としています。

テクノロジー: 

• Cloud Build

• Cloud Build トリガー

• Artifact Registry

• Cloud Run

• Pub/Sub

前提条件:

• 機能的なクライアントサイド リポジトリ

• 機能的な API サーバー リポジトリ

• 課金を有効にした既存の GCP プロジェクト

• UNIX マシン

ヒーローのジャーニー - クエストの始まり

開発の初めのステージでは、アプリケーションをコンテナ化してデプロイするために必要となる面倒な作業を過小評価しがちです。これは、特にクラウド初心者にありがちな傾向です。Google Cloud ではこのような面倒な作業を増やさずにプロジェクトを完了することができるでしょうか？詳しく見ていきましょう。このブログで辿るクエストでは、次のプロダクトの優れた機能を活用してデプロイを迅速に自動化するためのキーポイントをご紹介します。

• Cloud Build: DevOps 自動化プラットフォーム

• Artifact Registry: ユニバーサル パッケージ マネージャー

• Cloud Run: コンテナ化されたアプリケーションのためのサーバーレス

• Pub/Sub: グローバル リアルタイム メッセージング 

この学習ジャーニーではフローの現実的な例をご紹介しながら、読者の皆様が独自の CI / CD パイプラインを作り上げられるようお手伝いします。このブログは、Emblem というオープンソース GitHub プロジェクトを参照します。このプロジェクトでは、Google Cloud サーバーレス パターンを使用したベスト プラクティス アーキテクチャをモデル化しています。（注: 該当する参照は Emblem でタグ付けされています）。

注: このブログでは、Emblem での手法と同じく、複数の Pub/Sub トリガーを使用する利点をご紹介します。1 つのトリガーを使ってコンテナをビルドしてデプロイする、より直接的な方法をお探しの場合は、「Cloud Build を使用した Cloud Run へのデプロイ」と「Google Cloud Deploy を使用してアプリを Cloud Run にデプロイする」のクイックスタートをご覧ください。

クエストの目標

次の目標を達成していくことで、ソース GitHub リポジトリのメインブランチに変更が加えられるとトリガーされる、API サービスの無駄のない自動デプロイフローを作成できます。

Cloud Build と Cloud Run を使用した手動デプロイ

なんらかのプロセスを自動化しようと取り掛かる前に、作成する cloudbuild.yaml ファイルにどのコマンドを追加するかについて、しっかりと理解しておく必要があります。

Cloud Build トリガーを組み込んだイメージをビルドする

Cloud Build プロダクトで、GitHub プロジェクトのメインブランチに加えられた新しい変更に応答する、最初のトリガーと cloudbuild.yaml ファイルを作成します。

Pub/Sub を介して Cloud Build イベントに応答する

Artifact Registry リポジトリの優れた組み込みの機能を使用して、Pub/Sub トピックを作成します。

Cloud Build トリガーを使用してデプロイする

上記の Pub/Sub トピックをリッスンする新しい Cloud Build トリガーと、Artifact Registry 内の新しく作成されたコンテナ イメージのデプロイを開始する cloudbuild.yaml ファイルを作成します。

始める前に

このブログで説明する手順には、次のものが必要です。

• UNIX マシンにインストールされた gcloud cli

• Dockerfile が関連付けられている既存の REST API サーバー

• 課金を有効にした Google Cloud プロジェクト（料金）

GitHub のプロジェクト リポジトリ epic-quest-project を新たに作成し、既存の REST API サーバー コード ディレクトリ（Emblem: content-api）を追加して、次のプロジェクト ファイル構造を作成します。

それでは、クエストを始めましょう！

目標 1: Cloud Build と Cloud Run を使用した手動デプロイ

gcloud とも呼ばれる Google Cloud CLI で、Google Cloud プロダクトの Cloud Build と Cloud Run を使用してコンテナをビルドおよびデプロイします。

開いたターミナル内で、以下に示すように、Google Cloud プロジェクト ID を宣言する環境変数と、プロジェクトを配置するリージョンを宣言する環境変数を作成します。さらに、Google Cloud プロジェクト内で、Cloud Run、Cloud Build、および Artifact Registry API などのプロダクト API を有効にする必要もあります。

server-side/ ディレクトリから作成するコンテナ イメージは、Artifact Registry が管理する「epic-quest」という名前のイメージ リポジトリに格納されます。

これで、「epic quest」Artifact Registry リポジトリが作成されたので、リポジトリへのコンテナ イメージの push を開始できます。gcloud builds submit を使用して、server-side/ ディレクトリからイメージをビルドし、Artifact Registry リポジトリ固有の <リージョン>-docker.pkg.dev/<プロジェクト ID>/<リポジトリ> 形式でタグを付けます。

server-side コンテナ イメージを Artifact Registry リポジトリに push したら、Cloud Run を使用してイメージをデプロイする準備は完了です！

これで、基本的な手動 CI / CD パイプラインが作成されました。次は、このパイプラインを自動化する手順を見ていきましょう。

目標 2: Cloud Build トリガーを組み込んだイメージをビルドする

この小規模なパイプラインの自動化に取り掛かるために、まず、cloudbuild.yaml ファイルを作成し、そこに最初の Cloud Build トリガーを構成します。

epic-quest-project の ops ディレクトリ内に api-build.cloudbuild.yaml という名前の新しいファイルを作成します。この新しい yaml ファイルに、Cloud Build がコンテナ イメージをビルドして Artifact Registry に push するために使用するステップを記述します。

（Emblem: ops/api-build.cloudbuild.yaml）

上記の yaml に記述されたステップを自動的に実行するように Cloud Build を構成するには、Google Cloud コンソールを使用して新しい Cloud Build トリガーを作成します。

ビルドトリガーを起動するイベントとして必ず [ブランチに push する] を選択し、[ソース] セクションで [epic-quest-project] GitHub リポジトリを接続してください。

リポジトリを Google Cloud プロジェクトに接続するには、GitHub アカウント認証情報を使用して認証を行わなければならない場合があります。リポジトリが接続されたら、そのリポジトリ内の Cloud Build 構成の場所を指定します。

この構成を送信すると、api-new-build という名前の新しいトリガーが作成されます。変更が commit されてリポジトリのメインブランチ内にある server-side/ フォルダ内の変更に統合されるたびに、このトリガーが呼び出されます。

server-side/ ファイルに対してローカルに変更を commit した後、このトリガーが機能することを確認するには、新しい commit をリポジトリのメインブランチに統合します。統合後、Google Cloud コンソールの [ビルド履歴] ページでビルドトリガーの動作を観察できます。

これで、コンテナビルドが自動化されました。新しいビルドがデプロイできる状態になったことを、Cloud Run はどのようにして把握するのでしょうか？その手段となるのが、Pub/Sub です。

目標 3: Pub/Sub を介して Cloud Build イベントに応答する

デフォルトでは、gcr という名前の Pub/Sub トピックが存在する場合、Artifact Registry はそのリポジトリ内の変更に関するメッセージをこのトピックにパブリッシュします。次に作成する Cloud Build トリガーでは、この機能を利用しましょう。まず、gcr という名前の Pub/Sub トピックを作成します。

以降は、新しいビルドが任意の Artifact Registry リポジトリに push されるたびに、そのビルドを識別するビルド ダイジェストを含むメッセージが gcr トピックにパブリッシュされます。次は、自動デプロイ パイプラインを完成させるために 2 つ目のトリガーを構成します。

目標 4: Cloud Build トリガーを使用してデプロイする

いよいよ最後のステップに到達しました。このステップでは、デプロイ トリガーを作成します。この Cloud Build トリガーが、自動デプロイ プロセスを完成させるための最後のピースです。

この Cloud Build 構成では、最初のステップで、Artifact Registry からパブリッシュされたメッセージの本文をビルドジョブ ログに出力し、2 番目のステップでビルドを Cloud Run にデプロイします。

api-build トリガーのようにリポジトリ イベントを選択するのではなく、Pub/Sub メッセージを選択し、トリガーと併せて目的の Pub/Sub トピックに対するサブスクリプションを作成します。

この場合も、リポジトリ内の対応する Cloud Build 構成ファイルの場所を指定します。さらに、構成ファイル内の代入変数に値を含めます。これらの変数は、アンダースコアの接頭辞（_）で識別できます。_BODY、_IMAGE_NAME、_REVISION の各変数は、Pub/Sub メッセージの本文に含まれるデータを参照します。

デフォルトでは、Cloud Build サービス アカウントが Cloud Run へのデプロイを開始します。したがって、このサービス アカウントには、Cloud Run サービスが存在するプロジェクト内の Cloud Run デベロッパーおよびサービス アカウント ユーザーの IAM ロールが付与されている必要があります。

これらのロールを付与した後、パイプラインが機能していることを確認するために、epic-quest-project GitHub リポジトリの server-side/ ディレクトリに対する commit を作成します。これによって、api-new-build トリガーが自動で呼び出され、その直後に api-deploy トリガーが呼び出されて、最後に対応する Cloud Run サービスで新しいリビジョンが作成されます。

プロジェクトの最終的な設定は、次と似たような結果になります。

クエストはこれで完了です！

お疲れさまでした。新しく作成した自動パイプラインによって、デプロイがレベルアップしました！

今日のこの投稿を読んで、Cloud Build と Cloud Run を使用して手動でコンテナを作成してスピンアップする方法、Cloud Build トリガーを使用して GitHub リポジトリでのアクションに応答する方法、cloudbuild.yaml ファイルを作成してビルドトリガーに構成を追加する方法、そして Artifact Registry リポジトリの優れた利点について理解を深めていただけたことを願います。

• さらなる詳細情報については、GitHub でオープンソース サーバーレス プロジェクト Emblem をご確認ください。