Zenn
🤔

CICDを体験する。

2023/11/02に公開
GCP
初心者
Cloud Run
Google Cloud
Cloud Build
tech

はじめに

この記事は、
　Serverless is simple. Do I need CI/CD?
という動画を視聴し『実際にやってみた』という記事になります。

CI/CD の PipeLine は何をする？

codeをrepositoryに、commitした瞬間から、
これらの変更がUserに表示されるまでに、
少なくとも、いくつかの手順を実行する必要がある。

たとえば、保存されたArtifactを構築し、deployするなど。
SoftwareSupplyChain.png

Google Cloud API を有効化

このCI/CDを構築したいGCPプロジェクトのコンソールへ接続。

Cloud Build API
Artifact Registry API
Cloud Run Admin API

これらのAPIを有効化。
その他、APIの有効化は、必要に応じて、適宜行う事。

sample code を copy しよう。

https://github.com/GoogleCloudPlatform/cloud-code-samples/tree/v1

今回は、Forkを使うことで、元のprojectに影響を与えないようにします。
github-fork1.png
↓
github-fork2.png

プログラミング言語を選択しよう。

sample code は様々なプログラミング言語を利用可能。
自分の好みで選択してください。

この記事では、今回は、Golangを選択しまして、
cloud-code-samples/golang/go-cloud-run-hello-world
というディレクトリを操作します。

sample-gengo-go.png

Artifact Registry に コンテナイメージ を作成する準備をしよう。

コンテナイメージを保存するためのrepositoryをArtifact Registryにdeployする。

repositoryの名前：自由に名前をつけてください。
形式：Docker
region：最寄りのリージョンを選択
他の項目は、デフォルトで設定。

artifact-repo-create.png

cloud build trigger を作成しよう。

CloudBuild はCICDパイプラインを作成できる サーバレスプラットフォーム です。

triggerの名前：Hello-Cloud-Run-Pipline
region：最寄りのリージョンを選択
event：ブランチに push する
repository：github.account/cloud-code-samples
※ repository が選択画面にない場合は、新しいリポジトリに接続を行うこと。
branch：　v1（今回は、defaultbranchを選択します）
形式：cloudbuild構成ファイル
ロケーション：リポジトリ
cloudbuild構成ファイルの場所：下記の画面スクショを参考にしてください。

基本、trigger の作成は、動画の説明通りに進めて問題ないですが、
この記事では、Cloud Build 構成ファイルの場所 のみ変えています。

この記事では、cloudbuild.yamlを
golang/go-cloud-run-hello-world内で作成する為です。

cloudbuild-trigger6.png

cloudbuild.yamlを作成

vscodeなどを開いて、cloudbuild.yamlを作成。
このyamlファイルは、asia-northeast1リージョンを選択している為、
最寄りのリージョンに合わせて適宜、修正を行ってください。

また、Golangを選択していますので、他のプログラミング言語を
選択した場合も、同じく修正を行う必要があります。

steps:
  # Build app
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-f', 'golang/go-cloud-run-hello-world/Dockerfile', '-t', 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/hello:$COMMIT_SHA', './golang/go-cloud-run-hello-world']
    id: BUILD

  # Storage of the image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/hello:$COMMIT_SHA']
    id: STORAGE

  # Deploy app
  - name: 'gcr.io/cloud-builders/gcloud'
    args: ['run', 'deploy', 'hello-site', 
        '--image', 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/hello:$COMMIT_SHA',
        '--region', 'asia-northeast1',
        '--platform', 'managed',
        '--allow-unauthenticated']
    id: DEPLOY

この記事では、cloudbuid.yamlはこちらのディレクトリの階層に作成します。
cicd-cloudbuild.png

error を解消しよう。

動画内では、errorが起こりませんが、実際に試してみると、
APIの有効化の不足やサービスアカウント権限不足でerrorになることがあります。

