Lesson 14 GitOps with ArgoCD
Theme:

Homework 14 — GitOps with ArgoCD

Lesson 14 · Cloud Infrastructure & DevOps · Three tasks

These three tasks extend the GitOps foundation from the lab. Task 1 adds ArgoCD notifications so you get a Slack (or webhook) ping on every sync event. Task 2 is a design exercise: migrating values-prod.yaml secrets to Sealed Secrets or external-secrets-operator without ever committing a plaintext secret to git. Task 3 is a read-and-compare on Argo Rollouts — the progressive delivery layer that sits on top of ArgoCD and replaces the L13 blue/green primitive with metric-gated canary releases.

Task 1 — Add a notifications ArgoCD child Application

Install argocd-notifications via an ArgoCD child Application in children/. Configure a subscription so that the url-shortener Application posts to a webhook whenever it syncs or goes OutOfSync. If you do not have a real Slack webhook, point at webhook.site and inspect the requests in the browser.

  1. Create cloud-devops/sample-app/argocd/children/argocd-notifications.yaml installing the Helm chart from https://argoproj.github.io/argo-helm, chart argocd-notifications, version 1.8.1. Set sync-wave: "-1". Configure a service.webhook.test-hook notifier pointing at your webhook URL. Enable triggers on-sync-succeeded, on-sync-failed, on-health-degraded.
  2. Add the subscription annotation to the url-shortener Application CR: notifications.argoproj.io/subscribe.on-sync-succeeded.test-hook: "".
  3. Push, watch the App-of-Apps pick up the new child, and confirm argocd-notifications deploys cleanly.
  4. Make a trivial values-file change, push, and watch the webhook fire within 5 min.

Self-check: the webhook payload includes the Application name and the sync revision SHA. Subscribing to on-sync-running fires on every reconciliation (every 3 min) — subscribe to on-sync-succeeded and on-sync-failed only.

Task 2 — Secrets without committing secrets

Read the Sealed Secrets docs and the external-secrets-operator (ESO) docs. Pick one and write a 15-line plan for migrating values-prod.yaml’s secret values (database password, OAuth client secret if any) to that mechanism.

Your plan must cover:

  1. Which CRD encodes the secret (name the CRD exactly).
  2. Where the unencrypted value lives (developer laptop, external vault, etc.).
  3. How to rotate a secret without committing any new plaintext value.

This is a reading and design exercise only — do not implement it in the cluster.

Self-check: the plan names the exact CRD (SealedSecret or ExternalSecret), the exact controller, and addresses all three points above. If you pick ESO, name the SecretStore backend you would use (e.g., HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager).

Task 3 — Canary with Argo Rollouts (read-only)

Read the Argo Rollouts introduction. Write a one-page comparison covering:

  1. How the Rollout CR differs from a standard Deployment (name at least one field from spec.strategy.canary).
  2. What analysis blocks do — explain the AnalysisTemplate CR and how a Prometheus query gates the canary promotion.
  3. One concrete reason to stick with the blue/green approach from L13 instead of moving to Argo Rollouts.

Self-check: the comparison cites at least one specific CRD field name from the Rollout spec (e.g., spec.strategy.canary.steps, spec.strategy.canary.analysis). It names the AnalysisTemplate CRD explicitly.

View solutions →