LESSON 30分

ストーリー

田
田中VPoE
Kubernetesの抽象化ができた。次はデプロイの仕組みだ。開発者がApplication CRDをGitにプッシュしたら、自動的にクラスタに反映される。これがGitOpsだ
あなた
CI/CDパイプラインでkubectl applyするのとは違うんですか？
あ
田
田中VPoE
根本的に異なる。CIパイプラインからのpushモデルでは「CIがクラスタに対してコマンドを実行する」。GitOpsのpullモデルでは「クラスタがGitの状態を監視し、自分自身を同期する」。CIにクラスタの認証情報を持たせる必要がなく、セキュリティが向上する
あなた
Gitがシングルソースオブトゥルースになるんですね
あ
田
田中VPoE
その通り。誰が、いつ、何を変更したかがすべてGitのコミット履歴に残る。ロールバックはgit revertするだけ。監査証跡も完璧だ

GitOpsの基本原則

4つの原則

原則説明
Declarativeシステムの望ましい状態を宣言的に定義する
Versioned and Immutable状態はGitでバージョン管理され、履歴は不変
Pulled AutomaticallyエージェントがGitの状態を自動的にクラスタに反映する
Continuously Reconciled実際の状態がGitの状態と異なれば自動修正する

Push型 vs Pull型

観点Push型（CI/CD→kubectl）Pull型（GitOps）
起点CIパイプラインがクラスタにpushクラスタ内のエージェントがGitからpull
認証情報CIにクラスタ認証が必要CIにクラスタ認証は不要
ドリフト検出手動チェック自動検出・自動修正
ロールバックCIを再実行 or kubectlgit revert
監査証跡CI/CDログGitコミット履歴
セキュリティ攻撃面が広い攻撃面が狭い

GitOpsツールの比較

主要ツール

ツール開発元特徴
Argo CDIntuit/CNCFWebUI充実、ApplicationSet、マルチクラスタ
FluxWeaveworks/CNCF軽量、Kubernetes-native、HelmController
FleetRancher大規模マルチクラスタ向け

Argo CDのアーキテクチャ

Argo CD の動作フロー:

1. 開発者が Application CRD を Git にプッシュ
       ↓
2. Argo CD が Git リポジトリを定期的にポーリング（3分間隔）
       ↓
3. 差分検出
   ├── Gitの状態（Desired State）
   └── クラスタの状態（Live State）
       ↓
4. 差分があれば同期
   ├── Auto Sync: 自動適用
   └── Manual Sync: UIで承認後に適用
       ↓
5. ヘルスチェック
   ├── Pod が Running か
   ├── Service が正常か
   └── Ingress が有効か
       ↓
6. ステータス更新
   └── Synced / OutOfSync / Degraded / Healthy

GitOpsリポジトリ戦略

リポジトリ構成パターン

パターン構成メリットデメリット
モノレポ1つのリポジトリに全環境シンプル、横断的変更が容易権限管理が複雑
環境別レポ環境ごとにリポジトリ環境ごとの権限分離同じ変更を複数箇所に反映
アプリ+インフラ分離アプリコードとマニフェストを分離関心の分離、CIの独立性リポジトリ間の同期が必要

推奨: アプリ + GitOps構成リポジトリ

推奨リポジトリ構成:

アプリリポジトリ（各チーム所有）:
  payment-service/
  ├── src/                    # アプリケーションコード
  ├── Dockerfile
  ├── platform.yaml           # Application CRD
  └── .github/workflows/
      └── ci.yaml             # CI: テスト、ビルド、イメージプッシュ

GitOpsリポジトリ（プラットフォームチーム所有）:
  gitops-config/
  ├── base/                   # 共通設定
  │   └── platform-defaults.yaml
  ├── environments/
  │   ├── dev/
  │   │   ├── payment-service/
  │   │   │   └── application.yaml  # dev環境の設定
  │   │   └── ...
  │   ├── staging/
  │   │   ├── payment-service/
  │   │   │   └── application.yaml  # staging環境の設定
  │   │   └── ...
  │   └── production/
  │       ├── payment-service/
  │       │   └── application.yaml  # production環境の設定
  │       └── ...
  └── argocd/
      └── applications.yaml   # Argo CD Application定義

プロモーション戦略

環境間のプロモーション

プロモーションフロー:

1. 開発者がアプリリポジトリにPRをマージ
       ↓
2. CI: テスト → ビルド → イメージプッシュ
   イメージタグ: registry/payment-service:abc123
       ↓
3. Image Updater が GitOps リポジトリの dev を自動更新
   environments/dev/payment-service/application.yaml
   image: registry/payment-service:abc123
       ↓
4. Argo CD が dev クラスタに自動同期
       ↓
5. dev で自動テスト（E2E、スモークテスト）
       ↓
6. 成功 → staging にプロモーション（PRを自動作成）
       ↓
7. staging で受け入れテスト
       ↓
8. 成功 → production にプロモーション（PRを作成、承認必須）
       ↓
9. Team Lead が PR を承認 → Argo CD が production に同期

ロールバック

ロールバック方法:

方法1: git revert
  $ git revert HEAD
  → Argo CD が前のバージョンに自動同期

方法2: Argo CD UI
  → Historyから任意のリビジョンに同期

方法3: CLI
  $ argocd app rollback payment-service
  → 前のSyncedリビジョンに戻す

いずれの方法でもGitに記録が残る

「GitOpsの最大のメリットは『すべての変更がGitに記録される』こと。障害対応時に『何が変わったか』をGitのログで瞬時に追跡できる」 — 田中VPoE

まとめ

ポイント内容
GitOps 4原則宣言的、バージョン管理、自動Pull、継続的な調整
Pull型モデルクラスタ内のエージェントがGitから状態を同期
リポジトリ戦略アプリリポジトリ + GitOpsリポジトリの分離
プロモーションdev → staging → production のPRベースフロー

チェックリスト

  • GitOpsの4原則を説明できる
  • Push型とPull型の違いを理解した
  • GitOpsリポジトリの構成パターンを設計できる
  • 環境間プロモーションとロールバックのフローを理解した

次のステップへ

次は演習です。CloudOps社のセルフサービスプラットフォームを設計しましょう。

推定読了時間: 30分