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