Agent-almanac implement-gitops-workflow
git clone https://github.com/pjt222/agent-almanac
T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/ja/skills/implement-gitops-workflow" ~/.claude/skills/pjt222-agent-almanac-implement-gitops-workflow-c12c49 && rm -rf "$T"
i18n/ja/skills/implement-gitops-workflow/SKILL.mdGitOpsワークフローの実装
Argo CDまたはFluxを使用したGitOps原則でKubernetesアプリケーションをデプロイ・管理し、自動化・監査可能・再現可能なデプロイを実現します。
使用タイミング
- 宣言的インフラおよびアプリケーション管理の実装
- 命令型kubectl/helmコマンドからGit駆動デプロイへの移行
- マルチ環境プロモーションワークフローのセットアップ(dev → staging → prod)
- 本番デプロイにコードレビューと承認ゲートを強制
- Gitの履歴によるコンプライアンスと監査要件の達成
- Gitをシングルソースオブトゥルースとするディザスタリカバリの実装
入力
- 必須: 管理者アクセス権付きのKubernetesクラスター(EKS、GKE、AKS、またはセルフホスト)
- 必須: KubernetesマニフェストおよびHelmチャート用Gitリポジトリ
- 必須: Argo CDまたはFlux CLIのインストール
- 任意: シークレット管理のためのSealed SecretsまたはExternal Secrets Operator
- 任意: 自動イメージプロモーションのためのImage Updater
- 任意: 同期ステータス監視のためのPrometheus
手順
完全な設定ファイルとテンプレートについては拡張例を参照してください。
ステップ1: Argo CDのインストールとリポジトリアクセスの設定
Argo CDをクラスターにデプロイし、Gitリポジトリに接続します。
# Namespaceの作成 kubectl create namespace argocd # Argo CDのインストール kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml # Podの準備完了を待機 kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=argocd-server -n argocd --timeout=300s # Argo CD CLIのインストール curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64 sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd rm argocd-linux-amd64 # UIへのアクセスのためにポートフォワード kubectl port-forward svc/argocd-server -n argocd 8080:443 & # 初期管理者パスワードの取得 ARGOCD_PASSWORD=$(kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d) echo "Argo CD Admin Password: $ARGOCD_PASSWORD" # CLIでログイン argocd login localhost:8080 --username admin --password "$ARGOCD_PASSWORD" --insecure # 管理者パスワードの変更 argocd account update-password # Gitリポジトリの追加(HTTPSとトークン) argocd repo add https://github.com/USERNAME/gitops-repo \ --username USERNAME \ --password "$GITHUB_TOKEN" \ --name gitops-repo # またはSSHで追加 ssh-keygen -t ed25519 -C "argocd@cluster" -f argocd-deploy-key -N "" # argocd-deploy-key.pubをGitHubリポジトリのデプロイキーに追加 argocd repo add git@github.com:USERNAME/gitops-repo.git \ --ssh-private-key-path argocd-deploy-key \ --name gitops-repo # リポジトリ接続の確認 argocd repo list # UIのIngressの設定(任意) cat <<EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-ingress namespace: argocd annotations: cert-manager.io/cluster-issuer: letsencrypt-prod nginx.ingress.kubernetes.io/ssl-passthrough: "true" nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" spec: ingressClassName: nginx tls: - hosts: - argocd.example.com secretName: argocd-tls rules: - host: argocd.example.com http: paths: - path: / pathType: Prefix backend: service: name: argocd-server port: number: 443 EOF
期待結果: Argo CDがargocd Namespaceにインストール済み。UIはポートフォワードまたはIngressでアクセス可能。デフォルトの管理者パスワードが変更済み。SSHまたはトークン認証でGitリポジトリが追加済み。リポジトリ接続が確認済み。
失敗時: PodのCrashLoopBackOffは
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-serverでログ確認。リポジトリ接続の失敗はトークンのリポジトリアクセスまたはSSHキーのデプロイキー追加を確認。IngressのSSL問題はcert-managerが証明書を正常に発行しているか確認。ログイン失敗は再度パスワードを取得するか、kubectl delete secret argocd-initial-admin-secret -n argocdでリセットしてサーバーを再起動。
ステップ2: アプリケーションマニフェストの作成と最初のアプリケーションのデプロイ
同期ポリシーとヘルスチェック付きのArgo CDアプリケーションリソースを定義します。
# Gitリポジトリ構造の作成 mkdir -p gitops-repo/{apps,infra,projects} cd gitops-repo # サンプルアプリケーションの作成 mkdir -p apps/myapp/overlays/{dev,staging,prod} mkdir -p apps/myapp/base # ベースKustomization cat > apps/myapp/base/kustomization.yaml <<EOF apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - deployment.yaml - service.yaml EOF cat > apps/myapp/base/deployment.yaml <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: myapp image: ghcr.io/username/myapp:v1.0.0 ports: - containerPort: 8080 EOF cat > apps/myapp/base/service.yaml <<EOF apiVersion: v1 kind: Service metadata: name: myapp spec: selector: app: myapp ports: - port: 80 targetPort: 8080 EOF # 本番オーバーレイ cat > apps/myapp/overlays/prod/kustomization.yaml <<EOF apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: production resources: - ../../base replicas: - name: myapp count: 5 images: - name: ghcr.io/username/myapp newTag: v1.0.0 EOF # Gitにコミット git add . git commit -m "Add myapp application manifests" git push # Argo CDアプリケーションの作成 cat > argocd-apps/myapp-prod.yaml <<EOF apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp-prod namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: project: default source: repoURL: https://github.com/USERNAME/gitops-repo targetRevision: main path: apps/myapp/overlays/prod destination: server: https://kubernetes.default.svc namespace: production syncPolicy: automated: prune: true # Gitから削除されたリソースを削除 selfHeal: true # ドリフト検出時に自動同期 allowEmpty: false syncOptions: - CreateNamespace=true - PruneLast=true retry: limit: 5 backoff: duration: 5s factor: 2 maxDuration: 3m revisionHistoryLimit: 10 EOF # kubectlでアプリケーションを適用 kubectl apply -f argocd-apps/myapp-prod.yaml # またはCLIで作成 argocd app create myapp-prod \ --repo https://github.com/USERNAME/gitops-repo \ --path apps/myapp/overlays/prod \ --dest-server https://kubernetes.default.svc \ --dest-namespace production \ --sync-policy automated \ --auto-prune \ --self-heal # 同期ステータスの監視 argocd app get myapp-prod --watch # アプリケーションの確認 kubectl get all -n production argocd app sync myapp-prod # 自動同期が無効の場合は手動同期
期待結果: アプリケーションがGitから自動的に同期済み。リソースがproduction Namespaceに作成済み。Argo CD UIがhealthyステータスを表示。自動同期ポリシーによりpruneとself-healが有効。リトライ制限内で同期が成功。
失敗時: 同期の失敗は
argocd app get myapp-prodとkubectl get events -n productionでイベントを確認。Kustomizeビルドエラーはkustomize build apps/myapp/overlays/prodでローカルテスト。Namespaceエラーはnamespaceの存在確認またはCreateNamespace同期オプションの有効化。Pruningの問題はkubectl get <resource> -o yamlでfinalizersとオーナーリファレンスを確認。
ステップ3: マルチ環境管理のためのApp-of-Appsパターンの実装
複数環境にわたる子アプリケーションを管理するルートアプリケーションを作成します。
# app-of-apps構造の作成 mkdir -p argocd-apps/{projects,infra,apps} # RBACのためのプロジェクト定義 cat > argocd-apps/projects/production.yaml <<EOF apiVersion: argoproj.io/v1alpha1 # ... (完全な設定はEXAMPLES.mdを参照)
期待結果: ルートアプリが全ての子アプリケーションを管理。新しいアプリケーションはGitに追加されると自動的にデプロイ。インフラアプリがアプリアプリケーションより先にデプロイ(必要に応じて同期ウェーブを使用)。プロジェクトがRBAC境界を強制。アプリツリーが親子関係を表示。
失敗時: 循環依存は同期ウェーブで順序を制御。プロジェクト権限エラーはsourceReposとdestinationsがアプリケーション要件と一致しているか確認。再帰的ディレクトリの問題はYAMLファイルが有効で競合がないか確認。子アプリが見つからない場合は
argocd app get root-appでルートアプリのステータスを確認。
ステップ4: 自動デプロイのためのImage Updaterの設定
新しいイメージバージョンを自動的にプロモーションするArgo CD Image Updaterをセットアップします。
# Argo CD Image Updaterのインストール kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/stable/manifests/install.yaml # アノテーションによるイメージ更新戦略の設定 cat > argocd-apps/myapp-prod-autoupdate.yaml <<EOF apiVersion: argoproj.io/v1alpha1 # ... (完全な設定はEXAMPLES.mdを参照)
期待結果: Image Updaterがタグパターンに一致する新しいイメージをレジストリで監視。セマンティックバージョニング戦略が最新の安定リリースに更新。新しいイメージタグで自動的にGitコミットが作成。アプリケーションが更新されたイメージで同期。Stagingはイミュータブルデプロイのためにdigestストラテジーを使用。
失敗時: レジストリアクセスエラーはimage-updaterがSecretまたはServiceAccountでプルクレデンシャルを持っているか確認。ライトバック失敗はgit-credsシークレットがプッシュ権限を持っているか確認。更新が検出されない場合は
argocd-image-updater test ghcr.io/username/myappで実際のタグとタグ正規表現の一致を確認。認証問題はimage-updaterのログで詳細なエラーメッセージを確認。
ステップ5: Argo Rolloutsによるプログレッシブデリバリーの実装
自動ロールバック付きのカナリアとブルーグリーンデプロイを有効にします。
# Argo Rolloutsコントローラーのインストール kubectl create namespace argo-rollouts kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml # Rollouts kubectlプラグインのインストール curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64 # ... (完全な設定はEXAMPLES.mdを参照)
期待結果: Rolloutがカナリアにトラフィックをプログレッシブにシフト。各ステップで分析が実行され成功率を検証。成功時は自動プロモーション、失敗時はロールバック。Argo CDがRolloutリソースを同期。ダッシュボードがリアルタイムのロールアウト進捗を表示。
失敗時: 分析の失敗はPrometheusがアクセス可能でクエリが有効な結果を返すか確認。トラフィックルーティングの問題はIngressアノテーションとカナリーサービスエンドポイントを確認。スタックしたロールアウトは手動でプロモーションまたは中止。リビジョンの不一致はArgo CDの同期ポリシーがRolloutsコントローラーの更新と競合していないか確認。
ステップ6: ドリフト検出とWebhook通知の設定
手動変更を監視し、Slack/メールにアラートを送信します。
# アプリケーションでのドリフト検出の設定 cat > argocd-apps/myapp-strict.yaml <<EOF apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp-prod # ... (完全な設定はEXAMPLES.mdを参照)
期待結果: Self-healが手動kubectl変更を自動的にリバート。同期の失敗と成功したデプロイでSlackに通知。Webhookが外部システムをトリガー(PagerDuty、モニタリング、ITSM)。ドリフトアラートが変更内容と変更者(Gitの履歴から)を表示。
失敗時: Self-healがトリガーされない場合は自動同期ポリシーが有効でリフレッシュ間隔が長すぎない(デフォルト3分)か確認。通知の失敗はcurlでSlackトークンをテストしてボットがチャンネルに追加されているか確認。ignoredDifferencesが機能しない場合はJSONポインター構文がリソース構造と一致するか確認。Webhookエラーはエンドポイントのアクセシビリティと認証ヘッダーを確認。
バリデーション
- Argo CDまたはFluxがインストールされUI/CLIでアクセス可能
- 適切な認証でGitリポジトリが接続済み
- アプリケーションがコミット後にGitから自動的に同期
- 手動kubectl変更がself-healによってリバート済み
- App-of-appsパターンが複数アプリケーションをデプロイ
- Image Updaterがタグパターンに基づいて新しいイメージをプロモーション
- Argo Rolloutsがプログレッシブカナリアデプロイを実行
- 同期イベントでSlack/メールに通知が送信済み
- ドリフト検出が帯域外変更をアラート
- RBACがプロジェクトレベルのアクセス制御を強制
よくある落とし穴
-
自動pruneが無効: Gitから削除されたリソースがクラスターに残る。同期ポリシーで
を有効にする。prune: true -
同期ウェーブなし: アプリが依存するインフラアプリがアプリの後にデプロイされる。
アノテーションで順序を制御する。argocd.argoproj.io/sync-wave -
HPAが管理するレプリカを無視: HPAがレプリカ数を変更して同期が失敗。
をignoredDifferencesに追加する。/spec/replicas -
ライトバックの競合: Image UpdaterのコミットがGitの手動コミットと競合。別ブランチまたはimage updaterのきめ細かいRBACを使用する。
-
finalizersの欠如: アプリケーション削除で孤立したリソースが残る。アプリケーションメタデータに
を追加する。resources-finalizer.argocd.argoproj.io -
分析テンプレートなし: ロールアウトが検証なしで自動的にプロモーション。メトリクスクエリを持つAnalysisTemplatesを実装する。
-
Gitにシークレット: 平文シークレットがリポジトリにコミットされる。Sealed SecretsまたはExternal Secrets Operatorを使用する。
-
過度なself-heal: Self-healが正当な緊急変更をリバートする。アノテーションで一時的に無効化するか承認ゲートを実装する。
関連スキル
- GitOps用のGitリポジトリ構造のセットアップconfigure-git-repository
- 環境プロモーションのためのブランチ戦略manage-git-branches
- GitOpsが管理するKubernetesリソースの理解deploy-to-kubernetes
- Argo CDとのSealed Secrets統合manage-kubernetes-secrets
- CIがイメージをビルド、GitOpsがデプロイbuild-ci-cd-pipeline
- レジストリ間のイメージプロモーションsetup-container-registry