Cloud Deployのイメージだけでも掴みたい
はじめに
2024年11月22日に行われた「Jagu'e'r Cloud Native #16 ハイブリッド Meetup ~学びの秋 ・食欲の秋・読書の秋 ビアバッシュLT ~」というイベントで話した内容を元にしています。
存在だけ知っていたCloud Deployを実際に使ってみてどんな感じだったのかをゆるく発表しました。
「Google CloudでCI/CDしたいならCloud Buildがあるじゃん。なんでCloud Deploy使うの?何がいいの?」 と疑問に思われてる方がこの記事を読んで、ざっくりとイメージを掴んでいただけれなと思い書いてます。
読み手の想定
- Cloud Buildは知っている/使っている。
- Cloud Deployは知らない/名前だけ知っている。
- Cloud Deploy全然知らないからイメージだけでも掴みたい。
書いてないこと
以下のことは書いてないです。
- Cloud Deployの詳しいこと(使い方等)。
- Skaffold[1]について。
なんでCloud Deploy使う?
そもそも、
Google Cloudには、Cloud BuildというCI/CDプラットフォームがあるのに、なんでCloud Deployを使うんだろうと疑問に思っていました。
ここについては、上記記事がめちゃくちゃわかりやすかったです。
なるほど。つまり、
CIとCDの両方をCloud Buildだけでやっていると実装が複雑になっていき、むしろ開発の足枷になってしまう。そこでCI部分はCloud Buildでやることにして、CD部分はCloud Deployに任せよう。
という感じです。
じゃあそのCloud Deployって?
Cloud Deployとは、"あらかじめ設定した手順に沿って、複数の環境(開発、テスト、本番など)へアプリケーションを自動的に配信してくれるマネージド サービス" です。
※ 対象サービスは、2024/12/1時点でGoogle Kubernetes Engine、Cloud Run、GKE Enterpriseのみです。
たとえば、Cloud Deployでは以下のような設定ができ、設定した通りにデプロイしてくれます。
# Cloud Runサービスを想定
1. ターゲットを決める。
例)検証用と本番用をターゲットにする。
2. 各ターゲットごとの設定をする。
例)Cloud Runサービスの設定(最大インスタンス数 etc.)や環境変数などをターゲットごとに設定する。
3. デプロイ順序を決める。
例)
1. まず検証にデプロイ
2. 次に本番にデプロイ
デフォルト設定の場合、検証デプロイ→本番デプロイの流れは自動的には進みません。自分たちでPromote
を実行する必要があります。
設定すれば、指定した時間経過後に自動で本番デプロイに進むようにもできます[2]。
本番デプロイ前に承認プロセスを設置することもできます[3]。
※Cloud DeployはSkaffoldというツールを使用してデプロイパイプラインを実現(各ターゲットで環境差分を持たせたり)しているのですが、イメージだけ掴むのには必要ないと思ってあえて登場させていません🙇
これはCloud Deployのコンソールをスクショした画像です。
stgからprodに矢印が開かれているのがわかると思います。これはstg -> prodという順序となるようにCloud Deployに設定したからです。stgに表示されている「プロモート」という文字をクリックするとprodへのデプロイが実行されます。すでに説明しましたが、ここを自動でやったり承認というプロセスを入れることもできます。
Cloud Buildとの棲み分け
Cloud Buildとの棲み分けですが、こんな感じです。
- Cloud Buildからイメージをビルド・プッシュしてアーティファクトを作る。
- Cloud BuildからCloud Deployを実行して、あらかじめ設定したデプロイパイプラインを走らせる。
つまり、Cloud BuildはCloud Deployを動かす基盤として存在します。
(スライドのいらすとのイメージです。→裏にCloud BuildがいてCloud Deployを操っている。)
Cloud Deploy使ってみて
実際に開発中のプロジェクトでCloud Deployを使ってみて。
もともと、Cloud BuildでイメージのビルドからCloud Runのデプロイまでやっていたのですが、Cloud Runのデプロイの部分はCloud Deployに任せてみました。
良かった点
- 環境ごとの設定をCloud Deploy (+Skaffold)に任せることができるので、Cloud Build自体の設定がシンプルになった。←これが一番嬉しかったかも。
- デプロイの可視化ができる。
- 各環境が同じパイプラインで繋がっているので、リリースの管理が簡単になった。
- Cloud Buildのトリガーを環境ごとに複数用意しなくてよくなったり
- 今どこの環境にデプロイされているか
困った点?・困りそうな点?
- もともととても単純なリリースフローだったため、too muchだった。
- E2Eテストや承認といったプロセスが組み込まれているちゃんとしたリリースフローの場合はめちゃめちゃ活躍すると思う。
- Cloud FunctionsなどのCloud Deployに対応してないリソースがある場合はどうするんだろうと思った。
まとめ
この記事を読んで持ち帰ってもらいことをまとめます。
- Cloud BuildだけでCI/CDをするとどんどん複雑になってしまう。
- なので、Cloud BuildはCI、Cloud DeployはCDという役割分けをする。
- Cloud BuildからCloud Deployを実行する。
追記
実際に開発中のプロジェクトでCloud Deployを使ってていろいろわかってきたので、また具体的なこととか記事にしたい。
参考
以下の記事がすごく参考になりました。
Cloud Runの本ですが、以下の本のハンズオンもすごく参考にしました。
(本自体はCloud Runについての参考になる知見が詰まっていて、Cloud Run使ってる方にめちゃめちゃおすすめです。)
なんと著者のお二人が登壇した場にいらっしゃった。サインもらうの忘れてしまった。
ていうか参考にした記事を書いた人もイベントにたくさんいた。すごい。ありがたや。
Discussion
カスタムターゲット使えばできるみたいです。
(Cloud Deployでやるメリットがあるかは...)
そんなのがあるのか。ありがとうございます🙇♂️