Introduction to Argo CD

Learn about Git as the single source of truth, assess declarative configuration and examine automatic reconciliation as GitOps foundations. Then compare pull-based workflows with traditional CI/CD and examine the roles of Argo CD and Flux in the CNCF ecosystem. Use a scenario to identify which differences matter for the team, platform and operating model.

The DevNinjas Dojo, our cloud learning environment, provides the lab cluster for installing Argo CD with a Helm chart. You examine how the Application Controller, Repo Server, API Server and cache interact and navigate the web interface and CLI. Then create an AppProject and connect a prepared Git repository; participant production environments remain outside this exercise.

Create an Application resource and link it to a Git repository. Compare manual and automated sync in an example. Then investigate OutOfSync and Degraded as distinct states and observe the application status in the UI; as part of this, assess how desired state and application status relate.

Drift describes differences between desired and current state. You enable self-heal as an explicit automated-sync option, configure pruning deliberately, order resources with sync waves and hooks, and test retry settings for a failed sync. Rollback uses application history and is unavailable while auto-sync is enabled.

Compare Git revert, an Argo CD history entry and a manual correction as distinct recovery paths. Account for the interaction between rollback and automated sync. Back up and reconstruct selected key Application, project and repository configurations in a prepared, controlled technical recovery scenario for practice.

You work with Helm charts as manifest sources; you create Applications with values files for several learning environments. You examine chart repositories and consider OCI sources; in the same example, you examine the precedence of values, values files and overrides. Then assess which configuration should remain traceable in the Git repository.

With Kustomize, work with overlays and patches for development, staging and production. Inspect the generated state and deploy it through Argo CD. At the end, in a direct comparison, you contrast Helm and Kustomize; you examine the reuse of structures and adapt base manifests for each environment.

Sketch mono-repository and multi-repository variants for application code and configuration. A pull request accompanies a stepwise promotion between prepared environments, exposing review, approval and history. Compare the advantages and disadvantages of both variants for collaboration and traceability without declaring one model a universal best practice for teams.

ApplicationSets generate Applications dynamically from shared templates. Examples include List with a static cluster list, Cluster with clusters registered in Argo CD, Git with directories and files, and Pull Request for preview environments per pull request. Other generator options and multi-cluster deployments remain outside the practical scope of this workshop.

Model a root Application with child Applications while building the pattern yourself as a hands-on exercise for multiple applications in the prepared learning environment. Discuss its limitations through dependencies between Applications and sync ordering. Then compare App of Apps with ApplicationSets: explicit hierarchy on one side and generated Applications on the other.

Configure AppProjects to restrict permitted destination namespaces and investigate fine-grained RBAC rules for distinct roles and access permissions. Then set up SSO via OIDC with Dex and consider different permissions for teams. The examples remain limited to the prepared learning environment and this workshop context.

In the prepared learning environment: Sealed Secrets encrypts data in the repository with kubeseal, the External Secrets Operator connects selected external secret stores such as HashiCorp Vault, and SOPS uses age-encrypted files. Plaintext secrets remain outside Git. Complexity, security and maintainability structure the comparison of these approaches and their operational boundaries.

Install the Argo Rollouts controller and model canary and blue-green steps in a Rollout resource. AnalysisTemplates, traffic routing, a preview service and manual promotion provide different control points. AnalysisRuns affect the rollout update; you examine the exact mapping between phase, effect and required manual decision as an open question in the controlled scenario.

Argo CD notifications send events to configured recipients; Prometheus metrics capture observability data for sync and health states of Argo CD-managed Applications. Configure notifications for Slack, Microsoft Teams and webhooks and define triggers for sync failures, health degradation and successful deployments. Next, collect Argo CD metrics and visualise sync duration, application health and reconciliation cycles in Grafana.

A prepared GitLab CI pipeline publishes an image and updates its reference in the configuration repository instead of writing directly to the cluster. You then trace the Git revision through the workflow during the workshop. This concrete flow clarifies the boundary between build, desired state, and deployment.