Cloud Build で、自動化されたサーバーレスのデプロイ パイプラインを構築
Google Cloud Japan Team
サーバーレスのアプリケーションを Cloud Run に自動的にビルド、push、デプロイ
※この投稿は米国時間 2023 年 1 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。
新しいアプリケーションをクラウドにデプロイしようとしていると仮定します。オプションを調べた結果、Cloud Run と Cloud Build を使用して、コンテナ化されたアプリケーション コードを構築し、Artifact Registry リポジトリに push することにしました。以下の 3 つのステップで、Dockerfile と Cloud Build 構成を使用して、コンテナをビルドし、Artifact Registry に push して、Cloud Run にデプロイします。
上記の例は、1 つの Cloud Build ジョブで、ビルド、push、デプロイのステップを組み合わせています。 このブログ投稿では、一連の手動デプロイの手順がどのようなものか、そして、より複雑なソリューションへの出発点となる自動サーバーレス デプロイ パイプラインに対して、それをどのように発展させていけるかをご紹介します。 ここでは、Cloud Build、Artifact Registry、Pub/Sub、そして Cloud Run を使用します。
オープンソースの GitHub プロジェクトである Emblem を、Google Cloud サーバーレス アーキテクチャの作業用のリファレンスのモデルとして使用します。 Emblem のリファレンスは、? の絵文字で表します。
手動のパイプライン
まず、コンテナ化されたアプリケーションを Cloud Run にデプロイするための手動のステップを検証してみましょう。
まず、リポジトリのメインブランチに対し、アプリケーション コードの変更を行います。
アプリケーションの変更が統合されたら、Cloud Build を使って新しいコンテナをビルドします。
ビルドが成功したら、Cloud Build は新しくビルドされたコンテナを Artifact Registry に push します。
新しいビルドを指す新しい構成で、Cloud Run を更新します。
Cloud Run は、サービスの新しいリビジョンをデプロイします。これで、コードの変更がデプロイされました。
アプリケーション コードに変更があった場合は、再度この手順を行う必要があります。しかし、これは現実的とは言えず、コードの継続的な更新を行うチームにとっては、ロジスティック的にかなりの負担となる可能性があります。また、複数の環境に対して変更をステージングすることや、体系的なテストや段階的なロールアウトを取り入れることで、事態がより複雑になることは言うまでもありません。ビルドとデプロイの 2 つのパートに分けて、パイプラインを自動化する方法を見てみましょう。
ビルドを自動化する
パイプラインのビルドのステップを自動化するには、リポジトリのアプリケーション コードが変更された際に、Cloud Build によるビルドと push が行われる必要があります。そのために必要なことは以下のとおりです。
1. GitHub リポジトリを Cloud プロジェクトに接続する
GitHub リポジトリをプロジェクトに接続することで、Cloud Build はリポジトリのイベントを使って Cloud Build トリガーを開始できます。特定のブランチへの push、新しいタグの push、pull リクエストの作成など、一般的なリポジトリのイベントがサポートされています。
2. Cloud Build の yaml 構成をリポジトリに含める
Cloud Build のジョブをビルド構成ファイルで構成できます。この YAML ファイルは、タスクレベルのインストラクションを Cloud Build に提供します。このファイルは、アプリケーションの Dockerfile と一緒でも、リポジトリ内の別のディレクトリにあってもかまいません。自動ビルドの場合、構成ファイルは Cloud Build に対し、コンテナ イメージをビルドして Artifact Registry に push するように指示します。
? Emblem プロジェクトでは、複数のコンテナを継続的にビルドし、対応するビルド構成ファイルを、一元化された ops/ ディレクトリ内に維持します。これにより、Cloud Build 構成と、それらがビルドする可能性のあるアプリケーション コードの所有権を分離できます。
メインブランチに変更が push されるたびに、Cloud Build トリガーを呼び出すことができます。構成には、Google Cloud プロジェクトに接続する GitHub のリポジトリ、使用するブランチの名前、リポジトリ内の Cloud Build 構成ファイルのパスが必要となります。Cloud Build トリガーの起動は、特定のファイルが変更されたときのみ新しいビルドを作成するように、どのファイルやディレクトリを含めるか、または無視するかを指定することにより、さらに絞り込むことができます。
? Emblem に搭載された自動ビルドトリガーは、Cloud Build 構成ファイルを使用してコンテナをビルドし、Artifact Registry に push します。
アンダースコア（_）から始まる変数は、Cloud Build トリガーを構成する際、置換を提供できます。上記の例では、_REGION をオーバーライドすることで、Container Registry が新しい場所に移動されても、この構成を変更せずに使用できます。$PROJECT_ID のような、アンダースコアを含まない置換は組み込みとなっており、Cloud Build が提供する値を持ちます。詳しくは、組み込みの置換リストのドキュメントをご覧ください。これは、類似する関数を持つ複数のトリガーに対して、1 つの Cloud Build 構成を使用する場合に便利です。
デプロイの自動化
手動のパイプラインでは、新しいビルドが push されるとわかるので、ご自身で Cloud Run サービスをしっかり更新することができます。これを自動で行うには、新しいビルドが利用可能になったことを、なんらかの方法で Cloud Run に通知する必要があります。これは、Pub/Sub やその他の Cloud Build トリガーを使って行えます。さらに詳しく見てみましょう。
ご自身の Google Cloud プロジェクトが、「gcr」という名前の Pub/Sub トピックを含む場合、Artifact Registry は、リポジトリ内の変更についてのメッセージをパブリッシュします。イメージビルドが push されるか、タグ付けされるか、または削除されると、メッセージがパブリッシュされます。こうしたメッセージは、対応する Pub/Sub サブスクリプションによって、アプリケーション（Google の場合は Cloud Build トリガー）に配信されます。
2 つめの Cloud Build トリガーは、Cloud Run サービスの新しいリビジョンをデプロイするように構成されています。リポジトリのイベントに加えて、Cloud Build トリガーは Pub/Sub のイベントにも対応しています。gcr Pub/Sub トピックをトリガー イベントとして選択し、対応するサブスクリプションを作成できます。これに伴い、Artifact Registry が Pub/Sub にメッセージをパブリッシュする際に、Cloud Run サービスも自動的に更新されるようになります。
1 つの Cloud Build トリガーでアプリケーションをビルドし、push し、デプロイすることもできますが、ビルドと push からデプロイを分離すると、各ステージを別々の Cloud Build ジョブで実行できます。これにより、パイプラインの各要素を独立して開発しやすくなります。
? Emblem は、ウェブサイトと content-api サービスを Cloud Run に自動的にデプロイする、2 つの独立した Cloud Build トリガーを搭載しています。これらは、以下の Cloud Build 構成ファイルを共有しています。
繰り返しになりますが、構成ファイルは、トリガーの置換変数設定によって値が提供される変数を使用します。_BODY、_IMAGE_NAME、_REVISION といったようなある種の変数の値は、gcr Pub/Sub トピックから受信したメッセージを使用して評価されますが、その他の変数は以下のようにハードコードされています。
さらに先へ
このパイプラインの真価は、シンプルさではなく、別の Google Cloud プロジェクトで変更をステージングしたり、アプリケーションの変更ごとに自動テストを組み込んだり、Cloud Run サービスに段階的にロールアウトするなど、より多くの機能を組み込めるような、さらなる開発の余地にあると言えます。これらはすべて、追加の Cloud Build トリガーと Pub/Sub トピックの組み合わせで実現できます。または、先日の Cloud Run サポートの追加により、Cloud Deploy は、ロールバック、承認、監査、配信の指標を完備した Cloud Run ターゲットにデプロイするデリバリー パイプラインとして使用できるようになりました。
? Emblem は、このモデルに基づいた、より高度な自動デプロイ パイプラインを搭載しています。これには、複数の環境間で変更をステージングし、本番環境への段階的なカナリア ロールアウトをサポートするための、以下のような Google Cloud プロジェクトがいくつか含まれます。
この挙動は、Emblem GitHub リポジトリに移動し、Emblem のサンプル アプリケーションをご自身でデプロイすることで確認できます。このパイプラインをデプロイするための詳細なチュートリアルについては、Cloud Build によるデプロイ自動化の手引き.をご覧ください。
- デベロッパーリレーションズ エンジニア Roger Martinez
- クラウド デベロッパーリレーションズ エンジニア Patricia Shin