APIの有効化については、この記事の冒頭で説明を挟んでいますが、
cloud build triiggerを実行した際に、サービスアカウント権限が
不足していると、下記のerrorが出力され、triggerは異常終了してしまいます。

Step #2: ERROR: (gcloud.run.deploy) PERMISSION_DENIED: Permission 'run.services.get' denied on resource ...

これを解決するには、
Cloud Build サービスアカウント（<PROJECT_NUMBER>@cloudbuild.gserviceaccount.com）
に対して、

  • Cloud Run管理者ロール（run.admin）
  • サービスアカウントユーザーロール（iam.serviceAccountUser）

を割り当てなければなりません。

これはGCPコンソール上の操作で設定が可能。
cloudbuild-serviceaccout.png
詳しくは、Cloud Buildを使用したCloud Runへのデプロイを参考にしてください。

Cloud Run を実行してみよう。

errorの解消が終わり、cloud build triiggerが正常終了すると、
いよいよ、deployされたCloud Run Serviceのリンクを実行して、
Applicationが実行されている事を確認することができます。

対象のCloud Run ServiceのURLを実行して下記のスクショが表示されれば成功です。
cicd-cloudrun0.png
↓ Execution Result
cicd-cloudrun1.png

Cloud Run の Canary Test release を行ってみよう。

最後にCanary Test releaseを実装して、この記事の締めとしたいと思います。

こちらも動画の内容に沿って行いますが、やることは２つです。

  • 作成した cloudbuild.yaml の Deploy App step で、--no-traffic を追加する。
  • Canary release step を追記する。

下記はCanary Test releaseに対応するように修正したcloudbuid.yamlです。

steps:
  # Build app
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-f', 'golang/go-cloud-run-hello-world/Dockerfile', '-t', 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/hello:$COMMIT_SHA', './golang/go-cloud-run-hello-world']
    id: BUILD

  # Storage of the image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/hello:$COMMIT_SHA']
    id: STORAGE

  # Deploy app
  - name: 'gcr.io/cloud-builders/gcloud'
    args: ['run', 'deploy', 'hello-site', 
        '--image', 'asia-northeast1-docker.pkg.dev/$PROJECT_ID/my-repo/hello:$COMMIT_SHA',
        '--region', 'asia-northeast1',
        '--platform', 'managed',
        '--allow-unauthenticated',
        '--no-traffic']
    id: DEPLOY

  # Canary release
  - name: 'gcr.io/cloud-builders/gcloud'
    args: ['run', 'services', 'update-traffic', 'hello-site',
        '--region', 'asia-northeast1',
        '--to-revisions=LATEST=50']
    id: CANARY

このcloudbuild.yamlをgithubへpush、cloud build triiggerが
実行され、正常に終了すると、Cloud Run内のリビジョンのトラフィックが分割され、
Canary Test releaseを実装することができます。

今回の設定では、トラフィックを50％に設定していますので、
２つのリビジョンに対して、トラフィックが50％ずつ流れていれば成功です。
CanaryTestrelease1.png
対象のCloud Run ServiceのURLを何度かreloadしてみてください。
下記のスクショが切り替わり表示されれば、Canary Test releaseは成功になります。

↓ Execution Result
CanaryTestrelease2.png
↓ Execution Result
CanaryTestrelease3.png

終わりに

今回の記事は、動画を視聴しまして、
実際に『手を動かしてみた』という内容で書きました。

実際に自分自身でやってみる事で、躓いてしまった部分もありました。

これからCICDのPipeLineに触れてみようと思っている人、
動画を視聴されまして、実際に試しにやってみたが
躓いてみてしまった人は、参考にしていただけると幸いです。

あとで『じっくり読みたい』、『繰り返し読みたい』と
思ってくれましたら、『ストック』へ登録、
この記事が読まれている方にとって、
参考になる記事となりましたら、『いいね』を
付けていただけますと、励みになりますので、
よろしくお願いします。

Discussion