# 宣言：「3つのレプリカが欲しい」
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3  # 望ましい状態
  template:
    spec:
      containers:
      - name: app
        image: myapp:v1.2.3

システムがこの状態を達成する方法を自動的に見つけ出します。

2. Gitが唯一の信頼できる情報源

すべての設定がGitに存在：

アプリケーションマニフェスト（デプロイメント、サービス）
インフラストラクチャ定義
設定データ

Gitが提供するもの：

バージョン履歴: すべての変更が著者、タイムスタンプ、理由とともに追跡される
監査証跡: 誰が何を変更したかの完全な履歴
コラボレーション: プルリクエスト、コードレビュー、承認
ロールバック: git revertで変更を即座に元に戻す

3. 自動同期

コントローラーが継続的に：

Gitリポジトリの変更を監視
望ましい状態（Git）と実際の状態（クラスター）を比較
変更を自動的に適用してドリフトを排除
手動の変更をGitに合わせて元に戻す

4. 継続的な調整

システムは常に「現実はGitと一致していますか？」と尋ねます。

誰かがkubectl editを実行 → 自動的にリバート
ポッドがクラッシュ → 自動的に再作成
設定がドリフト → 自動的に修正

これが自己修復インフラストラクチャです。

GitOps vs 従来のCI/CD

従来のCI/CD（命令的）:

# プッシュベースのデプロイメント
git push → CIパイプラインがビルド → Jenkinsがkubectl applyを実行 → うまくいったことを願う

GitOps（宣言的）:

# プルベースのデプロイメント
git push → コントローラーが変更を検出 → コントローラーが変更を適用 → 同期を確認

主な違い：誰がデプロイメントをトリガーするか？

プッシュベース vs プルベース：重要な違い

GitOps実装には2つの基本的なアプローチがあります：

プッシュベースGitOps（従来のCI/CD）

動作方法:

開発者がコードをGitにプッシュ
CI/CDパイプライン（Jenkins、GitHub Actions）がトリガーされる
パイプラインがアーティファクトをビルド
パイプラインがkubectl applyを使用してKubernetesクラスターにアクティブにプッシュ

アーキテクチャ:

[Git Repo] → [CI/CD Pipeline] → [Kubernetes Cluster]
              (変更をプッシュ)

メリット:

すでにCI/CDを使用しているチームには馴染みがある
デプロイメントのタイミングを直接制御
既存のCI/CDインフラストラクチャ

デメリット:

セキュリティリスク: CI/CDにクラスター認証情報が必要（広範な権限）
単一障害点: CI/CDがダウンするとデプロイメントができない
ドリフト検出なし: 手動変更が自動的にリバートされない
認証情報管理: CI/CDシステム内のクラスターアクセストークン
手動ロールバック: 古いバージョンでパイプラインを再実行する必要がある

プルベースGitOps（ArgoCD、Flux）

動作方法:

開発者が設定変更をGitにプッシュ
クラスター内のコントローラーが継続的にGitを監視
コントローラーがGitとクラスターの違いを検出
コントローラーが変更をプルして適用

アーキテクチャ:

[Git Repo] ← [ArgoCD Controller] ← [Kubernetes Cluster]
            (プルして監視)

メリット:

より良いセキュリティ: クラスター外にクラスター認証情報がない
自動ドリフト検出: 手動変更を自動的にリバート
自己修復: クラスターは常にGitと一致
シンプルなロールバック: git revert → 自動同期
明確な監査証跡: Git履歴 = デプロイメント履歴
宣言的: 望ましい状態が明示的に定義される

デメリット:

クラスターにコントローラーをインストールする必要がある
プッシュベースCI/CDに慣れているチームにとってはパラダイムシフト

なぜArgoCDはプルベースを使用するのか

ArgoCDはプルベースGitOpsを実装します：

セキュリティ: コントローラーはクラスター内で実行され、外部認証情報は最小限。CI/CDシステムにクラスターアクセストークンを保存する必要がない。

シンプルさ: 開発者はGitにプッシュするだけ。複雑なパイプライン設定は不要。

ドリフト検出: ArgoCDはGitとクラスターの両方を継続的に監視し、ドリフトを自動的に修正。

