Google Cloud の CI/CD な話 2020
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 13 日目の記事です（偶然にも、昨年も 13日目の記事を書きました）。
CI/CDしてますか？ Customer Engineer の岩成です。
2020年 も残りわずか、こたつを囲んで CI/CD のアップデートを振り返りたい季節となってまいりました。
この記事では、2020 年の Google Cloud の CI/CD 関連アップデートについて紹介します。
[前半] プロダクトアップデート
[後半] 具体的な構成例
の二本立てでお送りしたいと思います。
プロダクトアップデート
Cloud Build
UI改善、DeveloperEX改善、後述する Cloud Build の機能を活かした各プロダクト側での継続的デプロイなどの統合が印象的でした。ちなみに、App Engine のデプロイプロセスでも、 Cloud Build が動いていたりします。
- Build History が利用可能。ビルド実行履歴を時系列で追いやすくなりました。
- Cloud Build Dashboard の改善が GA。直近のビルドのハイレベルな情報が把握しやすく。
- GitHub App triggers が GA。PR との連携がクリックぽちぽちで可能に。
- Slack & SMTP 通知機能が OSS として公開。
- Cloud Native Buildpacks を利用することで、Dockerfile 無しでのコンテナ作成が可能に（blog）。
- Manual Trigger をサポート。
- BigQuery notifier を通じて、Cloud Build metrics を BigQuery に転送可能に。Cloud Build のコンソールよりもより詳細な分析、MLでの活用を実施したい場合に。
Container Registry / Artifact Registry
Container Registry (GCR) の後継に当たる Artifact Registry がリリースされました。Artifact Registry は、コンテナイメージだけではなく、Maven や npm package もサポートします。
また、Docker Hub の pull リクエスト制限に備えてのブログも公開されています。気になる方はチェックしてみてください。
以下は、Artifact Registry のアップデートです。
Cloud Run / Google Kubernetes Engine
実は、Cloud Run / GKE のコンソールにも、 CI/CD 関連のアップデートが有ったのにお気づきでしょうか？コンソールからチャチャッと継続的デプロイを組めるので、シンプルに利用したい場合は特に便利です。
これらの機能の裏側では、 Cloud Build のトリガーが作られていたり、Clean up するための Cloud Scheduler が設定されています。ですので、この機能を使うことで、ベストプラクティスに則った Cloud Build トリガー設定を見るすることができます。この機能をそのまま使うことが無くても、試してみると新たな発見があるかもしれません :)
なお、Cloud Run x Cloud Native Buildpacks については、12/15「Cloud Run と Buildpacks で簡単にコンテナ使えるよ！ by kzs」で取り扱われる予定です。Stay Tuned!
実際の構成例
ここからは、上記の機能を組み合わせて、実際に CI/CD フローを組む例を紹介します。
Argo CD, GitLab, GitHub Actions, Spinnaker, Jenkins, 世の中にはたくさんの選択肢がありますが、既存のパイプラインが既に有ったりもしますので、慣れているものを選ぶのも一案です（※個人的見解）。権限管理を考えると、Google Cloud に閉じていると何かと気にすることが減るので、以下では Google Cloud に閉じた構成にしています。
環境面（=GCP プロジェクト） としては prod / staging / dev の 3 面、ブランチ戦略としては GitHub Flow を例として、Cloud Run への継続的デプロイをサンプルとして扱ってみましょう。
一番シンプルなフローは、main branch -> prod 環境、feature branches -> staging 環境という形でマッピングする事でしょう（feature branches も staging 環境に紐付けても良い）。
main branch については、コンソールからサクッと設定します。feature branches も同じ仕組みで staging 環境に継続的デプロイ出来ます。
Cloud Native Buildpacks を使うことで、Dockerfile 無しでビルドが可能です。Dockerfile を書かなくてよいので、お手軽 & ベースイメージのバージョンが古いなどといったリスクを避けられます。ただし、当然メリット・デメリットがあるので、「コンテナ化のメソッドの比較: Buildpacks、Jib、Dockerfile」などを参考にすると良いです。
次に、Dev 環境を考えましょう。開発中のものを他の開発者に共有したり、実際にクラウド上で確認したかったりもしますよね。そんな時は、Cloud Code を使って、ローカルのコードを使って、イメージをビルド / デプロイするとお手軽です。
ここまでで、main branch / feature branches の prod / staging 環境への継続的デプロイ、dev 環境への展開ができました。ただ、上記の方法だと、main ブランチへのマージ後、即 100 % のトラフィックが振られますので、それだと困っちゃう場合もありますね（Feature Flags / Toggles などで問題ないケースも有ると思います）。
カナリアリリースを行いたい場合は、 prod 環境にデプロイするトリガーの方に、—-no-traffic を渡してあげるように、main branch 向けのトリガーを修正しましょう。
これで、いきなり prod 環境に新しいコードが全反映されることは無くなりました。prod 環境へのカナリアリリースも、マニュアルですが出来ますね。
更に、「ServerlessNEG を使ってGoogle Cloud Load Balancing も使いたいんだ！」というケースも有るでしょう。そんな時は「A new Terraform module for serverless load balancing」を参考にしてみてください。
Cloud Run 以外にも、DB や NW などをどう管理するか、といった課題もあります。それらも含めて管理する場合は、Terraform などを検討すると良いですね。
余談: GKEの場合
GKE については、とてつもなく長くなりそうだったので、またの機会に記事を書かせていただこうと思いますが、少し思ったことだけでも。
GKE を使う場合は、アプリケーションコードにも、GKE クラスタや NW などのクラウドリソース、デプロイ用のマニフェスト、RBAC などのポリシーといった様々なものが存在し、それらを適切な粒度でリポジトリに分け、適切な粒度で環境にマッピングしていく必要があります。Terraform, Config Sync, Config Connector, Anthos Config Management, Kustomise, Cloud Code, Skaffold など、組織にあったフローを実現するための便利な機能 / ツールが徐々に揃ってきています。これらをうまく活用することで、チームの掌握範囲と環境への反映をうまくマッピングできたり、複数環境への差分を無駄なく管理できるでしょう。
まとめ
Cloud Build を始めとして、CI / CD に利用できる機能が実は色々追加されています。来年も、多くの便利な機能が出てくると思いますので、是非楽しみにお待ち下さい！
明日 14 日目は、Isobe san の「Google Cloud の API Gateway で API を管理しよう」です。今年、装いを新たに出てきた API Gateway をどのように活用するのか、楽しみですね！
