GitOps

GitOps とは

GitOps は、Git リポジトリをシステムの「あるべき状態」の唯一の正 (Single Source of Truth) とし、リポジトリの変更をトリガーにインフラやアプリケーションを自動的に同期させる運用手法である。Weaveworks の Alexis Richardson が 2017 年に提唱した。

従来の運用では、本番環境に SSH で入って設定を変更したり、管理コンソールから手動操作したりすることが日常的だった。GitOps はこれを根本から否定し、「Git に書かれていない変更は存在しない」という原則を徹底する。

基本原則

1. 宣言的な記述: システムの望ましい状態を YAML, HCL, CloudFormation テンプレートなどで宣言的に記述する
2. バージョン管理: すべての状態定義を Git リポジトリに格納し、変更履歴を完全に追跡可能にする
3. プルリクエストによる承認: 変更はプルリクエスト経由でレビュー・承認する。誰が、いつ、なぜ変更したかが記録に残る
4. 自動同期: 承認後、自動的にシステムに適用する

Push 型と Pull 型の比較

GitOps の実装には 2 つのアプローチがある。

観点	Push 型	Pull 型
仕組み	CI パイプラインがデプロイコマンドを実行	クラスター内のエージェントが Git をポーリング
代表的なツール	GitHub Actions, GitLab CI, CodePipeline	ArgoCD, Flux
クレデンシャル管理	CI 環境にデプロイ権限が必要	クラスター内で完結、外部に権限を渡さない
ドリフト検出	別途仕組みが必要	エージェントが常時監視し自動修復
適するケース	サーバーレス、小規模チーム	Kubernetes、大規模マルチクラスター

Pull 型はセキュリティ面で優位だ。CI 環境にクラスターへのデプロイ権限を持たせる必要がなく、クラスター内のエージェントが自律的に Git と同期する。一方、Push 型はシンプルで導入コストが低い。

AWS サーバーレスでの GitOps

SAM テンプレートを Git で管理し、main へのマージをトリガーに GitHub Actions で sam deploy を実行する構成は、Push 型 GitOps の実践だ。

# .github/workflows/deploy.yml
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/setup-sam@v2
      - run: sam deploy --no-confirm-changeset

CloudFormation のドリフト検出で、手動変更による乖離を検出できる。ただし、ドリフト検出は自動修復まではしないため、Pull 型の ArgoCD ほどの自律性はない。

GitOps と従来の CI/CD の違い

GitOps は CI/CD の上位概念ではなく、運用哲学の違いだ。

• 従来の CI/CD: 「コードをビルドしてデプロイする」パイプラインに焦点。デプロイ後の状態管理は範囲外
• GitOps: 「Git の状態とシステムの状態を常に一致させる」ことに焦点。デプロイ後のドリフト検出・自動修復まで含む

CI/CD は「変更を届ける仕組み」、GitOps は「あるべき状態を維持する仕組み」と捉えると違いが明確になる。

よくある落とし穴

• シークレット管理の課題: Git にパスワードや API キーを直接格納できない。Sealed Secrets、External Secrets Operator、AWS Secrets Manager との連携が必要になる
• 環境ごとの差異: dev/stg/prod で設定が異なる場合、ブランチ戦略かディレクトリ戦略かで悩む。Kustomize のオーバーレイや Helm の values ファイルで環境差分を管理するのが一般的
• 手動変更の誘惑: 障害対応で「とりあえず本番を直接変更」すると、Git との乖離が生じる。Pull 型なら自動で Git の状態に戻されるが、Push 型では乖離が残り続ける
• 大規模リポジトリの遅延: マニフェストが数千ファイルに膨れると、ポーリング間隔内に同期が完了しない場合がある

GitOps を始めるための判断基準

GitOps を始めるための判断基準を以下にまとめる。

条件	Push 型で十分	Pull 型を検討
インフラ	サーバーレス (Lambda, S3)	Kubernetes クラスター
チーム規模	1〜5 人	5 人以上、複数チーム
環境数	2〜3 環境	5 環境以上、マルチクラスター
ドリフト検出	手動確認で許容	自動検出・修復が必須

小規模なサーバーレスプロジェクトなら、GitHub Actions + SAM の Push 型で十分だ。Kubernetes を運用するなら、ArgoCD の導入を検討する価値がある。

Weaveworks のブログ記事 (2017 年) が GitOps の原典であり、「GitOps and Kubernetes」(Billy Yuen ら著) で体系的に解説されている。

# ArgoCD の Application 定義
apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  source:
    repoURL: https://github.com/myorg/k8s-manifests
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true

体系的に学ぶなら関連書籍を参照してほしい。