手順書どおりにデプロイしたはずなのに、本番の設定だけが少し違っている。
調べてみると、誰かが急ぎで直接いじった変更が、どこにも記録されずに残っていた。
「いま本番がどうなっているか」を、コードを見ても答えられない状態は、じわじわとチームの足を引っ張ります。
その答えの置き場を Git に決めてしまおう、というのが GitOps の発想。
本番の状態を確かめたいとき、まずどこを見に行っていますか？
GitOpsは「望む状態」をGitに置き、機械に合わせさせる
GitOps という言葉は、2017年に Weaveworks の Alexis Richardson 氏が提唱したものです。
いまは CNCF の GitOps Working Group が、OpenGitOps として4つの原則に整理している。
- 宣言的（Declarative）：望む状態を、手順ではなく「あるべき姿」として書く
- バージョン管理され不変（Versioned and Immutable）：望む状態を書き換えられない形で保存し、履歴をすべて残す
- 自動で取り込まれる（Pulled Automatically）：ソフトウェアのエージェントが、望む状態の宣言を自分で取りに行く
- 継続的に照合される（Continuously Reconciled）：エージェントが実際の状態を見張り続け、望む状態に合わせようとする
並べてみると、Git は「作業の記録」ではなく「本番のあるべき姿」の置き場になっていることが分かります。
人がサーバーに入って直すのではなく、機械が Git の内容に本番を合わせにいく。
この向きの逆転が、GitOps のいちばん大事なところなのです。
原則の原文はOpenGitOpsで公開されています。
従来のデプロイとの違いは「押し込む」か「取りに来る」か
ビルドとテストを流すパイプラインの最後で、デプロイのコマンドを実行する形は、多くの現場でおなじみ。
この場合、パイプラインが本番環境へ変更を押し込む（push）向きになる。
裏を返すと、パイプラインに本番環境を操作できる強い権限を持たせる必要が出てきます。
GitOps の原則が求めるのは、その逆の向き。
本番の側にいるエージェントが Git を見に行き、望む状態を取りに来る（pull）形です。
さらに4つめの原則にあるとおり、取り込んで終わりではなく、実際の状態を見張り続けます。
誰かが本番を直接いじってずれが生まれても、エージェントがそれに気づけるわけです。
デプロイが一回きりの作業ではなく、ずれを見張り続ける常駐の仕事に変わるという違い。
ビルドとテストを回す土台そのものは、CI 入門の記事で整理しています。
Kubernetesでは Argo CD と Flux が代表的
この「見張って合わせる」エージェントを担う代表的なツールが、Argo CD と Flux。
どちらも CNCF で卒業（Graduated）の段階に到達したプロジェクトで、Flux は2022年11月、Argo は2022年12月に発表されています。
Argo CD の公式ドキュメントは、自身を「Kubernetes のための宣言的な GitOps 継続的デリバリーツール」と説明している。
仕組みとしては、実行中のアプリケーションを見張り、今の状態を Git に書かれた目標の状態と比べ続けるコントローラーとして動きます。
両者がずれていれば OutOfSync として扱われ、自動または手動で目標の状態へ同期し直せる。
見張る対象は、たとえば次のような設定で登録するイメージです。
# Argo CD の Application の例（一部）
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
# ... 省略（同期ポリシーなど）どのリポジトリのどのパスを、どのクラスターへ合わせるかを宣言しているだけ、という点が GitOps らしいところ。
どちらのツールを選ぶかより先に、「本番の正解は Git にある」とチームで合意できているかが効いてくる。
仕組みの説明はArgo CD の公式ドキュメントにまとまっています。
導入でつまずきやすいところ
便利に見える一方で、始めてから気づく落とし穴もいくつかある。
1つめはシークレットの扱い。
望む状態をすべて Git に置くといっても、パスワードや API キーをそのままリポジトリに入れるわけにはいきません。
暗号化してから置くのか、外部の保管庫から取り込むのかを、最初に決めておく必要があります。
2つめは、緊急時に本番を直接直したくなる誘惑。
Argo CD の場合、自動同期を有効にしただけでは本番への直接の変更は同期のきっかけにならず、自己修復（self-heal）まで有効にしてはじめて Git の状態へ引き戻される。
急ぎの修正も Git への変更として流すと決めておかないと、仕組みとチームの習慣がぶつかります。
3つめは、アプリケーションのコードと環境の設定を同じリポジトリに置くか、分けるかという設計。
Argo CD のベストプラクティスは分けることを強く勧めていて、マニフェストだけを直したいときに CI のビルド全体を走らせずに済む、という理由を挙げています。
同じリポジトリにマニフェストの変更を書き戻す形にすると、ビルドとコミットが互いを呼び合って止まらなくなるおそれも指摘されているのです。
最後に
GitOps は、特定のツールの名前ではありませんでした。
望む状態を Git に宣言し、機械がそこへ本番を合わせ続けるという運用の形。
本番の正解を探しに行く場所が一つに決まるだけで、変更の履歴も差し戻しも Git の操作で説明できるようになります。
DevOps 全体の中での位置づけは、DevOps とは何かを扱った記事で整理しました。
私自身も学びながらですが、まずは小さなリポジトリで「Git を見て合わせる」流れを一度なぞってみるのがよさそう。
以上です。
コメントを残す