GitOpsと自動化｜クラウドインフラ

🎓 レベル：発展　|　重要度：B（推奨）

📎 前提：CI/CDとは・パイプライン　|　関連：Kubernetesの全体像（宣言的・調整ループ）・IaCとは・宣言的構成

要点（BLUF）

GitOps＝git を「望ましい状態」の唯一の真実とし、クラスタ内のエージェントが現実を git へ自動で寄せ続ける運用。デプロイが「git に merge する」行為になる。
従来CIのpush型（CIがクラスタへ押し込む）に対し、GitOps はpull型（クラスタ内エージェントが git を見に行き同期）。認証情報を外に出さず、ドリフトも自動是正。
本質は K8s の調整ループ（Kubernetesの全体像（宣言的・調整ループ））とIaCの宣言（IaCとは・宣言的構成）を、git を基準点にして合体させたもの。

概念 ── git が真実の源

これまで見た2つの「宣言と収束」——K8s（望ましい状態へ収束）とIaC（コードへ収束）——を、git リポジトリという1点に束ねるのが GitOps です。クラスタの「あるべき姿」を全部 git に置き、git＝正とする。人は git を変えるだけ。反映はエージェントがやる。

flowchart LR
    dev["開発者"] -->|"PR → merge"| repo["git（望ましい状態の真実）"]
    agent["クラスタ内エージェント（Argo CD等）"] -->|"git を監視"| repo
    agent -->|"差分を検知して適用（pull）"| cluster["Kubernetes クラスタ"]
    cluster -->|"現状を読む"| agent
    agent -->|"手で変えられたら git へ戻す（自動是正）"| cluster

仕組み ── push型と pull型

従来CIのpush型：CI パイプライン（CI/CDとは・パイプライン）がクラスタの認証情報を持ち、外から kubectl apply を押し込む。CI が本番への強い権限を持つのがリスク。

GitOpsのpull型：クラスタ内のエージェント（Argo CD・Flux 等・要最新確認）が git を監視し、差分があれば自分で取り込んで適用する。クラスタの権限が外に出ず、誰がいつ何を変えたかは git 履歴が語る。

	push型（従来CD）	pull型（GitOps）
適用の主体	外部のCI	クラスタ内エージェント
クラスタ権限	CIが保持（外に出る）	クラスタ内に留まる
ドリフト是正	手動/別途	自動（gitへ収束）
監査	CIログ	git履歴がそのまま監査

仕組み ── 自動同期とドリフト是正

GitOps エージェントは調整ループを回し続けます。「git の宣言」と「クラスタの現実」を比較し、ズレたら git 側へ寄せる。誰かが手で kubectl edit してもエージェントがgit の状態へ戻すので、ドリフト（IaCとは・宣言的構成）が構造的に起きません。

ロールバックも「git を前のコミットに戻す（revert）」だけ。デプロイの履歴＝gitの履歴になり、git revert が即ロールバックになります。

なぜ GitOps なのか

単一の真実のため：「本番がどうあるべきか」が git 1か所に集約。複数ツール・手作業に散らばらない。
権限を縮めるため：本番への適用権をクラスタ内に閉じ込め、外部CIに強権を持たせない。攻撃面が小さい（責任共有の利用者側責務＝責任共有モデルとリージョン/AZ）。
監査とロールバックのため：すべての変更が PR とコミットになる。レビューでき、revert で戻せる。事故対応（インシデント対応とポストモーテム）が速い。

⚠️ よくある誤解・落とし穴

「GitOps なのに本番を手で kubectl edit」→ エージェントが git 状態へ戻し、手変更は消える。変更は必ず git 経由。
「秘密情報を git に平文」→ GitOpsでも厳禁。Sealed Secrets・外部シークレットストア等で暗号化して扱う（ConfigMap・Secret・ボリューム・要最新確認）。
「アプリのコードと宣言（manifest）を同じ動きで扱う」→ アプリ用リポジトリと構成（GitOps）用リポジトリを分けると、ビルドとデプロイの責務が整理される。
「pull型にすればCIは不要」→ ビルド・テスト・イメージ作成のCI（CI/CDとは・パイプライン）は依然必要。GitOpsが置き換えるのはデプロイ（CD）の届け方。
「同期の競合・自動同期の暴走を放置」→ 自動同期の範囲・承認ゲートを設計する。重要環境は手動同期も選択肢。

対応ラボ

なし（運用設計トピック）。土台となる宣言は Pod・Deployment・ReplicaSet・Terraformの基礎（HCL・state）のラボ。GitOps エージェント（Argo CD/Flux）の導入はクラスタ前提のため参照に留める（要最新確認）。