概観

設定手順を見てみましょう。以下の設定が、一連のダイアログで設定できます。

1. Cloud Runを設定する
2. 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

エコシステムへの投資や、今後の更なる成長を期待します。