こんにちは Development Team インターンの木村です。
先日、GCPからCloud Deployというコンテナデプロイのマネージメントサービスが発表されました。
今回の記事では、Cloud Deployにはどのような機能があるか、実際に触ってみてどうだったか、他のツールと比較した時にどうかなどの知見を共有できればと思います。 (なお、このプロダクトは9月ごろにGCPから発表があり、執筆時の12月の段階ではまだプレビューの状態です。)
目次
Googele Cloud Deployとは
現在、多くのアプリケーションはコンテナでの管理が主流になっていると思います。
AI Shiftも2016年のサービス開始以来、メインとなるアプリケーションは全てGoogle Kubernetes Engine (GKE) 上に展開しています。
その中で必ず検討事項になってくるのが、コンテナのデプロイフローの管理、いわゆるCDの構築です。
例えば「あるアプリケーションをGKE上で動かしたい」と思った時には下記のような作業が必要になります。
- DockerイメージのBuild
- DockerイメージのPush
- クラスタへImageをApply
これらの操作を全て手動で実行していては効率が悪いので、これらのリリースプロセスを自動化してくれるような、CDツールなるものがこれまでもいくつか出てきました。
そして今回GCPから、CDツールとしては発のプロダクト「Cloud Deploy」が発表されました!
Cloud Deployの特徴
では具体的にCloud Deployの中身について見ていきましょう。( GCPの公式ドキュメントも併せて参照いただければと思います。)
Cloud DeployのCDの流れ
Cloud Deployではどのようにデプロイを行うのでしょうか。
デプロイフローを簡単にまとめると下記のようになります。
- Pipelineを構築
- 成果物を「release」という単位でまとめ、Pipelineの最初のターゲット環境へ乗せる
- 成果物を次の環境へ「Promote」する
1つ1つ見ていきましょう。
1.Pipelineの構築
まず、「Pipelineの構築」を行います。
ここでのPipelineは、各ターゲット環境にアプリケーションを配信するワークフローを指します。
よくあるデプロイフローとして、例えばアプリケーションのイメージがBuildされたら
- まずはDevelop環境へデプロイしテストを行い
- 問題なかったらStaging環境でテスト
- 最後に本番環境へデプロイ
といったフローを取ると思いますが、これらのフローがPipelineに相当します。
後ほど実際に見ていきますが、Cloud Deployにおいては、これらのPipelineはclouddeploy.yamlという専用のファイルで定義します。
2.releaseの作成
Pipelineの構築が終わったら、次に実際にPipelineに乗せる成果物のまとまりを決めます。Cloud Deployではデプロイする成果物のまとまりを「release」と呼んでおり、具体的にはアプリのDockerイメージや、そのイメージを含むDeployment等を指します。これらの成果物をまとめて、「release」としてデプロイする単位を定義しています。
これを実現するために、Cloud Deployでは内部的にSkaffoldというツールを使用しています。
Skaffoldはローカルのソースコードの変更を検知して自動でデプロイを行ってくれるツールです。Skaffoldにはskafold renderというコマンドがあり、これは複数のk8sマニフェストを1つのマニフェストとして出力してくれます。
Cloud Deployでは、このskaffold renderコマンドを用いて成果物をまとめる、つまり「release」の作成を実現しています。
実際には、これらreleaseの操作は簡単なgcloudコマンドで提供されており、ユーザーはこのコマンドを実行するだけで、先ほど作成したPipelineの最初のターゲット環境(develop環境等)へアプリケーションをデプロイすることができます。
とても簡単ですね!
3.次の環境へPromote
Pipelineの最初のターゲット環境(develop環境)で実際にテストをしてみて、問題が無かったら、次の環境へアプリケーションをデプロイします。この次の環境へデプロイする操作を、Cloud DeployではPromoteと呼んでいます。
こちらも後ほど見ますが、PromoteもGUIから非常に簡単に行うことができます。
これにより、「各環境へのリリースの度に、リリースコマンドを逐一叩いて...」といったような手動管理から解放されそうです!
さらに、Promoteに関しては
- Pipeline上の任意ターゲット環境へのロールバック
- Promoteに対する承認機能
- Promote画面でマニフェストの差分を確認可能
といった、リリースする際に欲しくなる機能も提供されています。
実際にPipelineを構築してみる
Cloud Deployの概要についてみてきました。
それでは実際にCloud Deployを触っていきましょう。下記のような設定で検証していきます。
- Go製のアプリケーションをDockerfileで管理
- 上記GoアプリをDeploymentとしてデプロイする
- dev、dev2 という二つのターゲット環境を用意し、「dev → dev2」へのPipelineを構築する
- localでgcloudコマンドを叩くことにより、検証
手順としては、下記のようになります。
- dev → dev2のデプロイPipelineを作成
- Skaffold.yamlの作成
- 1で作成したPipelineに対するreleaseを作成
1. dev → dev2のデプロイPipelineを作成
まずはPipelineの構築です。
clouddeploy.yamlというファイルを用意します。
apiVersion: deploy.cloud.google.com/v1beta1
kind: DeliveryPipeline
metadata:
name: deploypipeline-test
description: test deploy pipeline for sample-dev
serialPipeline:
stages:
- targetId: dev
profiles: []
- targetId: dev2
profiles: []
---
apiVersion: deploy.cloud.google.com/v1beta1
kind: Target
metadata:
name: dev
description: dev cluster
gke:
cluster: projects/[project_id]/locations/asia-northeast1-a/clusters/[[clustor_name]]
---
apiVersion: deploy.cloud.google.com/v1beta1
kind: Target
metadata:
name: dev2
description: dev2 cluster
gke:
cluster: projects/[project_id]/locations/asia-northeast1-a/clusters/[[clustor_name]]
このYamlファイルに対して、下記のコマンドによってPipelineを構築します。
$ gcloud beta deploy apply --file clouddeploy.yaml --region=us-central1 --project=[project_id]
2. Skaffold.yamlの作成
Pipelineを作成したので、実際にPipelineに乗せる成果物を定義していきます。
具体的にはskaffold.yamlファイルを設定していきます。
apiVersion: skaffold/v2beta10
kind: Config
metadata:
name: sample-skaffold
build:
tagPolicy:
sha256: {}
artifacts:
- image: asia.gcr.io/[project_id]/[image_path]
local:
push: false
useBuildkit: true
deploy:
kustomize:
paths:
- "overlays/dev"
上のyamlでは、GCR上にあるDockerイメージを使用する前提で書いています。
さらに、skaffoldはkustomizeやhelmなどのデプロイツールに対応などの様々なツールに対応しています。今回はkustomizeを用いた構成で行ってみました。
3.Pipelineに対するreleaseを作成
skaffold.yamlを作成したら、いよいよ下記のコマンドでPipelineに対してreleaseを行います。
$ gcloud beta deploy releases create test-deployment-v1 --project=[project_id] --region=us-central1 --delivery-pipeline=deploypipeline-test
上記のように、特に指定をしなければコマンドを実行したカレントディレクトリ上のskaffold.yamlとclouddeploy.yamlをCloud Deployが探し、デプロイが開始されます。
これにより、最初のターゲット環境にskaffold.yamlで定義した成果物がデプロイされます!
最初のターゲット環境で問題がなければ、次の環境へPromoteです。こちらはGUIから行います。
今回は特に設定していませんが、このPromoteの段階に承認を持たせることもできます。
検証してみて、他ツールとの比較など
Cloud Deployを触ってみて、
- 簡単にCDを構築できる
- GUIから次の環境へのデプロイが簡単にできる
といった点がメリットに感じました。skaffold.yamlとclouddeploy.yamlの設定を記述する必要はありますが、ほぼそれだけでCDの設定が完成します。Cloud DeployはライトにCDを導入したい!というケースに特に向いていそうです。
ただし、既存の他のCDツールと比較した時には、
- GitOps ベース
- カナリアリリースもできるか
- メトリクスを基にrollbackできるか
- masterと本番の誤差をalertしてくれるか
といったような高度な機能はまだCloud Deployでは提供されていないようです。
まとめ
GCPから新しく発表されたCDツール、Cloud Deployを調査し、実際に触ってみました。
印象としては、とても簡単にCDを構築でき導入ハードルはかなり低そうだという印象を受けました。
一方で、デプロイの自動化とPipelineの構築を主としており、既存の他のCDツールに見られる種々の機能(カナリアリリース、自動rollback機能)は、まだないようです。
とはいえ、執筆段階ではまだPreview段階なので、今後の機能追加にも期待したいところです!