GitOps

GitOps とは?

GitOps は、Git リポジトリを唯一の信頼できる情報源（Single Source of Truth）とし、すべてのインフラ・アプリケーション設定を宣言的に管理する運用フレームワークです。 望ましい状態をコード化して Git に保存し、自動ツール（Argo CD、Flux など）が現在の状態を目指した状態に自動調整します。

ひとことで言うと： インフラ管理を「コードのプルリクエスト」で行うアプローチ。手作業の SSH ログインは一切不要です。

ポイントまとめ：

• 何をするものか： Git でインフラ設定を管理し、自動的に本番環境に反映
• なぜ必要か： 安全な変更管理、完全な監査ログ、迅速なロールバック、人為的ミスの排除
• 誰が使うか： Kubernetes 運用企業、DevOps チーム、マイクロサービス企業

なぜ重要か

従来のインフラ運用では、DevOps エンジニアが SSH で本番サーバーに直接ログイン・設定変更していました。これは ドリフト （本来の状態からのズレ）を引き起こし、障害原因特定が困難でした。GitOps は Git に「望ましい状態」を記録することで、常に環境が Git と一致した状態を維持。障害時は Git を戻すだけで復旧完了します。

Kubernetes のような複雑なインフラでは、GitOps がなければ管理不可能といっても過言ではありません。

仕組みをわかりやすく解説

GitOps のワークフローはシンプルです：

1. 定義： Kubernetes マニフェスト or Terraform で「3 レプリカで実行したい」と記述し Git に保存。

2. 提案： プルリクエストで変更を提案。他メンバーがレビュー・承認。

3. マージ： メインブランチにマージすると、自動的に本番環境に適用。

4. 監視： GitOps エージェント（Argo CD など）が常に Git の状態と現在の環境を比較。ズレを検出したら自動修正。

この流れにより、変更履歴は完全に Git に記録され、「誰が、いつ、何を変更したか」が明確。セキュリティ・コンプライアンス要件も自動的に満たされます。

実際の活用シーン

マルチクラスター管理

AWS、Azure、オンプレミスなど複数環境を一つの Git リポジトリで一元管理。環境間の一貫性を保証。

本番環境のロールバック

問題が発生 → Git で前のコミットにリバート → 自動的に環境が復旧。数秒で完了。

環境構築の自動化

新しいステージング環境が必要 → Git ブランチ作成 → PR マージ → 自動構築完了。手作業なし。

セキュリティポリシー強制

Pod セキュリティポリシー、ネットワークポリシーを Git で定義。変更は PR でチェック・承認してから反映。

メリットと注意点

GitOps の最大のメリットは 安全性と可視性 です。すべての変更が Git 記録され、誰でも確認可能。また、ロールバックが簡単。問題が発生したら Git をリバートするだけ。さらに 人為的ミスが減少 し、セキュリティ脆弱性も PR レビュー時に検出できます。

注意点は シークレット管理の複雑さ です。DB パスワードなどを Git に保存できないため、Sealed Secrets や HashiCorp Vault が必須。また、Git のみ依存のリスク もあり、Git サーバーが障害時は環境変更が不可能。バックアップ・リカバリ計画が必要です。

関連用語

• Infrastructure as Code — インフラを code で管理する哲学。GitOps の基礎
• Kubernetes — GitOps が最も活躍するコンテナオーケストレーション
• CI/CD — GitOps は CD（継続的デプロイメント）の進化形
• Argo CD — Kubernetes 向けの最人気 GitOps ツール
• DevOps — 開発と運用の統合。GitOps はその実現手段

よくある質問

Q: GitOps と DevOps の違いは？ A: DevOps は文化・自動化の総称。GitOps は「Git を信頼できる情報源とする」という具体的な方法論・ツール群。DevOps の実装手段と言えます。

Q: Pod が勝手に削除された場合、GitOps が復旧してくれる？ A: はい。Argo CD が常に監視しており、Git 定義と違う状態を検出すると自動修正します。

Q: サーバーに直接 SSH ログインして設定変更したら？ A: そうすると Git の定義と環境がズレてしまい、GitOps の利点が失われます。基本的に禁止。すべての変更は Git 経由にすべきです。