CI/CD Pipeline for Minimalist

Transcript

1. CI/CD Pipeline for Minimalist

2. hello! I am Yoshimasa Hamada I am Web Developer and

   work for Zeals. You can find me at @panchan9 or @pannpers. 2

3. 実際に、Kubernetes 導入してますか？ （or 直近に導入予定） 3 1.

4. CD専用ツール使ってますか？ 4 2. • Spinnaker • Jenkins X • Argo

   CD • Flux by Weaveworks • Tekton • GoCD

5. Hard Way to introduce CD Tool in Initial Phase ✘

   CDツールの選択肢が多過ぎる ✘ そして、どれも多機能なので比較検討のコストが高い ✘ というかKubernetesだけでも、導入コスト高い

6. とはいえ、 CD Pipelineを構築していないと・・・

7. Problems ✘ k8s Contextを間違って、意図した環境とは異なる Manifestsをデプロイしてしまう ✘ Gitでコード管理されていない変更が行われている （しかも意図が分からない） ✘ デプロイ作業が属人化してしまい、新規メンバーの学習

   コストが高くなる

8. Don’t use kubectl by hand 8

9. どうすればよいか？

10. GitOps is current Best Practices https://www.weave.works/technologies/ci-cd-for-kubernetes/

11. GitOps is just Principles. How implement GitOps approach?

12. Summary of Problems ✘ k8s導入初期で最適なCD Pipeline構築は難しい ✘ 一方、マニュアルオペレーションはリスク大・・・ ✘ 理想はGitOps。あとはどう実現するか？

    ◦ できればラーニングコストが低く ◦ 複雑性をできるだけ排除した方法で

13. CI/CD Pipeline for Minimalist

14. まずは前提とゴールを整理 ✘ Git Branch Model どうする？ ✘ Project Layout は？（GCPを例にします）

    ✘ いきなりGitOpsとかできるん？

15. GitHub Flow 1. Git Branch Model Master Feature PipelineのTriggerを変えれば、Git FlowやGitLab

    Flowでも同じことができます

16. • zeals-dev • zeals-stg • zeals-prd • zeals-cr (container registry)

    Docker Imageを一元管理するProject 2. GCP Project Layout

17. CI Ops like GitOps !! 3. Workflow For more details

    about GitOps, Kubernetes anti-patterns: Let's do GitOps, not CIOps!

18. どういうことだってばよ！？

19. GitOpsが提唱する以下の原則には従う ✘ ApplicationやMiddlewareの設定は、Gitレポジトリで管 理しているものが絶対的な正であり、差異が発生しない ようにする （HPAによるPod数の際などは除く） ✘ kubectl を直接使用してデプロイを行わない

20. その一方で 『アンチパターン』とされている CI Opsを部分的に採用

21. 具体的には・・・ ✘ デプロイに必要なCredentialsをCIツールに渡すことを許容 する ✘ GCPであれば、CIツール用に作成したService Accountの JSONファイル ✘ これにはKubernetesマスターのAPIへ命令を送ることがで

    きる、とても強力な権限が付与されている

22. 要するに GitOpsの恩恵を受けつつ 使い慣れたCIツールを使うことで （あと、デプロイ用のちょっとした Shell Script） ラーニングコストも最小限に！！ 以下はCircleCIを例としています

23. それではここで Zealsの実際のCI/CD Pipelineを紹介

24. None
25. None

26. Point 1 ✘ PushされたFeatureブランチ専用のNamespaceを 作成し、デプロイする ✘ ローカルからport-forwardし、動作検証を行う ◦ cert-managerでTLS証明書を自動作成し、 外部からのエンドポイントも自動で用意したい

    ✘ CircleCIでは『ブランチの削除』をHookできないため、 毎回のジョブ実行時に存在するブランチと k8sのNamespaceを照合し、無ければ削除している
27. None

28. Point 2 ✘ masterブランチへのMergeコミットIDをDocker Imageのタ グとしてPushする e.g. zeals/hoge:98sie82 ✘ このへんはSkaffoldがやってくれるので、雑に

    skaffold run -p ${ENV} と実行するだけでOK
29. None

30. Point 3 ✘ StagingのジョブでPushしたDocker ImageをPull ✘ masterブランチへのGitタグ（v0.1.2）を Docker Imageのタグに付与してPushする ◦

    docker tag zeals/hoge:98sie82 zeals/hoge:v0.1.2 ◦ docker push zeals/hoge:v0.1.2 ✘ ImageのビルドはSkipするために、Skaffoldは run ではなく、 deploy コマンドを使う ◦ skaffold deploy -p ${ENV} --images=zeals/hoge:v0.1.2

31. これらを実行するための CircleCIのコンフィグや Shell Scriptは・・・

32. Tech Blogで公開します！！ （Comming Soon） https://tech.zeals.co.jp

33. Conclusion ✘ k8s導入の初期フェーズは使い慣れたCIツールでも、 わりといい感じのCI/CD Pipelineを作れる ✘ ただ、本格運用に必要な機能は不足 ◦ カナリアリリース ◦

    障害時のロールバック ◦ Git上のk8s Manifestと実際の値の変更検知 ✘ ある程度、k8s運用に慣れたタイミングで より高機能なCD専用ツールを導入しよう

34. thanks! Any questions? You can find me at @panchan9