はじめに

この記事では、GithubとCloud Buildを使ったCloud RunのCI/CD環境構築について説明しています。Cloud Build でビルドする際にはKanikoキャッシュを使うことによって、ビルド時間を短縮しています。

この記事の対象者

GithubとCloud Buildを使って、Cloud RunのCI/CDの環境構築がしたい方
Kanikoキャッシュを使って、Cloud Build のビルド時間を短縮したい方

環境

Visual Studio Code
Google Cloud Engine
Linux

本編

ここから開発環境構築からCI/CD環境構築までの説明をします。

1. 事前準備

開発はGoogle Cloud EngineのVMインスタンスを作成し、VSCodeからSSH接続して行います。また、今回使用するGoogle Cloud のAPIについても、有効化する必要があります。

2. Dockerイメージの保存先

Cloud Buildの過程で生成されるDockerイメージやキャッシュを保存するリポジトリを作成します。今回はArtifact Registryのリポジトリに保存します。 Google Cloud Consoleで作成する方法は以下の通りです。

GCCにアクセスし、Artifact Registryのプロダクトページに移動します。
リポジトリを作成を押します。
名前に任意のリポジトリ名を決め、入力します。
形式をDockerにします。
ロケーションタイプをリージョンにし、任意のリージョンを選び、作成を押します。

※ 上記に示していない設定については、デフォルトにしています。

3. アプリケーションのプログラムの管理

アプリケーションの開発やCI/CDの環境を構築する上で必要なプログラムの管理はGitHubで行います。

GitHubのリポジトリの作成 GitHubにアプリケーションのコードを管理するためのリポジトリを作成します。個人または組織のGithubにリポジトリを作成してください。

ブランチの作成 作成したリポジトリのブランチに、開発環境用のブランチを作成します。ブランチ名はCloud Buildのトリガーを作成する際に使います。同じリポジトリ内で複数のアプリケーションのプログラムを扱う際には、ブランチでどのアプリケーションのDockerイメージをビルドするかを区別するので、わかりやすいブランチ名にします。

4. Cloud Buildの構成

Cloud BuildでCI/CDの環境を構築するうえで必要になるのが、cloudbuild.yamlです。

cloudbuild.yamlの作成 cloudbuild.yamlでは、DockerfileからDockerイメージの作成・Artifact Registryへの保存を行い、Cloud Runのアプリケーションとしてデプロイするまでの挙動を設定しています。

# cloudbuild.yaml
# Google Cloud Buildの設定ファイルです。
# このファイルはDockerイメージをビルドし、
# GCRにプッシュしてCloud Runにデプロイするために使用されます。

substitutions:
  _LOCATION: <Artifact Registryのロケーション>
  _REPOSITORY: <Artifact Registryの名前>
  _IMAGE_NAME: <作成されるDockerイメージの名前>
  _TAG: <作成されるDockerイメージのタグ>
  _SERVICE_NAME: <Cloud Runにデプロイされるアプリケーションの名前>
  _REGION: <Cloud Runのリージョン>
  