ディザスタリカバリ: 誰かが誤ってリソースを削除しても、ArgoCDがGitから即座に再作成。

マルチクラスター: 単一のArgoCDインスタンスが、CI/CDパイプラインの複雑さなしに複数のクラスターを管理可能。

ArgoCDとは？

ArgoCDは、Kubernetes向けの宣言的なGitOps継続的デリバリーツールです。Cloud Native Computing Foundation（CNCF）で最も人気のあるGitOpsツールであり、卒業ステータス（最高の成熟度レベル）を達成しています。

主な機能

🎯 GitOpsネイティブ

プルベースの継続的デリバリー
Gitが唯一の信頼できる情報源
自動同期

🖥️ リッチなWeb UI

ビジュアルアプリケーションダッシュボード
リアルタイムの同期ステータス
デプロイメント履歴とロールバック
リソース依存関係の可視化

🔄 自動同期と自己修復

Gitとクラスターを継続的に監視
設定のドリフトを検出
手動変更を自動リバート
望ましい状態を維持

📦 複数の設定管理ツール

プレーンなKubernetes YAML
Helmチャート
Kustomizeオーバーレイ
Jsonnetテンプレート
カスタムプラグイン

🌐 マルチクラスター管理

単一のArgoCDインスタンスから複数のクラスターを管理
テンプレート化されたデプロイメント用のApplicationSets
ハブアンドスポークアーキテクチャ

🔐 セキュリティとRBAC

きめ細かいアクセス制御
SSO統合（OIDC、SAML、LDAP）
プロジェクトによるマルチテナンシー
シークレット管理統合

📊 観測可能性

Prometheusメトリクス
ヘルスステータス監視
同期通知（Slack、メール、Webhook）
詳細なイベントログ

ArgoCD vs 代替ツール：クイック比較

ArgoCD vs Flux CD

機能	ArgoCD	Flux CD
Web UI	✅ 組み込み、機能豊富	❌ ネイティブUIなし
セットアップ	クイック（30分）	より多くの設定が必要
RBAC	優秀、組み込み	K8sネイティブRBACを使用
マルチテナンシー	ファーストクラスのサポート	基本的なサポート
学習曲線	穏やか	より急峻
ユースケース	UIとRBACが必要なチーム	CLI優先、軽量

ArgoCDを選ぶべき時: リッチなUI、マルチテナント環境、きめ細かいアクセス制御、簡単なオンボーディングが必要。

Fluxを選ぶべき時: CLI優先のアプローチを好む、Kubernetes RBACに既に慣れている、軽量なソリューションが欲しい。

ArgoCD vs Jenkins X

機能	ArgoCD	Jenkins X
スコープ	CD重視	フルCI/CDプラットフォーム
セットアップ時間	30分 - 1時間	数時間
複雑さ	シンプル、集中的	複雑、包括的
ユースケース	デプロイメント自動化	完全なCI/CDパイプライン

ArgoCDを選ぶべき時: すでにCIパイプラインがある、モダンなGitOps CDツールが必要、Kubernetesネイティブなデプロイメント。

Jenkins Xを選ぶべき時: ゼロからCI/CDプラットフォームを構築、統合されたCI + CDソリューションが必要。

なぜArgoCDを選ぶのか？

ArgoCDがKubernetes GitOpsデプロイメントの業界標準になった理由：

1. 開発者エクスペリエンス

シンプルなワークフロー:

# 1. 開発者が変更を行う
git add deployment.yaml
git commit -m "scale to 5 replicas"
git push

# 2. ArgoCDが自動的に同期（パイプライン設定不要）
# 3. 完了！30秒で変更が反映

従来のCI/CDと比較：

# 1. 開発者が変更を行う
git push

# 2. CIパイプラインを待つ（5-10分）
# 3. Jenkinsがビルド
# 4. Jenkinsがkubectl applyを実行
# 5. 何も壊れていないことを願う
# 6. クラスターを手動で確認

2. 安全性とロールバック

即座のロールバック:

# デプロイメントが失敗？コミットをリバートするだけ
git revert HEAD
git push
# ArgoCDが自動的に以前の状態に同期

同期前のプレビュー: ArgoCDは適用前に何が変更されるかを正確に表示：

