GCPを使ってるならCloud Buildがいいんじゃない？
Why not use Cloud Build for GCP projects?
Continuous Integration/Continuous Delivery (CI/CD)について、筆者はこれまでCircleCIをよく使っていたのですが、最近GCPのCloud Buildを触る機会があり、思っていた以上に便利だったので、その紹介をしたいと思います。今、GCP + CircleCIを使っている人が、Cloud Buildを検討するきっかけになれば幸いです。
結論を一言で言うと、「GCPを使っているなら、Cloud Buildを使った方が便利だよ」ということ。当たり前のことかもしれませんが、便利だと感じた３つの点について、CircleCIと比較しながら紹介していきます。
便利なこと その１：１ステップ１コンテナ
CI/CDのフローを実装する時、一般的には「ビルド」「テスト」「デプロイ」といった複数のステップが必要になることが多いと思います。この時、ビルドやテストはGoが必要で、デプロイにはGoogle Cloud SDKが必要で、といった風に、複数のツールが必要になることになります。
CircleCIの場合、ジョブ単位で仮想マシンまたはDockerイメージを指定するため、これを実現するためには、ひとつの仮想マシン上に全てのツールをインストールしてあげるか、特定のDockerコンテナ（例えばGoogle Cloud SDKのDockerコンテナ）に残りのツールをインストールしてあげるといった実装が必要になります。他にも、全てのツールがインストールされたDockerイメージを用意してそれを使用するとか、ジョブを分けて書くといった方法でも実現が可能ですが、いずれも管理が面倒だったり、制約があってうまく実現できなかったりすることがあります。
一方で、Cloud Buildの場合、ステップ単位でイメージを指定するため、ビルドとテストはGoのコンテナ上で実行し、デプロイはGoogle Cloud SDKのコンテナ上で実行するといった書き方が簡単にでき、ツールのインストールといった面倒な準備が不要となります。例えばこんな感じ。すごいシンプルですね。
steps:
- name: 'golangci/golangci-lint'
id: 'lint'
args: ['golangci-lint', 'run']
- name: 'golang'
id: 'test'
args: ['go', 'test', './...', '-v']
- name: 'golang'
id: 'build'
args: ['go', 'build']
- name: 'gcr.io/cloud-builders/gcloud'
id: 'deploy'
args: ['app', 'deploy']便利なこと その２：設定ファイルの分割
CircleCIの場合、フローは .circleci/config.yml に記述する必要があります。一方で、Cloud Buildの場合は、トリガーを複数作成することができ、それぞれのトリガーに対して実行するファイル名を指定できるので、デフォルトの cloudbuild.yaml というファイル名でなくても構いません。ディレクトリも含め、 build/cloudbuild-prod.yaml 、 build/cloudbuild-dev.yaml といった風にカスタマイズできます。複数のプロジェクトに同じリポジトリのトリガーを作成することもできます。
実はCloud buildでは、CircleCIでは当たり前の条件分岐（「 master ブランチの場合だけ実行する」といった分岐）を書くことができません。その代わりといってはなんですが、 master ブランチの場合に実行するファイルと、それ以外のブランチの場合に実行するファイルを分けて記述することで、同等の挙動を実現することができます。
「条件分岐を書けない代わりに、設定ファイルを分割できる」という仕様は一長一短で、人によって好みが分かれるとは思いますが、設定ファイルが長くなってくると途端に読みにくさが倍増するので、分割できること自体はありがたいなぁと思います。
便利なこと その３：GCP IAMとの親和性
最後に持ってきましたが、一番便利なのはこれです。Cloud Buildは、実行時にCloud Buildのサービスアカウントをデフォルトで利用できるのです。
CircleCIの場合、CircleCI用のサービスアカウントを作成して、サービスアカウントの鍵をダウンロードして、環境変数に鍵を設定して、それを実行中に読み込んで、 gcloud コマンドで認証して、と複数の手順が必要でしたが、Cloud Buildなら面倒な初期設定がごっそり不要になります。
GCPを使用しているのであれば、GAEへのデプロイや、GCPのデータベースに接続するテスト、KMSを用いた秘匿情報の暗号/複合等々、何かとGCPのサービスに依存することが多くありますが、Cloud Buildなら自動的に作成されるCloud Buildのサービスアカウントに必要な権限を付与してあげるだけ。これはとても楽ちんですね。
本記事では、CircleCIと比べたCloud Buildの便利な点を３つ紹介しました。ただ、今回は触れませんでしたが、Cloud Buildがいまいちな点ももちろんあります（キャッシュ機能がない等）。また、GitHubとの連携については、GitHub Actionsなども出てきているので、それぞれの特徴を知って、自分に合ったサービスを見つけてください。
