2020年7月13日に、Gitを利用してCloud Buildで継続的なデプロイをするための設定がCloud Runから簡単に行えるようになりました。
感想です。
Cloud Run、Dockerfile置いてあるリポジトリにコミット追加されたらCloud Buildでビルド・デプロイされるんか。いよいよPaaSっぽくてめっちゃよいな!https://t.co/PFCgRlyUCf
— カエル氏の闘争🐸😽 (@toshi0607) July 17, 2020
概観
設定手順を見てみましょう。以下の設定が、一連のダイアログで設定できます。
- Cloud Runを設定する
- Cloud Buildを設定する
1-1. Service settings
ここは特に変更ありません。managedかAnthosか、Service name、Authenticationを指定します。

1-2. Configure the service's first revision
Continuously deploy new revisions from a source repository
を選択すると、SET UP WITH CLOUD BUILD
ボタンが出ます。

2-1. Source repository
Cloud Runにデプロイするコンテナの元になるソースコードとDockerファイルのあるリポジトリを選択するためには、Cloud Source Repositories APIの有効化が必要です。

Gitリポジトリは、つぎの3つから選択できます。
- Cloud Source Repositories
- GitHub
- Bitbucket
アカウントを認証して、リポジトリを選択します。リポジトリは、認証したアカウントから参照できるものが同期され、表示されます。たくさんあると少し時間がかかるので、待ってください。
今回のテストではこのリポジトリを利用しています。
2-2. Build Configuration
デプロイ対象にするブランチを正規表現で指定し、リポジトリ内のDockerファイルのパスと名前を指定します。

SAVE
、CREATE
するとCloud RunのServiceの作成が始まります。
Cloud Runの継続的デプロイ
Cloud Run、Cloud Buildの設定が終わると、Cloud RunのServiceやRevisionが作成されます。そのあとは指定したGitリポジトリのブランチに変更をプッシュすることで、ソースコードからCloud Runをデプロイできます。
Serviceとplaceholderの作成
まず、Cloud RunのRevisionとして作成されるのはSERVICE_NAME-placeholderという名前のRevisionです。

これはgcr.io/cloudrun/hello
というコンテナがデプロイされたものです。まだ、設定したリポジトリからビルドしたコンテナがデプロイされたわけではありません。
ブラウザからアクセスすると、つぎのような画面が表示されます。

Revisionの作成
つぎに、Cloud Buildの設定に基づいてビルドされたコンテナがデプロイされます。

継続的デプロイ
今度は、設定したリポジトリのmasterブランチに変更をプッシュしてみましょう。リポジトリへのプッシュをトリガーにCloud Buildが実行され、新しいRevisionが作成されます。

Cloud Buildで設定される内容
Cloud RunからCloud Buildを連携すると、Cloud Build側では何が設定されるのでしょうか。結論は、大体このドキュメントに記載されているものです。
Cloud Build を使用した Git からの継続的なデプロイ
具体的には以下の4つです。
- Cloud Build Trigger - Event
- Cloud Build Trigger - Source
- Cloud Build Trigger - Build Configuration
- Cloud Build - Service Account
変更できるのかなども含め、実際に追ってみましょう。
Cloud Build Trigger
Cloud Buildを見に行くと、指定した内容に基づきCloud Build Triggerが作成されています。


Cloud Buildを実行するEventは3種類あるうちのPush to branch
、Cloud Buildが利用する設定はInline
です。
Cloud Build TriggerをGCPコンソールから作成する場合、File typeにInline
は選択できないようでした。
Eventの変更
EventをPush new tag
に変更します。

変更を保存し、リポジトリでv0.1.0などタグを打つとCloud Buildが実行されました。

Cloud BuildのBuild historyを確認すると、Refがmaster
(ブランチ名)からv0.1.0
(タグ名)に変わっています。