作成されるリソース
更新されるリソース
削除されるリソース

変更を確認した後、手動で同期できます。

3. 可視性

ArgoCD UIは表示：

✅ どのアプリが健全か
⚠️ どのアプリが非同期か
🔄 現在の同期ステータス
📜 完全なデプロイメント履歴
🔍 リソース依存関係ツリー

「実際に何がデプロイされているのか？」という混乱はもうありません。

4. 簡単なマルチクラスター

10個のクラスター？100個のクラスター？ArgoCDがすべて処理：

# 1つのApplicationSetがすべてのクラスターにデプロイ
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
spec:
  generators:
  - clusters: {}  # すべての登録されたクラスターを自動検出
  template:
    # 各クラスターに適用されるテンプレート

5. デフォルトでセキュア

プルベース = セキュア:

ArgoCDコントローラーはクラスター内で実行（外部認証情報なし）
Gitリポジトリは読み取りアクセスのみ必要
CI/CDシステムにクラスター認証情報なし
組み込みのRBACとマルチテナンシー

このシリーズで構築するもの

今後の7回のパートで、完全な本番環境対応のGitOpsデプロイメントシステムを構築します：

パート2：インストールと最初のアプリ

KubernetesクラスターにArgoCDをインストール
Gitから最初のアプリケーションをデプロイ
Application CRDを理解
基本的な同期操作

パート3：デプロイメントパターン

プレーンYAMLマニフェストでデプロイ
Helmチャート統合
Kustomizeオーバーレイ
それぞれのアプローチをいつ使用するか

パート4：同期戦略とApp of Apps

自動 vs 手動同期
プルーンと自己修復ポリシー
順序付けられたデプロイメントのための同期ウェーブ
App of Appsパターンで複数のアプリを管理

パート5：マルチ環境とマルチクラスター

テンプレート化のためのApplicationSets
開発/ステージング/本番環境
マルチクラスターデプロイメント
ハブアンドスポークアーキテクチャ

パート6：セキュリティとシークレット

RBACとアクセス制御
SSO統合
シークレット管理（External Secrets Operator）
プロジェクトによるマルチテナンシー

パート7：本番環境デプロイメント

高可用性セットアップ
Prometheus監視
Slack/メール通知
ディザスタリカバリ戦略

前提条件

このシリーズに従うには、以下が必要です：

必須:

基本的なKubernetesの知識（ポッド、デプロイメント、サービス）
kubectl CLIがインストールされている
Kubernetesクラスターへのアクセス（ローカルまたはクラウド）：
- ローカル: kind、minikube、Docker Desktop
- クラウド: GKE、EKS、AKS無料ティア
Gitの基本（コミット、プッシュ、プル）

推奨:

HelmまたはKustomizeに精通
YAMLの基本的な理解
CI/CDコンセプトの経験

オプション:

設定をホストするためのGitHub/GitLabアカウント
本番環境の例用のクラウドアカウント（パート6-7）

主要概念のまとめ

ハンズオンチュートリアルに入る前に、中核概念をまとめましょう：

GitOps = Git + 運用

Gitリポジトリ（信頼できる情報源）
       ↓
ArgoCDコントローラー（調整）
       ↓
Kubernetesクラスター（現実）

プルベースの勝利

クラスター内のコントローラー
Gitを継続的に監視
変更を自動的に適用
ドリフトを自動的にリバート

ArgoCDの利点

可視性のためのリッチなUI
マルチクラスター管理
組み込みRBAC
自動同期と自己修復
初日から本番環境対応

GitOpsを強力にするもの

宣言的: 望ましい状態を記述
バージョン管理: Git履歴 = デプロイメント履歴
自動化: 手動のkubectl applyなし
監査可能: 完全な変更追跡
回復可能: git revertによる即座のロールバック

次回予告

パート2：インストールと最初のアプリケーションでは：

KubernetesクラスターにArgoCDをインストール
ArgoCD UIにアクセス
Gitから最初のアプリケーションをデプロイ
Application CRDを理解
同期操作を実行

30分以内にゼロからアプリケーションのデプロイまで進めます！

GitOpsやArgoCDについて質問がありますか？ 下にコメントを残してください！シリーズを通じて質問にお答えします。

目次