steps:
  # ステップ 1: Kanikoを使用してDockerイメージをビルドして、リポジトリにPushする
  - name: 'gcr.io/kaniko-project/executor:latest'
    args:
    - --destination=${_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${_REPOSITORY}/${_IMAGE_NAME}:${_TAG}
    - --dockerfile=<GitHub上でのDockerfileのパス>
    - --cache=true
    - --cache-ttl=8h
    - --compressed-caching=false
    - --cache-copy-layers=true
    id: Build & Push

  # ステップ 2: Cloud Runにデプロイする
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    args: ['run', 'deploy', '${_SERVICE_NAME}', 
           '--image', '${_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${_REPOSITORY}/${_IMAGE_NAME}:${_TAG}', 
           '--region', '${_REGION}',
           '--platform', 'managed',
           '--allow-unauthenticated',
           '--memory', '2Gi',
           '--concurrency', '1',
           ]
    id: Deploy

変数の設定
```
substitutions:
  _LOCATION: <Artifact Registryのロケーション>
  _REPOSITORY: <Artifact Registryの名前>
  _IMAGE_NAME: <作成されるDockerイメージの名前>
  _TAG: <作成されるDockerイメージのタグ>
  _SERVICE_NAME: <Cloud Runにデプロイされるアプリケーションの名前>
  _REGION: <Cloud Runのリージョン>
```
上記のような内容については変数化しておくと、変更があった場合に便利です。 PROJECT_IDについてはデフォルトで設定されているので、特に指定しません。 Cloud Buildの変数に関する詳しい説明は以下をご覧ください。

https://cloud.google.com/build/docs/configuring-builds/substitute-variable-values?hl=ja

Dockerイメージのビルドとプッシュ

  - name: 'gcr.io/kaniko-project/executor:latest'
    args:
    - --destination=${_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${_REPOSITORY}/${_IMAGE_NAME}:${_TAG}
    - --dockerfile=<GitHub上でのDockerfileのパス>
    - --cache=true
    - --cache-ttl=8h
    - --compressed-caching=false
    - --cache-copy-layers=true
    id: Build & Push

Dockerイメージのビルドとプッシュの記述について説明します。

name: 使用するビルドツールとしてgcr.io/kaniko-project/executor:latestを指定。
args:

destination: 作成したイメージの保存先を指定。
- ${_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${_REPOSITORY}/${_IMAGE_NAME}:${_TAG}形式で指定。
dockerfile: 使用するDockerfileのパスを指定。
cache=true: キャッシュを有効にしてビルドを高速化。
cache-ttl=8h: キャッシュの有効期限を8時間に設定。任意の時間に変更可
compressed-caching=false: 圧縮キャッシングを無効に。
cache-copy-layers=true: キャッシュコピーのレイヤーを有効に。

上記のargs以外にも指定できるものが数多くあります。詳細については以下をご覧ください。

https://github.com/GoogleContainerTools/kaniko?tab=readme-ov-file#flag---dockerfile

メモ

ポイント ビルド対象のDockerfileの記述において、さまざまなライブラリをインストールすると思います。その時に、requirements.txtに必要なライブラリ名とバージョンを記述して、RUN pip install -r requirements.txt のようにインストールする手法がありますが、私の場合はキャッシュ化されませんでした。もし、Kanikoキャッシュを使ってもビルド時間が短縮されないようなことがあれば、ライブラリのインストール部分をべた書きにする対策があることを覚えておいてください。

Cloud Runのアプリケーションのデプロイ

  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    args: ['run', 'deploy', '${_SERVICE_NAME}', 
           '--image', '${_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${_REPOSITORY}/${_IMAGE_NAME}:${_TAG}', 
           '--region', '${_REGION}'
           ]
    id: Deploy

Cloud Runのアプリケーションのデプロイの記述について説明します。

name: 使用するデプロイツールとしてgcr.io/google.com/cloudsdktool/cloud-sdkを指定。
entrypoint: gcloudコマンドを使用。
args:

run deploy: Cloud Runにアプリケーションをデプロイするコマンド。
${_SERVICE_NAME}: デプロイするサービスの名前。
-image: デプロイするDockerイメージの場所を指定。
-region: Cloud Runのリージョンを指定。

上記のargs以外にも指定できるものが数多くあります。詳細については以下をご覧ください。

https://cloud.google.com/build/docs/deploying-builds/deploy-cloud-run?hl=ja

5. Cloud Buildトリガーの作成

cloudbuild.yamlを作成したところで、GitHubの特定のリポジトリのブランチにプッシュされたときに、cloudbuild.yamlを参照してCloud Runへアプリケーションを自動でデプロイするように、Cloud Buildのトリガーを設定します。

Google Cloud ConsoleのCloud Buildプロダクトのページのトリガーのページに移動します。
トリガーを作成を押します。
名前は任意、リージョンは「asia-east1（台湾）」、イベントは「ブランチにpushする」を設定します。

リージョンを台湾にした理由としては、Cloud Buildの仕様に使用状況に応じて、特定のリージョンしか使えなくなるものがあったためです。詳しくは以下をご覧ください。

https://cloud.google.com/build/docs/locations?hl=ja
ソースは第1世代で生成し、リポジトリは新しいリポジトリに接続を押して、GitHubと接続します。ブランチはこのトリガーでデプロイするアプリケーションのプログラムの管理を行っているブランチを設定してください。
構成では、形式はCloud Build構成ファイル、ロケーションはリポジトリ、cloudbuild.yamlのパスを入力します。このパスはGitHubのルートディレクトリからのパスにしてください。

※ 上記に示していない設定については、デフォルトにしています。

以上でGithubとCloud Buildを使ったCloud RunのCI/CD環境構築は終了です。