さよならSpinnaker

よろしくGitOps

（MF KESSAI社内発表版）

Index

• MF KESSAIとGKEへのDeployの歴史
  • Spinnaker導入によるオートメーション革命時代の幕開け
  • Spinnaker導入後のツラミ
  • 解決したいこと＆理想
  • GitOpsの採用と理由
  • GitOpsの手段としてCloud Builderを選択した理由
• Gitops用のコード大公開

MF KESSAIとGKEへのDeployの歴史

1.  なんだかんだJenkins時代（2017/03 ~ 2019/04）
   1.  Circle CIでBuild & Push
   2.  Jenkins on GKEでポチッと
2. Spinnakerによるオートメーション革命時代（2019/04 ~ 2020/05）
   1. CircleCI or Cloud BuilderでBuild & Push
   2. Spinnakerで自動デプロイ
3. Gitops: 僕たちは最初からこれが理想だった（2020/05 ~ 現在）
   1. Cloud BuilderでBuild & Push
   2. GithubでApprove & Mergeで自動デプロイ

Spinnaker導入によるオートメーション革命時代の幕開け

Spinnakerの導入によって、僕たちは「ポチり忘れ」「ポチる恐怖」「ポチるのめんどくさい」時代を卒業して、全てから解放された。

しかしその時はまだこのあと来るペインには気づいていませんでした。
そう銀の弾丸など存在しない事を改めて気付かされました。

Spinnaker導入後のツラミ

• SpinnakerはGCRの最新のタグを知れるが、manifest全体を管理するk8s repoには反映されない為、k8s repoでは `:latest` の様に汎用的なタグを指定する事になる問題（解決は出来る
• Spinnakerでrollbackや意図的に止めた場合、 SREがGithubの最新の状態を取得してマニフェストに変更を加えたあとApplyすると、意図せぬバージョンがデプロイされる事故が起きる
• 特にBlue Green(Red Black)を使う場合はSpinnakerにトラブルが発生すると、気軽にデプロイする方法が無い。
• Spinnakerの運用コストが高い
• Spinnakerクラスタのコストが結構高い

解決したいこと＆理想

• サーバレス（物を持たない）
•  k8sのManifestのリポジトリの状態とGKEで運用しているバージョンなどを同じにする。
• デプロイする仕組みに何か問題起きてもコンソール触って直接変更する方法が使えるSpinnakerの運用コストが高い
• githubでRollbackまで管理

GitOpsの採用と理由

• Githubは普段の開発で使い慣れたツール
• GithubのPull Requestでimage tagのバージョン管理
• Githubは稼働率100%ではない。しかし更に他のツールを導入する事でより障害発生率は上がるので、Githubだけの方が結果障害率を低く抑えれる 

GitOpsの手段としてCloud Builderを選択した理由

• Cloud Build を使用した GitOps スタイルの継続的デリバリーの存在
• Cloud Builderにある程度コード（Shell）を書く必要はあるが、その後の運用コストを考えると、低コスト
• GKEやGithub Repoとの連携が容易
• ArgoCDも考えたがSpinnakerを卒業したい理由の一つに運用するものを減らしたいという理由もあったので不採用

GitOps用のコード大公開

GCPでのGitOps時の流れなどは、Cloud Build を使用した GitOps スタイルの継続的デリバリーこちらを参考にしてください。

ここからは、以下２種類のリポジトリのコードを一部公開します。

1. アプリケーションリポジトリ（例えばGoのHTTPアプリ）
2. k8s manifestリポジトリ

デプロイの流れ

1. アプリケーションリポジトリで master ブランチにマージ
2. アプリケーションブランチのCloud Builderでk8s manifestに candidate_hoge ブランチを作成して、masterブランチに対してのPRを作成
3. k8sリポジトリの candidate_hoge にcommitが走る都度 hoge-stg環境へデプロイ
4. k8sリポジトリの candidate_hoge がmasterにマージされたら hoge-prod環境へデプロイ

簡単に書くとこの様な流れになります。

作成されるPRのイメージはこちらです。

RollbackをしたいときはRevertするだけ！

アプリケーションリポジトリのコード

まずアプリケーションの cloudbuild.yaml からお見せます。
master マージをトリガーに動く前提です。
また途中に出てくるPythonのコードも後述しています。

GitstでApplication Repoのサンプルを公開

cloudbuild.yamlの簡単な説明

1. sshを利用するのでkey取得
2. Docker Build
3. k8s repoをcloneしてcandidate_hogeをcheckout
4. 2でビルドした時のtagをk8s repoにpatchを当ててcommit
5. PR作成してレビュアーアサイン

Gitstでk8s repoのサンプルを公開

cloudbulild.yamlの簡単な流れ

1. hoge-prod/hoge-stgのcloud buildで起動
2. sshを利用するのでkey取得

3. kubectl kustomize <env> |  kubectl apply -f -

4. rollout待ち
5. slackで通知
6. Applicationリポジトリにrelease tagを作成