CI/CD Pipeline for Minimalist
by
pannpers
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
CI/CD Pipeline for Minimalist
Slide 2
Slide 2 text
hello! I am Yoshimasa Hamada I am Web Developer and work for Zeals. You can find me at @panchan9 or @pannpers. 2
Slide 3
Slide 3 text
実際に、Kubernetes 導入してますか? (or 直近に導入予定) 3 1.
Slide 4
Slide 4 text
CD専用ツール使ってますか? 4 2. ● Spinnaker ● Jenkins X ● Argo CD ● Flux by Weaveworks ● Tekton ● GoCD
Slide 5
Slide 5 text
Hard Way to introduce CD Tool in Initial Phase ✘ CDツールの選択肢が多過ぎる ✘ そして、どれも多機能なので比較検討のコストが高い ✘ というかKubernetesだけでも、導入コスト高い
Slide 6
Slide 6 text
とはいえ、 CD Pipelineを構築していないと・・・
Slide 7
Slide 7 text
Problems ✘ k8s Contextを間違って、意図した環境とは異なる Manifestsをデプロイしてしまう ✘ Gitでコード管理されていない変更が行われている (しかも意図が分からない) ✘ デプロイ作業が属人化してしまい、新規メンバーの学習 コストが高くなる
Slide 8
Slide 8 text
Don’t use kubectl by hand 8
Slide 9
Slide 9 text
どうすればよいか?
Slide 10
Slide 10 text
GitOps is current Best Practices https://www.weave.works/technologies/ci-cd-for-kubernetes/
Slide 11
Slide 11 text
GitOps is just Principles. How implement GitOps approach?
Slide 12
Slide 12 text
Summary of Problems ✘ k8s導入初期で最適なCD Pipeline構築は難しい ✘ 一方、マニュアルオペレーションはリスク大・・・ ✘ 理想はGitOps。あとはどう実現するか? ○ できればラーニングコストが低く ○ 複雑性をできるだけ排除した方法で
Slide 13
Slide 13 text
CI/CD Pipeline for Minimalist
Slide 14
Slide 14 text
まずは前提とゴールを整理 ✘ Git Branch Model どうする? ✘ Project Layout は?(GCPを例にします) ✘ いきなりGitOpsとかできるん?
Slide 15
Slide 15 text
GitHub Flow 1. Git Branch Model Master Feature PipelineのTriggerを変えれば、Git FlowやGitLab Flowでも同じことができます
Slide 16
Slide 16 text
● zeals-dev ● zeals-stg ● zeals-prd ● zeals-cr (container registry) Docker Imageを一元管理するProject 2. GCP Project Layout
Slide 17
Slide 17 text
CI Ops like GitOps !! 3. Workflow For more details about GitOps, Kubernetes anti-patterns: Let's do GitOps, not CIOps!
Slide 18
Slide 18 text
どういうことだってばよ!?
Slide 19
Slide 19 text
GitOpsが提唱する以下の原則には従う ✘ ApplicationやMiddlewareの設定は、Gitレポジトリで管 理しているものが絶対的な正であり、差異が発生しない ようにする (HPAによるPod数の際などは除く) ✘ kubectl を直接使用してデプロイを行わない
Slide 20
Slide 20 text
その一方で 『アンチパターン』とされている CI Opsを部分的に採用
Slide 21
Slide 21 text
具体的には・・・ ✘ デプロイに必要なCredentialsをCIツールに渡すことを許容 する ✘ GCPであれば、CIツール用に作成したService Accountの JSONファイル ✘ これにはKubernetesマスターのAPIへ命令を送ることがで きる、とても強力な権限が付与されている
Slide 22
Slide 22 text
要するに GitOpsの恩恵を受けつつ 使い慣れたCIツールを使うことで (あと、デプロイ用のちょっとした Shell Script) ラーニングコストも最小限に!! 以下はCircleCIを例としています
Slide 23
Slide 23 text
それではここで Zealsの実際のCI/CD Pipelineを紹介
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
Point 1 ✘ PushされたFeatureブランチ専用のNamespaceを 作成し、デプロイする ✘ ローカルからport-forwardし、動作検証を行う ○ cert-managerでTLS証明書を自動作成し、 外部からのエンドポイントも自動で用意したい ✘ CircleCIでは『ブランチの削除』をHookできないため、 毎回のジョブ実行時に存在するブランチと k8sのNamespaceを照合し、無ければ削除している
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
Point 2 ✘ masterブランチへのMergeコミットIDをDocker Imageのタ グとしてPushする e.g. zeals/hoge:98sie82 ✘ このへんはSkaffoldがやってくれるので、雑に skaffold run -p ${ENV} と実行するだけでOK
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
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
Slide 31
Slide 31 text
これらを実行するための CircleCIのコンフィグや Shell Scriptは・・・
Slide 32
Slide 32 text
Tech Blogで公開します!! (Comming Soon) https://tech.zeals.co.jp
Slide 33
Slide 33 text
Conclusion ✘ k8s導入の初期フェーズは使い慣れたCIツールでも、 わりといい感じのCI/CD Pipelineを作れる ✘ ただ、本格運用に必要な機能は不足 ○ カナリアリリース ○ 障害時のロールバック ○ Git上のk8s Manifestと実際の値の変更検知 ✘ ある程度、k8s運用に慣れたタイミングで より高機能なCD専用ツールを導入しよう
Slide 34
Slide 34 text
thanks! Any questions? You can find me at @panchan9