kubernetesでデプロイを継続してやるために
•いつ誰がコマンド実施したかがわからない
•コマンド実施したことで、マニフェスト同士が衝突するかもしれない
•手作業でデプロイするのはめんどくさいし、ヒューマンエラーが起きやすい という課題がある
それを解決する手段を紹介していく
Push型のデプロイ CIOps
kubectl apply --filename を自動化しようと思った時、まず考えるのは「MasterブランチにFutureブランチをマージしたら本番環境にkubectl applyを実施」という方法だと思う
この自動化をCIツールで実行することをCIOpsという。
Pull型のデプロイ GitOps
Gitを使って入ればGitOpsというわけではなく、定義がある
1.宣言的であること：システム全体は宣言的に記述される必要がある
2.バージョン管理と不変：正規の望ましいシステムの状態はバージョン管理されている
3.自動的に取得：承認された変更はシステムに自動的に適用される
4.継続的な調整：ソフトウェアエージェントが正確さを保証し、乖離があった場合にアラートを出す
なぜわざわざGitOpsを選ぶのか
四つの定義のうち三つ目が大きな違いの一つである。pull型であることで次のようなメリットがある
セキュリティリスク低減
CIOpsはその性質上、書き込み権限が必要になる。そのため万が一乗っ取られた時、読み書きが可能になってしまう。
GitOpsは読めればPullできるので、乗っ取られたとして取られる権限が小さく、CIOpsよりは被害が少なく済むと考えられる。
CI•COが分離できる
CIOpsはCI,CDともにCIツールを用いるため、実行タイミング、スクリプトが同じになることもある。規模が大きくなってくると、「CIが大きいせいでデプロイが遅い」「CI•CDのスクリプトが長すぎて調整ができない、めんどくさい」となってしまう。
GitOpsでは専用デプロイツールを利用して、デプロイの情報を宣言的に管理することでCIとCDを分離できる。
Kubernetesのマニフェスト管理
実際の開発で、ほぼ似たようなマニフェストを描く機会があるだろう。少ないうちはいいが、規模が大きくなるとコピーアンドペーストし続けるのは現実的じゃない。そこでいろいろな管理方法やツールがあります。
Helm
簡単にいうと、他の人の作ったマニフェストをテンプレ的に使うことができる。
他の開発者が作ったカスタムコントローラ用のマニフェストを使う時に便利
helm installで他の人のCRがデプロイできる
実は
helm installを直接実行するのはGitOpsと相性が悪い。そこでArgoCDなど書くGitOpsの仕様に従って実行するか、CIを利用して生成したマニフェストをGitOpsで管理するなどの方法がある
Kustomize
環境ごとに異なるマニフェストの一部だけを管理したい。そんな時に使う方法。
具体的にはマニフェストの共通部分はbaseディレクトリで管理し、環境ごとの差分をoverlaysというディレクトリで管理する。
つまり同じようなマニフェストを作らないといけなくなっても、これを使えば差分だけ書けばいいのである！
kustomize build <ディレクトリ名＞ でBase部分とディレクトリ独自の部分をまとめて出力してくれる便利なコマンドがある。
マニフェストの設定
kustomization.yaml
resources:ベースとなるディレクトリ、ファイルを書く。Baseディレクトリや、そのディレクトリ固有のファイルを書く。
patches:ovrelaysでBaseの設定を上書きするのに使う。上書きで使用するディレクトリを書く。