Google Cloud Platform

Cloud Source Repositories と Container Builder によるサーバーレスでの自動デプロイ

デプロイを自動化する理由には、整合性、安全性、タイムリー性などがあります。ソフトウェアがビジネスにとって重要になればなるほど、これらの重要性も高まります。この記事では、Google Cloud Platform(GCP)ツールを使用すれば自動デプロイを簡単に始められることを示しつつ、デプロイ プロセスを堅牢にするうえで役に立つリソースを紹介します。

たとえば、Google Cloud FunctionsFirebaseGoogle App Engine のいずれかのアプリケーションがあるとします。現時点では、おそらくローカル ワークステーションで gcloud コマンドを使用し、関数やアプリをデプロイすることが多いと思います。では、Google Cloud の Cloud Source RepositoriesCloud Container Builder を利用した軽量のワークフローならどうなるでしょうか。

serverless-deployments-3dnr8.max-700x700.png

この単純なパイプラインは、ソース コードが prod ブランチにプッシュされたときに、Cloud Container Builder のビルド トリガーを使って Cloud Functions に関数をデプロイします。

最初のステップは、コードをソース管理システムの管理下に置くことです。すでに GitHub や Bitbucket などのプロバイダーを利用しているのであれば、Cloud Source Repositories にコードをミラーリングするのは簡単でしょう。Cloud Source Repositories は 5 人までのプロジェクト ユーザーには無料で提供されるので、小規模のチームにはうってつけです。

以下ではコマンドラインを用いて説明しますが、こちらのドキュメントにはもっと詳しい説明があります。

まず、リポジトリを作成し、クローンを作ります。

  $ gcloud source repos create my-function
Created [my-function].
$ gcloud source repos clone my-function
Cloning into 'my-function'...

そして、簡単な関数を作りましょう(サードパーティの依存コードがある場合は、package.json をインクルードしてください)。

  index.js
exports.f = function(req, res) {
  res.send("hello, gcf!");
};

次に、Container Builder のビルド定義を作ります。

  deploy.yaml
steps:
- name: gcr.io/cloud-builders/gcloud
  args:
  - beta
  - functions
  - deploy
  - --trigger-http
  - --source=.
  - --entry-point=f
  - hello-gcf # Function name

この定義は次のコマンドを実行するのと同じです。

  gcloud beta functions deploy --trigger-http --source=. --entry-point=f hello-gcf

最初のビルドを始める前に、Container Builder 向けにプロジェクトをセットアップしてください。まず、Container Builder APICloud Functions API の 2 つの API を有効にします。Container Builder がビルドを行えるようにするには、プロジェクトへのアクセス権を Container Builder に与える必要があります。ビルド プロセスは、これらのビルドに関連づけられたサービス アカウントの認証情報を使います。サービス アカウントのアドレスは {numerical-project-id}@cloudbuild.gserviceaccount.com です。

サービス アカウントには Project Editor という IAM の役割を追加する必要があります。他のリソースのデプロイにもこのプロセスを使う場合は、他の役割が必要になることがあります。

serverless-deployments-21x8b.max-700x700.png

それでは、次のコマンドを実行して、デプロイの構成とパーミッションをテストしてみましょう。

  gcloud container builds submit --config deploy.yaml .

関数は、Cloud Container Builder 経由でデプロイされるようになっています。

ビルド トリガーは簡単に作成できます。リポジトリ、トリガー条件(この場合は prod ブランチへのプッシュ)、実行するビルド(この場合は deploy.yaml で指定されたビルド)を選択してください。

serverless-deployments-1o8h4.max-500x500.png

これで、prod ブランチをアップデートし、“master” の最新情報を与え、Cloud Source Repositories にプッシュすれば、関数はデプロイされます。

  $ git checkout prod
$ git pull origin prod
$ git merge master
$ git push origin prod

デプロイが失敗した場合は、ビルド履歴の画面に失敗ビルドとして表示されます。ログを見て何が問題だったのかを調べてください。Cloud Pub/Sub と Cloud Functions を使って、メールやその他の通知方法を設定することもできます。

上述のデプロイ パイプラインは、デプロイの自動化を実証するにあたって単純化された必要最小限のパイプラインです。このプロセスではいずれニーズに合わなくなるときが来ます。たとえば、本番システムを更新する前に、手作業の承認プロセスを入れたくなった場合です。そのようなときは、もっと複雑なワークフローを処理できるオープンソースのデプロイ自動化システム Spinnaker を試してみてください。

これは最初の一歩にすぎません。デプロイの自動化を進める過程で試せるツールやテクニックをいくつか挙げておきます。


ソフトウェアのデプロイを自動化することのすばらしさを本稿から感じ取っていただければ幸いです。ぜひ感想をお聞かせください。

* この投稿は米国時間 3 月 14 日、Developer Relations の Chris Broadfoot によって投稿されたもの(投稿はこちら)の抄訳です。

- By Chris Broadfoot, Developer Relations