GitOps

なぜ「Git を正」にするのか

従来のデプロイは、CI の最後に手元やパイプラインから kubectl apply や helm upgrade を 外から押し込む（Push） やり方が主流でした。これには弱点があります。

• 実環境の状態がどこにも一元化されていない：「いま本番に何が入っているか」は誰かの手元の操作履歴やログにしか残らない。
• 手作業の割り込み（緊急の kubectl edit）で、リポジトリと実環境が静かにズレていく。
• ロールバックや監査が「人の記憶」頼りになりやすい。

GitOps はこれを反転させます。「あるべき状態」を Git に宣言的に書き、実環境をそこに合わせる。Git のコミット履歴がそのまま「いつ・誰が・何を・なぜ」の監査ログになり、git revert がロールバックになります。

4つの原則

OpenGITOPS（CNCF）が整理する GitOps の核は、次の4点です。

1. 宣言的（Declarative）：手順ではなく「望ましい状態」を記述する（kubectl run … ではなく Deployment の YAML）。
2. バージョン管理され不変（Versioned & Immutable）：その状態は Git に保存され、改ざんできない履歴として残る。
3. 自動で取り込む（Pulled Automatically）：エージェントが望ましい状態を 自分から取りに行き、適用する。
4. 継続的に収束（Continuously Reconciled）：実環境を観測し、宣言と差があれば自動で一致させ続ける（一度きりではない）。

仕組み：Reconciliation ループ

中心にあるのは 収束ループ（reconciliation loop） です。クラスタ内に常駐するエージェント（Argo CD・Flux など）が、次を回し続けます。

1. 望ましい状態を取得：Git リポジトリの対象パスを監視（ポーリング or Webhook）。
2. 実際の状態を観測：クラスタの現状（実際に動いている Deployment 等）を取得。
3. 差分を計算：望ましい状態 と 実際の状態 を比較。
4. 収束（apply）：差があればエージェントが適用して一致させる。
5. これを繰り返す（継続的）。

# Git に置く「望ましい状態」の一例（Kubernetes Deployment）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3          # ここを 4 にして PR をマージ → エージェントが自動で 4 に収束
  template:
    spec:
      containers:
        - name: web
          image: registry.example.com/web:v1.4.2  # イメージタグの更新もコミットで

開発者がやることは Git を変えるだけ。replicas: 3 → 4 の PR をマージすれば、エージェントが差分を検知して本番を 4 レプリカに収束させます。CI（ビルド・テスト・イメージ作成）と CD（同期）が Git を境に分離 されるのもポイントです（/devops/ci-cd/）。

ドリフト検知と自己修復

ドリフト（drift） とは、実環境が Git の宣言からズレた状態のこと。誰かが手で kubectl scale した、別ツールが書き換えた、といった原因で起きます。

収束ループは差分を常に見ているので、ドリフトを 検知 できます。さらに設定次第で 自己修復（self-heal） ――Git の状態へ自動で引き戻す――も可能です。

Push 型デプロイとの違い

同じ CD でも、変更を 外から押し込む Push 型 と、内から取りに行く Pull 型 では性質が大きく異なります。

Kubernetes と相性が良い理由

GitOps が Kubernetes 文脈で広まったのは偶然ではありません。Kubernetes 自身が 「望ましい状態を宣言 → コントローラが収束させる」 という、GitOps と同じ思想で動いているからです（/devops/tools/kubernetes/）。

• すべてのリソースが 宣言的な YAML/API オブジェクト で表せる。
• 標準で 収束ループ を持つ（あるべき replica 数へ寄せ続ける等）。
• GitOps エージェントは、その「望ましい状態」の 供給源を Git にする だけ。

つまり GitOps は、Kubernetes の収束モデルを クラスタの外（Git）まで延長 したものと言えます。

つまずきポイント

• シークレットの扱い：パスワードや鍵を平文で Git に置くのは厳禁。Sealed Secrets・外部シークレットストア連携・暗号化（SOPS 等）で「暗号化された状態」だけをコミットする。
• リポジトリ構成：アプリのコードと、デプロイ用マニフェストの置き場を分ける構成（config リポジトリ分離）が定番。環境ごと（dev/stg/prod）の出し分けは Kustomize の overlay などで。
• 「自動」への過信：GitOps は 状態の同期 を自動化するもので、テストや段階的リリースまで肩代わりはしません。カナリア／ブルーグリーンなどの段階的展開（/devops/deployment-strategies/）や、収束結果を見るための監視（/devops/observability/）と組み合わせて初めて安全に回せます。

まとめ：何が変わるのか

• 正は Git：あるべき状態を宣言的に書き、唯一の真実とする。
• デプロイは Pull 型：エージェントが Git から取りに行き、自動で収束させる。
• ズレは検知：ドリフトを継続監視し、必要なら Git の状態へ引き戻す。
• 運用は PR ベース：変更・レビュー・監査・ロールバックがすべて Git のワークフローに乗る。

「サーバに入って直す」から「Git を直すと環境が直る」へ。これが GitOps がもたらす一番の発想転換です。