- Authors
- Name
- はじめに
- ArgoCDアーキテクチャ概要
- ArgoCDアプリケーション設定
- GitOpsツール比較：ArgoCD vs FluxCD vs Jenkins X
- Argo Rolloutsによるプログレッシブデリバリー
- 本番環境でのロールバック戦略
- ApplicationSetsによるマルチクラスタ管理
- 本番環境トラブルシューティングガイド
- 通知とアラートの統合
- ベストプラクティスチェックリスト
- まとめ
- 参考文献
はじめに
GitOpsは、Kubernetesにおける継続的デリバリーのデファクトスタンダードとなった。その核心は、Gitを宣言的なインフラストラクチャおよびアプリケーション定義の単一の情報源（Single Source of Truth）として扱うことにある。ArgoCDはIntuitによって開発され、現在はCNCFの卒業プロジェクトとして、約60%の市場シェアと導入者のNPS 79を誇る圧倒的なGitOpsツールとなっている。Intuit自体もArgoCDを約400のクラスタにわたって運用し、数千のアプリケーションを本番環境で管理している。
しかし、ArgoCDを導入するだけでは安全なデプロイメントが自動的に保証されるわけではない。本番環境では、新バージョンを段階的にトラフィックに公開するプログレッシブデリバリー戦略、すべてのユーザーに影響が及ぶ前に障害を検知する自動ロールバック機構、そして問題が発生した際の十分にテストされたリカバリ手順が必要となる。本ガイドでは、ArgoCDのアーキテクチャと同期ポリシーから、Argo Rolloutsとの統合によるカナリアおよびブルーグリーンデプロイメント、自動分析、ロールバック戦略、そして実運用でのトラブルシューティングまで、完全なライフサイクルをカバーする。
ArgoCDアーキテクチャ概要
プログレッシブデリバリーに入る前に、ArgoCDが内部的にどのように動作するかを理解することが不可欠である。
┌─────────────────────────────────────────────────────────────────┐
│ ArgoCD Server │
│ ┌───────────┐ ┌──────────────┐ ┌───────────────────────┐ │
│ │ API │ │ Web UI │ │ Dex / OIDC │ │
│ │ Server │ │ Dashboard │ │ Authentication │ │
│ └─────┬─────┘ └──────┬───────┘ └───────────────────────┘ │
│ │ │ │
│ ┌─────▼───────────────▼─────────────────────────────────────┐ │
│ │ Application Controller │ │
│ │ - Application CRDを監視 │ │
│ │ - 期待状態 (Git) と実際の状態 (クラスタ) を比較 │ │
│ │ - 同期操作を実行 │ │
│ └─────────────────────┬─────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────▼─────────────────────────────────────┐ │
│ │ Repo Server │ │
│ │ - Gitリポジトリをクローン │ │
│ │ - Helm / Kustomize / Jsonnet テンプレートをレンダリング │ │
│ │ - パフォーマンスのためマニフェストをキャッシュ │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ Redis Cache │ │
│ │ - アプリケーション状態キャッシュ │ │
│ │ - Gitリポジトリキャッシュ │ │
│ └───────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│ │
▼ ▼
┌─────────────────┐ ┌──────────────────┐
│ Git Repository │ │ Kubernetes │
│ (情報源) │ │ Cluster(s) │
│ │ │ (デプロイ先) │
└─────────────────┘ └──────────────────┘
主要コンポーネント：
- API Server はCLIおよびWeb UIが使用するgRPC/REST APIを公開する
- Application Controller はGitの状態とライブクラスタの状態を継続的に比較するコアのReconciliationエンジンである
- Repo Server はGit操作とマニフェストレンダリング（Helm、Kustomize、Jsonnet、プレーンYAML）を処理する
- Redis はアプリケーション状態とリポジトリデータのキャッシュを提供する
ArgoCDアプリケーション設定
基本的なArgoCDアプリケーションマニフェストは、ソースリポジトリとターゲットクラスタを定義する。
# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app-production
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
project: production
source:
repoURL: https://github.com/myorg/k8s-manifests.git
targetRevision: main
path: apps/my-app/overlays/production
destination:
server: https://kubernetes.default.svc
namespace: my-app-prod
syncPolicy:
automated:
prune: true
selfHeal: true
allowEmpty: false
syncOptions:
- CreateNamespace=true
- PrunePropagationPolicy=foreground
- PruneLast=true
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
ignoreDifferences:
- group: apps
kind: Deployment
jsonPointers:
- /spec/replicas
重要な同期ポリシーオプションの解説：
| オプション | 説明 | 本番推奨設定 |
|---|---|---|
automated.prune | Gitから削除されたリソースを削除 | 慎重に有効化 |
automated.selfHeal | クラスタへの手動変更を元に戻す | 強く推奨 |
allowEmpty | リソースゼロでの同期を許可 | 常にfalseに設定 |
PruneLast | 他の同期完了後に削除を実行 | 安全のため有効化 |
retry.backoff | 失敗時の指数バックオフ | 5秒基準、ファクター2 |
警告： PruneLast=trueなしでautomated.pruneを有効にすると、リポジトリ構造の変更時にカスケード削除が発生する可能性がある。必ずステージング環境で同期ポリシーを先にテストすること。
GitOpsツール比較：ArgoCD vs FluxCD vs Jenkins X
ツールを決定する前に、各ツールのトレードオフを理解しておくべきである。
| 機能 | ArgoCD | FluxCD | Jenkins X |
|---|---|---|---|
| 市場シェア (2026年) | 約60% | 約30% | 5%未満 |
| CNCFステータス | Graduated | Graduated | Sandbox（アーカイブ済み） |
| Web UI | 組み込み、高機能 | サードパーティ（Weave GitOps） | 基本的 |
| マルチクラスタ | ネイティブサポート | Kustomization経由 | 限定的 |
| Helmサポート | ネイティブ | ネイティブ | ネイティブ |
| プログレッシブデリバリー | Argo Rollouts経由 | Flagger経由 | 組み込み（Tekton） |
| SSO/RBAC | 組み込み（Dex, OIDC） | Kubernetes RBAC | Kubernetes RBAC |
| リソース使用量 | 中程度（約512MB） | 低い（約128MB） | 高い（約2GB） |
| 学習曲線 | 中程度 | 中程度 | 急勾配 |
| マニフェストレンダリング | Helm, Kustomize, Jsonnet | Helm, Kustomize | Helm |
| 通知システム | Argo Notifications | Flux Notification Controller | Webhooks |
| ApplicationSets | あり（ジェネレータ） | あり（Kustomization） | なし |
| 差分プレビュー | UIおよびCLI | CLIのみ | CLIのみ |
ArgoCDを選ぶべき場合： リッチなWeb UI、シングルペインオブグラスでのマルチクラスタ可視化、組み込みSSO が必要な場合、またはチームにKubernetes経験レベルが異なるメンバーがいる場合。
FluxCDを選ぶべき場合： 軽量でKubernetesネイティブなアプローチを好む場合、主にCLI/自動化で運用する場合、500以上のアプリケーションを管理する場合、またはリソースオーバーヘッドを最小限に抑えたい場合。
Jenkins Xを選ぶべき場合： Tektonパイプラインと緊密に統合されたCI/CDが必要な場合（注：採用率は低下しており、コミュニティの勢いは限定的）。
Argo Rolloutsによるプログレッシブデリバリー
Argo Rolloutsは、カナリア、ブルーグリーン、実験機能を含む高度なデプロイメント戦略を提供するKubernetesコントローラである。標準的なKubernetes DeploymentをRollout CRDで置き換える。
カナリアデプロイメント戦略
カナリアデプロイメントは、主要なメトリクスを監視しながら、新バージョンへのトラフィックを段階的にシフトする。
# canary-rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-app
namespace: my-app-prod
spec:
replicas: 10
revisionHistoryLimit: 5
selector:
matchLabels:
app: my-app
strategy:
canary:
canaryService: my-app-canary
stableService: my-app-stable
trafficRouting:
istio:
virtualServices:
- name: my-app-vsvc
routes:
- primary
steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: error-rate-check
args:
- name: service-name
value: my-app-canary
- setWeight: 20
- pause: { duration: 5m }
- analysis:
templates:
- templateName: latency-check
args:
- name: service-name
value: my-app-canary
- setWeight: 50
- pause: { duration: 10m }
- analysis:
templates:
- templateName: comprehensive-check
args:
- name: service-name
value: my-app-canary
- setWeight: 80
- pause: { duration: 10m }
- setWeight: 100
rollbackWindow:
revisions: 3
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: myregistry/my-app:v2.1.0
ports:
- containerPort: 8080
resources:
requests:
cpu: 200m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
このロールアウトは慎重に段階化されたアプローチに従う：
- トラフィックの5%をカナリアに送り、5分待機
- エラー率分析を実行
- 20%に増加、5分待機
- レイテンシ分析を実行
- 50%に増加、10分待機
- 包括的チェックを実行（エラー率＋レイテンシ＋ビジネスメトリクス）
- 80%に増加、10分待機
- 100%にプロモート
いずれかの分析ステップが失敗した場合、ロールアウトは自動的に中止され、トラフィックは安定バージョンに戻る。
自動メトリクスチェック用のAnalysisTemplate
AnalysisTemplateは、評価するメトリクスとロールバックをトリガーする閾値を定義する。
# analysis-templates.yaml
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: error-rate-check
spec:
args:
- name: service-name
metrics:
- name: error-rate
interval: 60s
count: 5
successCondition: result[0] < 0.05
failureLimit: 3
provider:
prometheus:
address: http://prometheus.monitoring:9090
query: |
sum(rate(http_requests_total{
service="{{args.service-name}}",
status=~"5.."
}[5m]))
/
sum(rate(http_requests_total{
service="{{args.service-name}}"
}[5m]))
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: latency-check
spec:
args:
- name: service-name
metrics:
- name: p99-latency
interval: 60s
count: 5
successCondition: result[0] < 500
failureLimit: 3
provider:
prometheus:
address: http://prometheus.monitoring:9090
query: |
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{
service="{{args.service-name}}"
}[5m])) by (le)
) * 1000
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: comprehensive-check
spec:
args:
- name: service-name
metrics:
- name: error-rate
interval: 60s
count: 10
successCondition: result[0] < 0.02
failureLimit: 2
provider:
prometheus:
address: http://prometheus.monitoring:9090
query: |
sum(rate(http_requests_total{
service="{{args.service-name}}",
status=~"5.."
}[5m]))
/
sum(rate(http_requests_total{
service="{{args.service-name}}"
}[5m]))
- name: p99-latency
interval: 60s
count: 10
successCondition: result[0] < 300
failureLimit: 2
provider:
prometheus:
address: http://prometheus.monitoring:9090
query: |
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{
service="{{args.service-name}}"
}[5m])) by (le)
) * 1000
警告： Prometheusインスタンスに十分な保持期間とクエリパフォーマンスがあることを確認すること。Prometheusクエリが遅いとAnalysisRunがタイムアウトし、Argo Rolloutsはそれを失敗として扱い、意図しないロールバックがトリガーされる。
ブルーグリーンデプロイメント戦略
ブルーグリーンデプロイメントは、2つの完全な環境を維持し、トラフィックをアトミックに切り替える。
# blue-green-rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-app-bluegreen
namespace: my-app-prod
spec:
replicas: 5
revisionHistoryLimit: 3
selector:
matchLabels:
app: my-app
strategy:
blueGreen:
activeService: my-app-active
previewService: my-app-preview
autoPromotionEnabled: false
autoPromotionSeconds: 300
scaleDownDelaySeconds: 600
scaleDownDelayRevisionLimit: 2
prePromotionAnalysis:
templates:
- templateName: comprehensive-check
args:
- name: service-name
value: my-app-preview
postPromotionAnalysis:
templates:
- templateName: error-rate-check
args:
- name: service-name
value: my-app-active
antiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
weight: 100
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: myregistry/my-app:v2.1.0
ports:
- containerPort: 8080
ブルーグリーンのフロー：
┌─────────────────────────────────────────────────────────────┐
│ ブルーグリーンデプロイメントフロー │
│ │
│ ステップ1: プレビュー（グリーン）をデプロイ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Active │ 100%│ Stable │ │
│ │ Service │────▶│ (Blue) │ │
│ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Preview │ 0% │ New │ │
│ │ Service │────▶│ (Green) │ プロモーション前分析 │
│ └──────────┘ └──────────┘ │
│ │
│ ステップ2: プロモート（トラフィック切り替え） │
│ ┌──────────┐ ┌──────────┐ │
│ │ Active │ 100%│ New │ │
│ │ Service │────▶│ (Green) │ プロモーション後分析 │
│ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Preview │ │ Old │ 遅延後にスケールダウン │
│ │ Service │ │ (Blue) │ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────┘
重要な設定：
autoPromotionEnabled: falseは手動承認を必要とする（本番環境で推奨）scaleDownDelaySeconds: 600はプロモーション後10分間旧バージョンを維持し、迅速なロールバックを可能にするprePromotionAnalysisはプロモーション前にプレビューを検証するpostPromotionAnalysisはトラフィック切り替え後の正常性を確認する
本番環境でのロールバック戦略
分析失敗による自動ロールバック
AnalysisRunがメトリクス違反を検出すると、Argo Rolloutsは自動的にロールアウトを中止し、トラフィックを安定バージョンに戻す。手動介入は不要である。
# ロールアウト状態を監視
kubectl argo rollouts get rollout my-app -n my-app-prod --watch
# 分析実行結果を確認
kubectl argo rollouts list analysisruns -n my-app-prod
# 分析失敗の詳細理由を確認
kubectl describe analysisrun -n my-app-prod \
$(kubectl get analysisrun -n my-app-prod --sort-by=.metadata.creationTimestamp -o name | tail -1)
手動ロールバック手順
自動システムでは不十分な場合、手動ロールバックが必要になることがある。
# 方法1: ArgoCD CLIで前回の同期にロールバック
argocd app rollback my-app-production
# 方法2: Argo Rolloutsの中止とロールバック
kubectl argo rollouts abort my-app -n my-app-prod
kubectl argo rollouts undo my-app -n my-app-prod
# 方法3: 特定のリビジョンにロールバック
kubectl argo rollouts undo my-app -n my-app-prod --to-revision=3
# 方法4: Gitベースのロールバック（GitOpsネイティブアプローチ）
# Gitでコミットをリバート - ArgoCDが自動的に同期する
git revert HEAD
git push origin main
# 方法5: 緊急時 - 既知の正常なコミットに強制同期
argocd app sync my-app-production --revision abc1234
重大な警告： 自動同期が有効なアプリケーションではArgoCDのロールバックは実行できない。手動ロールバックが必要な場合は、先に自動同期を無効にするか、Gitリバートアプローチを使用すること。
# 手動ロールバック前に自動同期を無効化
argocd app set my-app-production --sync-policy none
# ロールバックを実行
argocd app rollback my-app-production
# 安定性確認後に自動同期を再有効化
argocd app set my-app-production --sync-policy automated \
--self-heal --auto-prune
部分的なロールバック失敗からのリカバリ
ロールバックが途中で停止した場合：
# ステップ1: アプリケーションの同期状態を確認
argocd app get my-app-production
# ステップ2: 停滞しているリソースを特定
argocd app resources my-app-production --orphaned
# ステップ3: 競合を解決するために強制同期
argocd app sync my-app-production --force --replace
# ステップ4: リソースが不正な状態にある場合、同期を終了して再試行
argocd app terminate-op my-app-production
argocd app sync my-app-production --prune
警告： --force --replaceを使用するとリソースが削除・再作成され、短時間のダウンタイムが発生する。最終手段としてのみ使用すること。
ApplicationSetsによるマルチクラスタ管理
複数のクラスタを管理する組織では、ApplicationSetsが環境間のアプリケーションデプロイメントを自動化する。
# multi-cluster-appset.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: my-app-multi-cluster
namespace: argocd
spec:
generators:
- clusters:
selector:
matchLabels:
env: production
values:
revision: main
- clusters:
selector:
matchLabels:
env: staging
values:
revision: develop
strategy:
type: RollingSync
rollingSync:
steps:
- matchExpressions:
- key: env
operator: In
values:
- staging
- matchExpressions:
- key: env
operator: In
values:
- production
maxUpdate: 25%
template:
metadata:
name: 'my-app-{{name}}'
spec:
project: default
source:
repoURL: https://github.com/myorg/k8s-manifests.git
targetRevision: '{{values.revision}}'
path: apps/my-app/overlays/{{metadata.labels.env}}
destination:
server: '{{server}}'
namespace: my-app
syncPolicy:
automated:
prune: true
selfHeal: true
このApplicationSetは、最初にステージングクラスタにデプロイし、次に本番クラスタに25%ずつ段階的にロールアウトするRollingSync戦略を使用する。
本番環境トラブルシューティングガイド
よくある障害シナリオと解決策
1. 同期が「Progressing」状態でスタック
# どのリソースが正常でないかを確認
argocd app get my-app-production --show-operation
# よくある原因: PodがCrashLoopBackOffまたはImagePullBackOff状態
kubectl get pods -n my-app-prod -o wide
kubectl describe pod <pod-name> -n my-app-prod
kubectl logs <pod-name> -n my-app-prod --previous
# 修正: Gitでイメージタグを更新するか、コンテナの問題を修正
# その後、強制リフレッシュ
argocd app get my-app-production --hard-refresh
2. Out-of-Syncだが差分を特定できない
# 詳細な差分を生成
argocd app diff my-app-production --local ./path/to/manifests
# 問題をマスクしている可能性のあるignoreDifferencesを確認
argocd app get my-app-production -o yaml | grep -A 20 ignoreDifferences
# よくある原因: Mutating WebhookやControllerによるリソースの変更
# 修正: Controllerが変更するフィールドにignoreDifferencesを追加
3. Repo ServerのOOMまたは遅いマニフェスト生成
# Repo Serverのログを確認
kubectl logs -n argocd -l app.kubernetes.io/component=repo-server --tail=100
# 大規模なHelmチャートや多数のアプリケーションで頻発
# 修正: Repo Serverのリソースを増加
kubectl patch deployment argocd-repo-server -n argocd --type=json \
-p='[{"op":"replace","path":"/spec/template/spec/containers/0/resources/limits/memory","value":"2Gi"}]'
4. Application ControllerのCPU使用率が高い
# Controllerのメトリクスを確認
kubectl top pods -n argocd -l app.kubernetes.io/component=application-controller
# 修正: Reconciliation間隔を調整
# argocd-cm ConfigMapで:
# timeout.reconciliation: 180s (デフォルト180秒、大規模デプロイメントでは増加)
# または大規模デプロイメント向けにControllerをシャーディング
kubectl patch statefulset argocd-application-controller -n argocd \
--type=json \
-p='[{"op":"replace","path":"/spec/replicas","value":3}]'
5. Webhook配信の失敗による同期遅延
# Webhook設定を検証
argocd admin settings validate -n argocd
# ArgoCD ServerログでWebhookイベントを確認
kubectl logs -n argocd -l app.kubernetes.io/component=server \
--tail=50 | grep webhook
# フォールバック: 手動リフレッシュを強制
argocd app get my-app-production --refresh
ヘルスチェック監視
ユーザーへの影響前に問題を検出するための適切なヘルスチェックを設定する。
# argocd-cm ConfigMap - カスタムヘルスチェック
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
namespace: argocd
data:
resource.customizations.health.argoproj.io_Rollout: |
hs = {}
if obj.status ~= nil then
if obj.status.conditions ~= nil then
for _, condition in ipairs(obj.status.conditions) do
if condition.type == "Paused" and condition.status == "True" then
hs.status = "Suspended"
hs.message = condition.message
return hs
end
if condition.type == "InvalidSpec" then
hs.status = "Degraded"
hs.message = condition.message
return hs
end
end
end
if obj.status.phase == "Healthy" then
hs.status = "Healthy"
hs.message = "Rollout is healthy"
elseif obj.status.phase == "Degraded" then
hs.status = "Degraded"
hs.message = "Rollout is degraded"
elseif obj.status.phase == "Progressing" then
hs.status = "Progressing"
hs.message = "Rollout is progressing"
end
end
return hs
通知とアラートの統合
Argo Notificationsを設定して、デプロイメントイベントをチームに通知する。
# argocd-notifications-cm ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-notifications-cm
namespace: argocd
data:
service.slack: |
token: $slack-token
trigger.on-sync-failed: |
- when: app.status.operationState.phase in ['Error', 'Failed']
send: [app-sync-failed]
trigger.on-health-degraded: |
- when: app.status.health.status == 'Degraded'
send: [app-health-degraded]
template.app-sync-failed: |
message: |
アプリケーション {{.app.metadata.name}} の同期が {{.app.status.operationState.phase}} しました。
リビジョン: {{.app.status.operationState.syncResult.revision}}
詳細: {{.app.status.operationState.message}}
slack:
attachments: |
[{
"color": "#E96D76",
"title": "{{.app.metadata.name}} 同期失敗",
"fields": [
{"title": "アプリケーション", "value": "{{.app.metadata.name}}", "short": true},
{"title": "クラスタ", "value": "{{.app.spec.destination.server}}", "short": true}
]
}]
template.app-health-degraded: |
message: |
アプリケーション {{.app.metadata.name}} のヘルスがDegradedです。
slack:
attachments: |
[{
"color": "#F4C030",
"title": "{{.app.metadata.name}} ヘルスDegraded",
"fields": [
{"title": "ヘルスステータス", "value": "{{.app.status.health.status}}", "short": true}
]
}]
ベストプラクティスチェックリスト
自動同期が有効な場合は、常にGitリバートでロールバックする。自動同期を無効にして手動ロールバックを行うのではなく、GitOpsの原則を維持する。
ArgoCDコンポーネントにリソース制限を設定する。 特にRepo Serverは、大規模なHelmチャートのレンダリング時にOOMが発生しやすい。
マルチクラスタデプロイメントにはRollingSyncを使ったApplicationSetsを使用する。 まずステージングにデプロイし、検証してから本番に段階的にロールアウトする。
AnalysisTemplateには適切な閾値を設定する。 メトリクスへの信頼度が高まるまで、緩めの閾値から始めて徐々に厳しくする。
ブルーグリーンデプロイメントでは
scaleDownDelaySecondsを600以上に設定する。 プロモーション後の分析で問題を見逃した場合に、手動でプロモーションを中止するための時間的余裕を確保する。Rolloutテンプレートでreadinessプローブとlivenessプローブを省略しない。 これらは壊れたコンテナのデプロイを防ぐ最初の防衛線である。
ArgoCD自体を監視する。 ControllerのCPU、Repo Serverのメモリ、同期キューの長さにアラートを設定する。ArgoCDが不健全になると、アプリケーションの問題がマスクされる可能性がある。
ロールバック手順を定期的にテストする。 本番環境でインシデントが発生する前に、ステージング環境でロールバックドリルを実施し、チームがプロセスに慣れるようにする。
まとめ
ArgoCDとArgo Rolloutsを組み合わせることで、Kubernetes上での本番グレードのGitOpsプラットフォームによるプログレッシブデリバリーが実現する。成功の鍵はツーリングだけでなく、その周りの運用プラクティスにある：自動メトリクス分析を伴う適切に定義されたカナリアステップ、テスト済みのロールバック手順、適切な通知とアラート、そしてリカバリプロセスを検証するための定期的なドリルである。
GitOpsモデル、つまりGitを単一の情報源とするモデルは、監査可能で、再現可能で、元に戻すことができるデプロイメントプロセスを提供する。プログレッシブデリバリー戦略と組み合わせることで、チームは自信を持ってデプロイし、自動分析で問題を早期に発見し、問題が発生した際に迅速に回復できるようになる。