ArgoCDで実践するGitOps入門：Kubernetesのデプロイ管理を完全に自動化・可視化する
テックリードの私たちが日々の開発で直面する最大のボトルネック、それは「CI/CDパイプラインのブラックボックス化」と「環境間のコンフィグ drift（意図しない乖離）」だ。
JenkinsやGitHub Actionsのパイプラインから `kubectl apply` を叩く従来のプッシュ型CI/CDは、ビルドの成功とデプロイの成功を混同しやすい。そして何より、「今、本番クラスターで実際に稼働しているマニフェストは何なのか？」を即座に答えられるエンジニアは、現場にどれだけいるだろうか？
本稿では、この課題に終止符を打つArgo CDを用いたGitOpsの実践アプローチを、現場の即戦力となるプロの知見を交えて徹底解説する。
—
1. 従来のCI/CDとGitOpsの違いとメリット
プッシュ型CI/CDの限界
従来のCI/CDモデルでは、CIツール（GitHub Actions等）がビルドを行い、認証情報（Kubeconfig）を保持した状態で直接Kubernetesクラスターへマニフェストをプッシュ（Push）する。
- セキュリティリスク: CIランナーが本番クラスターへの強大な書き込み権限（ServiceAccount Token）を持つ必要がある。
- 状態の不可視性: クラスター側で誰かが `kubectl edit` や `patch` で手動修正（Hotfix）を行った場合、Gitリポジトリとの乖離（Drift）が発生し、次回のCI実行時に予期せぬ上書きやコンフリクトを引き起こす。
GitOps（プル型）の本質
GitOpsは、「Gitリポジトリを唯一の真実のソース（Single Source of Truth）」とし、クラスター側で常駐するエージェント（Argo CD）が自律的にGitの状態をプル（Pull）し、差分を自動修復するモデルだ。
[ Git Repository (Desired State) ]
▲
│ (Pull & Sync)
[ Argo CD (Cluster Agent) ] ───> [ Kubernetes Cluster (Actual State) ]
- 監査証跡の完全性: すべての変更がPull Requestのレビューとコミット履歴として残る。
- 自己修復性（Self-Heal）: クラスターが意図せず変更されても、Argo CDが自動的にGitの状態へ引き戻す。
—
2. ArgoCDのインストールとアーキテクチャ
Argo CDのコントロールプレーンは、Kubernetesのカスタムリソース定義（CRD）とコントローラーの集合体として動作する。
本番グレードのインストール
評価用なら `kubectl apply -n argocd -f …` で事足りるが、実運用ではKustomizeやHelmを用い、HA（高可用性）構成とセキュリティ硬化（Hardening）を行った上でデプロイする。
名前空間の作成
kubectl create namespace argocd
公式マニフェスト（Stable）の適用
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
> プロの知見：初期パスワードの安全な取得
> 初期管理者（`admin`）のパスワードは自動生成され、シークレットに保存される。以下のワンライナーで安全に取得し、初回ログイン後に即座に変更、あるいはOIDC（OAuth2/Keycloak等）連携へ移行せよ。
> `kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath=”{.data.password}” | base64 -d`
—
3. GitリポジトリとKubernetesクラスターの同期設定
アプリケーションのデプロイ定義は、`Application` カスタムリソースとして宣言する。ここでは、Kustomizeを用いたマルチ環境（Staging / Production）対応のベストプラクティス構成を示す。
ディレクトリ構造のベストプラクティス
gitops-manifests/
├── apps/ # ArgoCD Application定義
│ ├── staging-app.yaml
│ └── production-app.yaml
└── workloads/ # アプリケーションマニフェスト本体
├── base/
│ ├── deployment.yaml
│ ├── service.yaml
│ └── kustomization.yaml
└── overlays/
├── staging/
│ ├── kustomization.yaml
│ └── patch-replicas.yaml
└── production/
├── kustomization.yaml
└── patch-replicas.yaml
実用的な Application マニフェスト（YAML）
以下は、自動同期（Prune/Self-Heal有効）を組み込んだプロダクション向けの `Application` 定義だ。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: payment-api-production
namespace: argocd
# ArgoCD自身のコントローラーによるリソース削除を防ぐファイナルナイザー
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
project: default
source:
repoURL: ‘https://github.com/your-org/gitops-manifests.git’
targetRevision: HEAD
path: workloads/overlays/production
destination:
server: ‘https://kubernetes.default.svc’
namespace: production
syncPolicy:
# 自動同期を有効化
automated:
prune: true # Gitから削除されたリソースをクラスターからも削除
selfHeal: true # クラスター上の手動変更をGitの状態に強制同期
syncOptions:
- CreateNamespace=true # 対象名前空間が存在しない場合は自動作成
- ApplyOutOfSyncOnly=1 # 差分があるリソースのみapply（最適化）
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
—
4. WebUIを活用したアプリケーションの監視とロールバック
Argo CDの真骨頂は、デプロイ状態の美しく直感的な可視化にある。Pod、Service、Ingress、ConfigMapなどの依存関係がツリー構造でリアルタイム表示され、ヘルスチェックの状態が一目でわかる。
開発スピードを劇的に高めるCLI & WebUIの極意
1. CLIの神ショートカット（`argocd` CLI）
日々のオペレーションでWebUIを開くのは遅すぎる。CLIを駆使せよ。
- 爆速同期: `argocd app sync payment-api-production –prune`
- ログのリアルタイム追跡（複数レプリカ対応）: `argocd app logs payment-api-production –tail=100`
- 差分の即座確認（Diff）: `argocd app diff payment-api-production`（デプロイ前にGitとクラスターの差異を目視確認する必須コマンド）
2. 現場で導入すべき「神プラグイン」と設定
- Argo CD Image Updater:
CI側でコンテナイメージのビルドとプッシュが行われた後、わざわざGitのマニフェストを書き換えるPRを作る必要はない。`argocd-image-updater`を導入し、Annotationを設定するだけで、ECR/GAR/DockerHubの新しいタグを検知してGitリポジトリへ自動コミット（またはダイレクトプレーン書き換え）を行わせる。
- Resource Exclusions / Inclusions:
巨大なクラスターでは、不要なカスタムリソース（例: Prometheus OperatorのCRD内部状態など）までトラッキングするとArgoCDのメモリが圧迫される。`argocd-cm` ConfigMapにて、不要なリソースグループをトラッキング対象外（Exclusions）に指定することは、SREとしての必須嗜好である。
3. 瞬時のロールバック戦略
本番障害が発生した際、Gitのコミット履歴を巻き戻す（`git revert`）のがGitOpsの正攻法だが、緊急時にはArgo CDのUIまたはCLIから直接ロールバックを実行できる。
過去の特定の同期待ちリビジョンへロールバック
argocd app rollback payment-api-production
> 警告: `argocd app rollback` を実行すると、Argo CDは一時的に自動同期（Automated Sync）を一時停止（Suspended）状態にする。Gitの状態とクラスターの状態が一時的に乖離するため、障害復旧後に必ず根本原因をGitリポジトリ側へコードとして反映（Git Commit）し、同期を再有効化することを忘れてはならない。
—
結びにかえて
Argo CDを導入することは単に「デプロイツールを変える」ことではない。インフラストラクチャの変更管理におけるマインドセットを「命令型（Imperative）」から「宣言型（Declarative）」へ完全にシフトさせることを意味する。
ここに示した設定とベストプラクティスをベースラインとしてチームに導入し、誰もが安心して数分おきに本番デプロイを行える、真のContinuous Delivery文化を築き上げてほしい。