Cloud Buildのデプロイ自動化を検証してみた

根本夏瑠

2024.04.16

こんにちは。データアナリティクス事業本部の根本です。
先月娘が生まれ、赤ちゃんの成長スピードとその可愛さに驚き続ける毎日です。
Cloud BuildをGitHubと連携させてビルドプロセスを自動化するという検証をしましたので記事にしました。

はじめに

Cloud Buildは、Google Cloud上でCI/CD環境を構築できるサービスです。
例えば、ソースコードがGitHubのリポジトリにpushされると自動デプロイされる、とか、pushされたソースコードを自動テストして自動デプロイするというようなことを実現できます。

検証全体の流れ

GitHubとの連携設定
Cloud Buildトリガーの作成
ビルド設定ファイルの作成
ビルドのテスト

それでは順番にやって検証していきます！

GitHubとの連携設定

まずはGitHubと連携をさせます Cloud Buildのサービス画面へアクセスして、左ペインのトリガー(矢印のようなアイコン)をクリックして画面上部の[リポジトリを接続]を押下します。

今回はGitHubと連携します。GitHubを選択して[続行]ボタンを押下するとGitHub側の認証画面へ遷移します。

Cloud Buildを立ち上げているブラウザでGitHubへログイン済みですと以下のような画面になります。

Cloud BuildのGitHubアプリを、GitHubでインストールしていなかった場合はインストールが必要になるので
[GOOGLE CLOUD BUILDのインストール]を押下してインストールを行います。

今回は[Only select repositories]を選択し、一つリポジトリを選択しました。
(GitHubの全てのリポジトリを対象にすることもできるようです)

GitHubのログインパスワードを確認画面で入力して進むとCloud Buildの画面へ戻ってきます。
[GitHubアカウント]を押下して、ご自身のGitHubアカウント名が表示されていれば成功です。
GitHubアカウントと連携したいリポジトリを選択して[接続]ボタンを押下します。

接続できるようになるとトリガー作成画面でリポジトリを選択できるようになります。

Cloud Buildトリガーの作成

続いてトリガー作成を行います。今回の検証ではブランチにpushされたらデプロイして欲しいのでイベントは[ブランチにpushする]を選択しています。
ソースの項目では第１世代を選択します。(第２世代は大規模で複雑なプロジェクトやセキュリティが重要な環境に適しています。第１世代はコスト効率が良く、シンプルなプロジェクトに向いています。今回は検証用のシンプルなものなので第１世代を選択しています。)
リポジトリ、ブランチには検証に用いるものを設定します。

[形式]の項目でCloud Buildのビルド設定を記載するファイル形式を選択できます。
今回は[Cloud Build構成ファイル]を選択し、ロケーションはリポジトリ直下、
ファイル名は[cloudbuild.yaml]で設定をしました。代入変数は設定しません。
代入変数はビルド設定ファイル(cloudbuild.yamlなど)で使用できる変数のようなもので、
本番環境開発環境での値の出し分けやリソースの動的指定(バケット名やDB名など)が可能です。
サービスアカウントに、トリガーが実施する動作(Cloud Functions関数の作成権限など)の権限があるアカウントを設定して[作成]を押下します。

[作成]を押下すると、トリガーが作成されます。

ビルド設定ファイルの作成

いよいよビルド設定ファイルの作成を行います。今回使用するリポジトリは以前のブログで用いた、Cloud FunctionsとWorkflowsのソースを管理しているリポジトリとなります。以下がリポジトリの構成となります。

cloud_workflows_dev
  ├── cloudbuild.yaml
  ├── cloud_functions
  │   ├── get_file_names_function
  │   │   ├── main.py
  │   │   └── requirements.txt
  │   └── parallel_process_function
  │       ├── deploy.sh
  │       ├── main.py
  │       └── requirements.txt
  └── workflows
      └── workflow.yaml

cloudbuild.yamlはYAMLでの実装となります。以下が今回実装したものになります。
(以前のブログでデプロイ時に使ったgcloudコマンドを流用しています。)

steps:
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    gcloud functions deploy get_file_names_function \
      --gen2 \
      --region=asia-northeast1 \
      --runtime=python311 \
      --source=./cloud_functions/get_file_names_function \
      --entry-point=get_file_names \
      --trigger-http
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    gcloud functions deploy parallel_process_function \
      --gen2 \
      --region=asia-northeast1 \
      --runtime=python311 \
      --source=./cloud_functions/parallel_process_function/ \
      --concurrency=3 \
      --memory=2GiB \
      --entry-point=parallel_process \
      --trigger-http
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    gcloud workflows deploy dev_workflow \
      --location=asia-northeast1 \
      --source=./workflows/workflow.yaml
options:
  logging: 'CLOUD_LOGGING_ONLY'

それぞれのステップを簡単に説明します。

- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'

name:
使用するDockerイメージを指定します。ここでは、Google Cloud SDKが含まれている公式イメージを指定しています。

entrypoint: 'bash'

entrypoint:gcloudなどのコマンドを実行するために、cloud-sdkコンテナのエントリポイントにbashを設定しています。

  args:
  - '-c'
  - |

bash -c:シェルに対して、直後に続く文字列をコマンドとして解釈し、実行するよう指示しています。またパイプ( | )でgcloudコマンドを渡しています。

options:
  logging: 'CLOUD_LOGGING_ONLY'

ビルドトリガーにサービスアカウントを指定している場合ビルドログに関する追加設定が必要となります。ログ出力先バケットを指定するか、上記の実装(Cloud Loggingへのみ記録)をしないとビルド時に以下のエラーが発生します。

ビルドを実行できませんでした: generic::invalid_argument: if 'build.service_account' is specified, the build must either (a) specify 'build.logs_bucket', (b) use the REGIONAL_USER_OWNED_BUCKET build.options.default_logs_bucket_behavior option, or (c) use either CLOUD_LOGGING_ONLY / NONE logging options

ビルドのテスト

それではcloudbuild.yamlを実装し終えたのでリモートのmainブランチへpushしてCloud Buildのトリガーが動作するか確認します。
GitHubのリポジトリでコミットIDを確認します。ローカルで確認しても良いです。

pushした時のコミットIDは[3f7efff]でした。
それではいよいよCloud Buildのビルド履歴を確認してみます。

コミットID[3f7efff]の行がありました。ステータスも成功になっています。
続いてビルド対象のCloud Functions、Workflowsがビルドされているか確認してみます。

どちらも問題なくビルドされていました！すごい便利!笑

まとめ

Cloud Buildを用いることでデプロイ作業の自動化ができることが検証できました。
Cloud Buildを用いていなかった前回のブログでは、Cloud Functionsの実装を修正するたびに gcloudコマンドを叩いてそれぞれの関数をデプロイしていました。
今回のCloud Build導入後は、リモートリポジトリへpushすればデプロイが自動で行われるので手間やストレスも低減することができるようになりました。
GitHub Actionsを組み合わせれば自動テストもできたりするので、CI/CD環境構築に大いに役立ちそうですね。この記事がどなたかのお役に立てたら幸いです。それでは。