Step
Cloud Buildで実行されるStepも見ておきましょう。シンプルにつぎのような構成になっています。
-
Build
: コンテナイメージのビルド -
Push
: コンテナイメージのGCRへのプッシュ -
Deploy
: GCRのイメージをCloud Runにデプロイ
steps:
- name: gcr.io/cloud-builders/docker
args:
- build
- '--no-cache'
- '-t'
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA'
- .
- '-f'
- Dockerfile
id: Build
- name: gcr.io/cloud-builders/docker
args:
- push
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA'
id: Push
- name: gcr.io/google.com/cloudsdktool/cloud-sdk
args:
- run
- deploy
- $_SERVICE_NAME
- '--platform=managed'
- '--image=$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA'
- >-
--labels=managed-by=gcp-cloud-build-deploy-cloud-run,commit-sha=$COMMIT_SHA,gcb-build-id=$BUILD_ID,gcb-trigger-id=$_TRIGGER_ID,$_LABELS
- '--region=$_DEPLOY_REGION'
- '--quiet'
id: Deploy
entrypoint: gcloud
images:
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA'
options:
substitutionOption: ALLOW_LOOSE
substitutions:
_DEPLOY_REGION: asia-northeast1
_LABELS: gcb-trigger-id=96560acf-1aa3-4525-b49d-01d4b749d6e4
_TRIGGER_ID: 96560acf-1aa3-4525-b49d-01d4b749d6e4
_GCR_HOSTNAME: asia.gcr.io
_PLATFORM: managed
_SERVICE_NAME: w-cloud-build
tags:
- gcp-cloud-build-deploy-cloud-run
- gcp-cloud-build-deploy-cloud-run-managed
- w-cloud-build
最初の2 Stepはgcr.io/cloud-builders/docker
イメージを使いdocker build
とdocker push
を、最後のStepはgcr.io/google.com/cloudsdktool/cloud-sdk
イメージを使いgcloud run deploy
コマンドを実行しています。
Inline
に表示されているこれらのStepは、GCPコンソールから変更できなさそうでした。
リポジトリにCloud Buildの設定ファイルを置くように変更すれば、必要に応じてテストなどのStepも追加できそうです。
たとえば、つぎのようにBuild、Push、Deployの前にTestを実行するStepを追加したcloudbuild.yaml
をリポジトリに置きます。
steps:
- name: golang:1.14
env: ['GO111MODULE=on']
args: ['go', 'test', './...']
id: Test # Testを実行するためのStepを追加
- name: gcr.io/cloud-builders/docker
args:
- build
- '--no-cache'
- '-t'
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA'
- .
- '-f'
- Dockerfile
id: Build
- name: gcr.io/cloud-builders/docker
args:
- push
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA'
id: Push
- name: gcr.io/google.com/cloudsdktool/cloud-sdk
args:
- run
- deploy
- $_SERVICE_NAME
- '--platform=managed'
- '--image=$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA'
- >-
--labels=managed-by=gcp-cloud-build-deploy-cloud-run,commit-sha=$COMMIT_SHA,gcb-build-id=$BUILD_ID,gcb-trigger-id=$_TRIGGER_ID,$_LABELS
- '--region=$_DEPLOY_REGION'
- '--quiet'
id: Deploy
entrypoint: gcloud
images:
- '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA'
options:
substitutionOption: ALLOW_LOOSE
substitutions:
_LABELS: gcb-trigger-id=96560acf-1aa3-4525-b49d-01d4b749d6e4
_TRIGGER_ID: 96560acf-1aa3-4525-b49d-01d4b749d6e4
_GCR_HOSTNAME: asia.gcr.io
_PLATFORM: managed
_SERVICE_NAME: w-cloud-build
_DEPLOY_REGION: asia-northeast1
tags:
- gcp-cloud-build-deploy-cloud-run
- gcp-cloud-build-deploy-cloud-run-managed
- w-cloud-build
File typeをCloud build configuration
に変更すると、このファイルを元にCloud Buildが実行されるようになります。

ただし、File typeを変更するとInline
に記載されていた設定には戻せません。Inline
も選択できなくなります。

Service Account
Cloud Buildが実行時に利用するService Accountには、つぎの3つのRoleが割り当てられています。
Service Account User
Cloud Run Admin
- (
Cloud Build Service Account
(GCPコンソールのIAMなどから確認できます))

Roleカラムに表示されていないRoleを割り当てるには、IAMのGCPコンソールやgcloudコマンドを利用します。

まとめ
今回の連携で、Cloud Runにコンテナをデプロイするための設定がより簡単になりました。個々のCloud Buildの設定は以前から利用できたものです。しかし、Cloud Run側からほとんど手間をかけずに継続的デプロイが設定できるのは嬉しいものです。一層アプリケーション自体の開発に集中できそうですね。
デプロイ周りでは、GoogleCloudPlatform/buildpacks
などで、Dockerファイルすら準備しなくて済む世界を想像してみると楽しいかもしれません。
つぎのような実装も、いずれCloud Runで利用できたり、事例が増えたりするかもしません。
- イベントドリブンなワークロード実行のためのgoogle/knative-gcp
- より楽にFunctionを実装するためのFunctions Framework
エコシステムへの投資や、今後の更なる成長を期待します。