記事概要
Kubernetes上における運用パターンの一つとしてGitOpsを利用する場合がある。
GitOpsにおけるブランチ戦略について検討する。
目指すポイント
- 環境毎のマニフェストをなるべく同じ場所で管理する
- helmのようなテンプレートエンジンを使わない
- 本番環境の運用は安全に行う。
GitOpsの実践方法
大きく分けてPull型とPush型のやり方がある。
Pull型とはArgoCDやFluxCD等のGitOpsツール上にGitアクセス情報を保持し、この情報をもってyamlを引っ張ってくるタイプのGitOps。
対してPush型とはKubernetesアクセス情報を自動化ツール上に保持し、kubectlコマンドでGitのCICD環境から能動的にapplyする方法である。
Pull型のメリット
- Kubernetesの外にアクセス情報を保つ必要がない
- ArgoCDの場合、Git上での差分比較に加えてArgoCDのUI上でKubernets上のマニフェストと差分比較ができる。
Push型のメリット
- ツール管理の手間が減る。
1. クラスタ毎にブランチを分ける
図1のようにクラスタ毎にブランチを分け、それぞれ同期するパターン。
1つのリリース単位毎にdev/stg等の下位のブランチを上位のブランチから切り直す。
このパターンを採用した場合、いくつかの課題がある。
問題点その１ – 複数のIssueに同時に対応できない
この問題は「モノリポ構成」を採用した場合や、リポジトリ内のマニフェストファイルが多い場合に多く発生する。
「モノリポ構成」とはIngressControllerやArgoCD等の管理者が同じコンポーネントを１つのGitOpsリポジトリにまとめてしまう構成のことを指す。
コンポーネント毎に一つのリポジトリの中で完全に切り離されたブランチで運用していくのもあり。
例)
問題点その１に対する回避策
- なるべくリポジトリを小さくする。
リポジトリがリリース単位だと考えるのが良さそう。
そのように考えると「モノリポ構成」は避けたほうが良い。
ベースブランチを複数作って「疑似モノリポ構成」というのもありかもしれない。 - Issue処理を同時並行で進めない。
問題点その２ – 下位ブランチの履歴が途切れる
切り直すと当然履歴が切れる。
GitOpsの良いところはGitで履歴管理ができることなので望ましくはない。
下位のクラスタの履歴なんていらない、という方は気にしなくても良いと思われる。
問題点その２に対する回避策
- 上位ブランチの履歴を見る。
- ブランチ名をリリース毎に変更し「stg-v1.1」等にする。
ブランチがきれいな状態に保たれるのがメリット。
問題点その３ – リリースサイクルを策定しない場合に対応できない
そもそもリリースサイクルがない場合もある。
緊急で修正したい場合にdevの変更内容が入らないように注意する必要がある。
devで検証した結果、部分的にリリースを見送る時にミスしやすい。
2. 開発はfeatureブランチで行う
「モノリポ構成」で生きるパターン
機能を開発する際はmainブランチからfeatureブランチを生やし、開発クラスタで検証し、開発が終わったらstgにマージする。
stgブランチで問題がなければmainにマージする。
リリースサイクルに縛られないので運用しやすい。
問題点その１ – 開発クラスタのブランチ切り替えが大変
同期設定を中央集権で基盤管理している場合、中央で切り替え処理を受け持たなければならない。
この手間はPush型か自律管理型のツール（FluxCD等）であれば発生しない問題。
3. mainブランチを中心に運用
本番、ステージング共にmainブランチを同期する。
クラスタ間の差分は原則kustomizeだけで定義する。
kustomizeのbaseディレクトリに変更を加える場合のみfeatureブランチを設定する。
mainへのマージだけで良いので運用の手数が少なく、非常に楽。
問題点その１ – baseブランチの変更がステージングクラスタを経由せずに直接本番クラスタに入ってしまう。
検証の機会が減るので危なくなりがち。
devブランチでmainにマージする前にコンフリクトチェックすると良さそう。
おまけ. Push型ツールを使う
そもそもブランチ戦略の話ではないが、こういうパターンもあるということで記載しておく。
ArgoCDやFluxCD等のPull型のGitOpsツールのメリットとしては２点ある。
- Kubernetesクラスタの操作権限を外に出さなくても良い
- ツール上でGitとKubernetes上の差分がないか、あるいは本当に反映されているか、をチェックできる
この内、1に関してはGithubSelfhostedRunner（※以前投稿した記事を参照）等のCICD実行環境をKubernetes上で動かしてしまうという方法がある。
Kubernetes上に立ち上げてしまえばServiceAccountに権限をつけるだけでKubernetes操作が可能となる。
ただしこの方法だとyamlの変更確認ができない。