🚗
kubernetes運用におけるCICD
DevOps初心者がkubernetesの運用におけるCICDについてメモします。
現状
考え方や思想としてCIOpsとGitOpsの大きく2つがある。
GitOpsにシフトチェンジしている。
CIOps
CIツール上でImage作成からクラスターにapplyするまでCICDを一気通貫で行う。アプリケーションコードとマニフェストを同一リポジトリで管理するのが一般的。
メリット
- 構築が簡単
デメリット
- CICDを分離できない
- ブルーグリーンデプロイやカナリアデプロイなどのデプロイ手法を導入できない
- CIツールの持つ権限が大きくなる
- 本来はCIの責務範囲における権限のみでよいはずが、CDの責務範囲の権限を付与する必要がある
- ロールバックが難しい
GitOps
アプリケーションコードとマニフェストのリポジトリを分けてCICDを分離する。
メリット
- CIツールの権限を最小限にできる（CIOpsのデメリット解決）
- CICDを分離できる（CIOpsのデメリット解決）
- アプリケーションコードに変更がなく、マニフェストのみ変更したい場合はCDのみ実行してApplyできるため時間短縮になる
- デプロイ時点の状態がGitログに残っているためロールバックが容易
- manifestを管理しているリポジトリが
Single Source of Truthとなり、宣言的なリソース管理ができる
デメリット
- GitOpsツールの導入時のキャッチアップコスト
- FluxCD
- ArgoCD
- etc...
GitOpsのベストプラクティス
- アプリケーションコードとマニフェストのリポジトリを分けて管理する
リポジトリが同一の場合、マニフェストのみ変更したい場合もCIが実行されデプロイが効率的に実行できないことを防げる - マニフェストを管理するリポジトリの数を適切に選ぶ
モノレポ/チームごとなど開発チームの規模に応じて全員が自由にデプロイできるような構成を選択する - コミット前にマニフェストをテストする
例えば、Conftestなどでテストコードを書くなどマニフェストファイルのチェックを実施したほうがよい - 外部の変化の影響を受けて、マニフェストが変わってしまわないようにする
Gitにコミットする以外の手段でマニフェストを変更できないように制御することが重要。GitOpsツールのバージョン指定などツールも込。 - 機密情報の管理方法を計画する
Gitで管理すべきではない機密情報を選定し、やむを得ず手動オペレーションで管理することも想定する。
Discussion