GitOps
このドキュメントの目的
GitOpsの概念と原則を理解し、従来のCI/CDとの違いやGitOpsがもたらす利点を把握することが目標です。
IDサービスを題材にした具体例を使用しますが、設計原則自体はあらゆるSaaSに共通して適用できます。
デプロイ手法の進化
GitOpsは突然生まれたものではなく、ソフトウェアデプロイの課題を解決してきた歴史の延長にあります。
デプロイ手法の進化:
2000年代 2010年代前半 2010年代後半 2018年〜
┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────┐
│ 手動デプロイ│────▶│ CI/CD │────▶│ Infrastructure│──▶│ GitOps │
│ │ │ (Push型) │ │ as Code │ │ (Pull型) │
│ │ │ │ │ │ │ │
│・FTP/SSH │ │・Jenkins │ │・Terraform │ │・Argo CD │
│・手順書 │ │・Travis CI │ │・Ansible │ │・Flux CD │
│・属人化 │ │・CircleCI │ │・CloudFormation│ │・宣言的 │
└──────────┘ └──────────────┘ └──────────────┘ └──────────┘
課題: 課題: 課題: 解決:
再現性がない CIに強い権限が必要 コードとインフラ Gitが唯一の
スケールしない ドリフトに気づかない 定義が分散 情報源
人的ミス多発 監査が困難 状態の収束が手動 自動収束
| 世代 | 特徴 | 残った課題 |
|---|---|---|
| 手動デプロイ | SSH/FTP + 手順書 | 属人化、再現性なし、人的ミス |
| CI/CD（Push型） | パイプラインが自動でビルド・テスト・デプロイ | CIに強い権限、ドリフト未検知、監査困難 |
| Infrastructure as Code | インフラをコードで定義（Terraform, Ansible等） | コードとクラスター状態の乖離、収束が手動 |
| GitOps（Pull型） | Gitをあるべき状態の情報源とし、エージェントが自動収束 | ― |
GitOpsはCI/CD + Infrastructure as Codeの考え方を統合し、Gitリポジトリを中心にすべてを管理する手法として2017年にWeaveworks社が提唱しました。
GitOpsとは
Gitリポジトリをシステムのあるべき状態の唯一の情報源（Single Source of Truth）とし、クラスター側のエージェントがリポジトリの状態に自動的に収束させるデプロイ手法です。
従来のCI/CDではパイプラインがクラスターに「Push」するのに対し、GitOpsではクラスター側のエージェントがGitから「Pull」します。
Push型とPull型の違い
Push型（従来のCI/CD）
CIパイプラインがビルド後にクラスターへ直接デプロイコマンドを発行します。
Push型の流れ:
開発者 ──push──▶ GitHub ──trigger──▶ CI (GitHub Actions)
│
│ kubectl apply / helm upgrade
▼
Kubernetesクラスター
Push型の課題:
| 課題 | 説明 |
|---|---|
| 強い権限がCIに必要 | パイプラインがクラスターへの書き込み権限を持つ |
| 状態の不透明さ | 「今クラスターに何がデプロイされているか」がGitから分からない |
| ドリフト | 手動 kubectl で上書きされるとGitとの乖離が生まれる |
| 監査の困難さ | 誰がいつ何をデプロイしたか追跡し にくい |
Pull型（GitOps）
クラスター内のエージェントがGitリポジトリを監視し、差分があれば自動的に同期します。
Pull型の流れ:
開発者 ──push──▶ GitHub ──trigger──▶ CI (GitHub Actions)
│
│ Image Push + マニフェスト更新
▼
┌──────────┐ ┌──────────┐
│ マニフェスト│ ◀─── │ Container│
│ リポジトリ │ │ Registry │
└─────┬────┘ └──────────┘
│
│ Pull & Sync (GitOps Agent)
▼
Kubernetesクラスター
Pull型の利点:
| 利点 | 説明 |
|---|---|
| CIに最小権限 | パイプラインはクラスターへのアクセス権を持たない |
| Gitが情報源 | リポジトリを見ればクラスターの状態が分かる |
| 自己修復 | 手動変更を自動でGitの状態に戻せる |
| 監査証跡 | すべての変更がGitコミットとして記録される |
比較まとめ
| 観点 | Push型 | Pull型（GitOps） |
|---|---|---|
| デプロイの起点 | CIパイプライン | クラスター内エージェント |
| クラスターへの権限 | CIが持つ | エージェントのみが持つ |
| あるべき状態の定義 | パイプラインのスクリプト内 | Gitリポジトリ |
| ドリフト検知 | なし（手動確認） | 自動検知・自動修復 |
| 変更の追跡 | CIログ | Gitコミット履歴 |
GitOpsの4原則
| 原則 | 説明 | 具体例 |
|---|---|---|
| 宣言的 | あるべき状態をYAML/JSONで宣言する（手順ではなく結果を記述） | Kubernetes マニフェスト、Kustomize、Helm Chart |
| バージョン管理 | すべての状態変更がGitコミットとして記録される | マニフェストリポジトリへのコミット、PRによるレビュー |
| 自動適用 | 承認された変更はクラスターに自動的に反映される | エージェントがGitの変更を検知し同期 |
| 自己修復 | クラスターの実状態がGitと乖離したら自動で修正する | 手動 kubectl 変更を自動で元に戻す |
GitOpsの動作サイクル:
┌──────────┐ コミット ┌──────────┐
│ 開発者 │──────────────▶│ Git │
└──────────┘ │ リポジトリ │
└────┬─────┘
│
┌────┴─────┐
│ あるべき │
│ 状態 │
└────┬─────┘
│
比較 │ 比較
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 差分なし │ │ 差分あり │ │ ドリフト │
│ │ │ │ │ 検知 │
│ → 何もし │ │ → 同期 │ │ → 自己 │
│ ない │ │ 実行 │ │ 修復 │
└──────────┘ └──────────┘ └──────────┘
GitOpsのリポジトリ戦略
モノリポ vs マルチリポ
GitOpsではアプリケーションコードとインフラ定義（Kubernetesマニフェスト）の管理方法を選択する必要があります。
モノリポ: マルチリポ（推奨）:
idp-server/ idp-server/ (アプリ)
├── src/ ├── src/
├── Dockerfile ├── Dockerfile
├── .github/workflows/ └── .github/workflows/
└── k8s/ ← 同一リポ
├── base/ idp-server-manifests/ (マニフェスト)
└── overlays/ ├── base/
└── overlays/
| 方式 | 利点 | 欠点 |
|---|---|---|
| モノリポ | シンプル、小規模チーム向き | 権限分離が困難、アプリ変更のたびにGitOpsエージェントが反応 |
| マルチリポ | 権限分離、履歴分離、独立したライフサイクル | リポジトリ間の連携が必要 |
マルチリポが推奨される理由:
| 理由 | 説明 |
|---|---|
| 権限分離 | アプリ開発者とインフラ管理者でアクセス権を分けられる |
| コミット履歴の分離 | アプリの変更とインフラの変更が混ざらない |
| デプロイ頻度の違い | アプリは頻繁に更新、インフラ設定は低頻度 |
| ロールバックの独立性 | アプリだけ / インフラだけのロールバックが容易 |
GitOpsにおけるロールバック
GitOps環境ではロールバックもGitの操作で行います。
ロールバック手順:
方法1: Git Revert（推奨）
───────────────────────
1. マニフェストリポジトリで変更コミットを revert
git revert HEAD
2. エージェントが自動的に前の状態に同期
方法2: エージェントのUIからロールバック
──────────────────────────────────────
1. UIで過去のリビジョンを選択
2. 即座にクラスターに適用
※ Gitとの乖離が発生するため、後でGitも修正が必要
| 方法 | 速度 | Git整合性 | 推奨 |
|---|---|---|---|
| Git Revert | やや遅い（コミット→同期） | 保たれる | 通常時 |
| UI Rollback | 速い（即座に適用） | 一時的に乖離 | 緊急時 |
原則: 通常時は Git Revert でロールバックし、Gitの整合性を保ちます。緊急時のみUIから即座にロ ールバックし、事後にGitを修正します。
GitOpsエージェント
エージェントの役割
GitOpsを実現するには、Gitリポジトリの状態を監視し、クラスターに自動的に反映するエージェントが必要です。エージェントはKubernetesクラスター内で動作し、「Gitに書かれたあるべき姿」と「クラスターの現在の姿」を常に比較し続けます。
GitOpsエージェントの動作:
┌──────────────┐ ┌──────────────┐
│ Git リポジトリ │ │ Kubernetes │
│ │ │ クラスター │
│ あるべき状態 │ │ 現在の状態 │
└──────┬───────┘ └──────┬───────┘
│ │
└───────────┬───────────┘
│
▼
┌──────────────┐
│ GitOps Agent │
│ │
│ 差分を検知 │
│ → 自動で同期 │
└──────────────┘
主要なGitOpsエージェントの比較
| ツール | CNCF | 特徴 |
|---|---|---|
| Argo CD | Graduated | Web UIが充実、Application単位の管理、RBAC、SSO連携 |
| Flux CD | Graduated | 軽量、CLI中心、Helm Controller内蔵、学習コスト低 |
| Jenkins X | - | Jenkinsベース、CI/CD一体型、独自のワークフロー |
Argo CD
Argo CD のアーキテクチャ:
┌───────────────────── ────────────────────────────┐
│ Kubernetes クラスター │
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Argo CD │ │
│ │ │ │
│ │ ┌────────────┐ ┌────────────────────┐ │ │
│ │ │ API Server │ │ Repo Server │ │ │
│ │ │ │ │ │ │ │
│ │ │ UI / CLI │ │ Git リポジトリから │ │ │
│ │ │ を提供 │ │ マニフェストを取得 │ │ │
│ │ └────────────┘ └────────────────────┘ │ │
│ │ │ │
│ │ ┌────────────────────────────────────┐ │ │
│ │ │ Application Controller │ │ │
│ │ │ │ │ │
│ │ │ Git の状態とクラスターの状態を比較 │ │ │
│ │ │ 差分があれば同期を実行 │ │ │
│ │ └────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────┐ │
│ │ アプリケーション Pod │ │
│ │ (idp-server) │ │
│ └──────────────────────────────┘ │
└─────────────────────────────────────────────────┘
強み: Web UIでリソースのツリー表示・ヘルス状態を一目で確認でき、同期前にGitとクラスターの差分をプレビューできる。Argo Rollouts（Canary/Blue-Green）やArgo Workflows等のエコシステムとも連携可能。
Flux CD
Flux CD のアーキテクチャ:
┌─────────────────────────────────────────────────┐
│ Kubernetes クラスター │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Source │ │ Kustomize │ │
│ │ Controller │ │ Controller │ │
│ │ │ │ │ │
│ │ Git/Helmリポ │ │ Kustomize │ │
│ │ を監視 │ │ を適用 │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Helm │ │ Notification │ │
│ │ Controller │ │ Controller │ │
│ │ │ │ │ │
│ │ Helm Chart │ │ Slack等に │ │
│ │ を適用 │ │ 通知 │ │
│ └──────────────┘ └──────────────┘ │
└─────────────────────────────────────────────────┘
強み: 各機能が独立したControllerとして動作し、軽量。CLIベースでの運用に向いており、Helm Chartのネイティブサポートも強力。
どちらを選ぶか
| 観点 | Argo CD | Flux CD |
|---|---|---|
| UI | Web UIが充実 | CLIが中心（Web UIは別途構築） |
| 学習コスト | 中程度 | 低い |
| マルチクラスター | 1インスタンスで複数管理 | クラスターごとにインストール |
| Helm対応 | Helm Template経由 | Helm Controller内蔵 |
| 差分プレビュー | UI上で視覚的に確認 | CLI (flux diff) |
| 適したチーム | 運用チームがUIを必要とする場合 | CLI慣れした開発者チーム |
IDサービスの場合: マルチテナントの認証基盤では、デプロイの影響範囲が大きいため、Argo CD のUI上で差分をプレビューし、手動承認してからデプロイできる点が特に有効です。
GitOpsの導入で変わること
| 観点 | 導入前 | 導入後 |
|---|---|---|
| デプロイ方 法 | CIからkubectl実行 | Gitにコミット |
| 状態の確認 | kubectl get で直接確認 | Gitリポジトリを参照 |
| 変更の承認 | CI権限を持つ人が実行 | Pull Requestでレビュー |
| ロールバック | 手動でkubectlを実行 | Git Revertで自動反映 |
| 監査 | CIログを調査 | Gitコミット履歴で完結 |
| ドリフト対応 | 気づかない、または手動修正 | 自動検知・自動修復 |
次のステップ
GitOpsの概念と原則を理解しました。
次に読むべきドキュメント
- 実践: EKS + Argo CD パイプライン - GitOpsをEKS + Argo CDで実装する具体例
関連リソース
- Docker / Kubernetes - Kubernetesの基礎知識
- デプロイ戦略 - ローリング / Blue-Green / Canary の選択
最終更新: 2026-03-04 対象: SaaS開発者・プラットフォームエンジニア