Argo CD and Argo Rollouts for GitOps: The Definitive Guide

We review the comprehensive list of tools required for the course, including Docker, kubectl, Helm, and a local Kubernetes provider like Minikube or Kind. You will also get an overview of the instructor's IDE setup to help you match your environment for the coding exercises.

This guide for Windows users demonstrates how to install the Windows Subsystem for Linux (WSL) and set up an Ubuntu virtual machine. You will learn how to launch your Linux terminal and navigate the file system to bridge the gap between Windows and the course's Unix-based commands.

We dive deeper into WSL integration by configuring Visual Studio Code with the Remote - WSL extension. You will learn how to edit files directly within your Linux environment using VS Code and manage file interoperability between your Windows host and the Ubuntu virtual machine.

We outline the learning path for this section, which focuses on transitioning from standard CI/CD deployment flows to a GitOps architecture.

We analyze the limitations of the traditional push deployment model, identifying critical issues such as configuration drift, poor auditability, and inconsistent environments. This lecture explains why manual kubectl commands and opaque CI pipelines often lead to "stressful rollbacks" and a lack of a single source of truth.

This lecture breaks down the GitOps workflow, emphasizing the separation between application source code and Kubernetes configuration repositories. You will learn how Argo CD acts as a controller that continuously monitors the configuration repository to detect drift and automatically sync the live cluster state with the desired state stored in Git.

We define the four foundational principles that a system must follow to be considered GitOps: it must be Declarative, Versioned and Immutable, Pulled Automatically, and Continuously Reconciled. This lecture explains how adhering to these rules guarantees a robust and self-healing infrastructure.

We outline the roadmap for this section, which focuses on the installation and initial configuration of the tool. You will see how we plan to use Helm for deployment, access the dashboard, and set up the CLI for future operations.

The goal of this lab is to deploy the Argo CD controller and its components using the official Helm chart. You are tasked with performing a clean, version-controlled installation (targeting version 8.6.0) to ensure your cluster is ready for GitOps.

We walk through the installation process step-by-step, from adding the Argo Project Helm repository to creating a dedicated namespace. You will learn how to verify that all pods are running successfully after executing the helm upgrade command.

This lab challenges you to establish a connection to your new Argo CD instance. Your objectives are to retrieve the auto-generated admin password, expose the server locally using port forwarding, and successfully log in via both the browser and the terminal.

We demonstrate how to extract and decode the password from the argocd-initial-admin-secret and use kubectl port-forward to access the Web UI. We then conclude by installing the Argo CD CLI, authenticating to the local server, and changing the default admin password.

We outline the learning goals for this section, which include understanding the roles of Argo CD's internal components, defining the Application CRD, and performing your first hands-on deployment.

We break down the Argo CD architecture to explain how its key components function. You will learn the specific roles of the API Server, Repository Server, and Application Controller in managing communication with Git, generating manifests, and monitoring cluster state.

This lecture examines the Application Custom Resource Definition (CRD), the core declarative contract in Argo CD. We analyze its schema, specifically focusing on the source (Git repository) and destination (Kubernetes cluster) fields that define where code comes from and where it runs.

We clarify the critical distinction between the Argo CD Application resource and standard Kubernetes manifests. You will understand how the Application resource acts as a management layer that controls the actual Deployments, Services, and ConfigMaps running in your cluster.

In this lab, you are tasked with creating your first Argo CD application. You will write a YAML manifest for the "Guestbook" application, configuring it to point to a fork of the example repository and targeting your local cluster.

We walk through the solution by creating the guestbook-app.yaml file and applying it to the cluster. You will see how Argo CD detects the new application, reports an initial "Out of Sync" status, and how to trigger the first deployment via the UI.

We define the two primary indicators of application state: Sync Status and Health Status. You will learn the difference between being "Out of Sync" (configuration drift) versus "Degraded" (resource failure) and how to interpret these signals in the dashboard.

This lab challenges you to execute the complete GitOps workflow. Your objective is to modify the deployment configuration in your Git repository and verify that Argo CD detects this change.

We demonstrate the full GitOps loop by pushing a commit to the repository that scales the application from one to three replicas. You will watch Argo CD detect the configuration drift and perform a manual sync operation to align the live cluster state with the new desired state.

We introduce the section's goals, which include understanding Argo CD's unique approach to Helm, deploying charts from public repositories, and mastering the various methods to override default configuration values.

This lecture clarifies the mechanics of Helm integration. You will learn that Argo CD does not run helm install or manage Helm history; instead, it uses helm template to generate manifests and applies them via kubectl, allowing for advanced diffing and drift detection.

In this lab, you will refactor the existing "Guestbook" application to use a Helm chart instead of plain Kubernetes manifests. Your task is to modify the application source to point to the local helm-guestbook directory and configure the initial value overrides.

We walk through the migration process, highlighting a critical challenge where changing resource definitions leads to "immutable field" errors. You will learn how to resolve this by using Argo CD's "Force" and "Replace" sync options to successfully transition the application structure.

This lab expands your skills to external dependencies. You are tasked with creating a new Argo CD application that deploys the official Kubernetes Dashboard by referencing its public Helm repository URL and specific chart version.

We demonstrate how to configure an Application manifest that targets a public Helm repository. You will see how to specify the chart name and version in the source field and verify that the dashboard resources are successfully created in the cluster.

Merely deploying the dashboard isn't enough; we need to access it securely. This lecture covers creating a dedicated ServiceAccount and ClusterRoleBinding, generating an authentication token, and using kubectl port-forward to log in to the Kubernetes Dashboard UI.

We analyze the hierarchy of value overrides in Argo CD. You will learn the strict order of precedence: default values.yaml (lowest), valueFiles array, inline values object, and finally parameters (highest).

This lab challenges you to experiment with the different methods of overriding Helm values. You will define configurations using external files, inline objects, and specific parameters to observe how Argo CD applies the precedence rules.

We practically demonstrate the precedence hierarchy by setting conflicting replica counts at different configuration levels. You will observe how parameters override inline values, and how inline values override file-based settings, ensuring you know exactly how to control your production configurations.

We introduce the advanced capabilities of Argo CD that allow for "zero-touch" deployments. You will learn the roadmap for enabling automated syncing, handling deleted resources via pruning, and correcting manual cluster changes with self-healing.

This lecture defines the three pillars of Argo CD automation: Automated Sync (automatically applying Git changes), Pruning (deleting resources removed from Git), and Self-Healing (reverting manual cluster changes). We discuss the safety implications of each feature and when to enable them in your GitOps pipeline.

In this lab, you will configure your application to automatically detect and apply changes from the repository. Your task is to update the Application manifest to include the automated sync policy and enable prune: true to handle resource deletion.

We implement the automated sync policy and verify it by creating a test ConfigMap in the repository, watching it deploy automatically, and then deleting it from the source code. You will observe how enabling pruning ensures the resource is correctly removed from the cluster during the sync operation.

This lab focuses on maintaining system integrity against manual interference. You are tasked with enabling the selfHeal option and then intentionally creating configuration drift by manually scaling a deployment using kubectl to see how Argo CD reacts.

We demonstrate the "aggressive" nature of self-healing by manually scaling the application replicas and watching Argo CD immediately revert the change to match the Git state. We also discuss practical workflows, such as temporarily disabling self-healing for debugging purposes.

We outline the objectives for this section, which include understanding the need for private repository access and mastering the two primary authentication methods: HTTPS with tokens and SSH with private keys.

This lecture explains the underlying mechanism Argo CD uses to find credentials. You will learn about the specific Kubernetes Secret structure and the critical label (argocd.argoproj.io/secret-type: repository) that registers a secret as a valid credential provider for your Git repositories.

In this lab, you will practice connecting to a private repository using the HTTPS protocol. Your goal is to configure Argo CD to authenticate using a username and a Personal Access Token (PAT) instead of a password.

We start the lab setup by creating a new private repository on GitHub and populating it with the "Guestbook" Helm chart. This establishes a controlled environment where we can safely test authentication failures and successes.

We demonstrate how to generate a fine-grained Personal Access Token (PAT) in GitHub and use the Argo CD Web UI to register the repository credentials. You will see the application transition from an "Authentication Required" error to a successful sync state.

We peel back the layers of the UI configuration by manually creating the authentication Secret using kubectl. You will learn how to imperatively create the secret with the correct data fields and apply the necessary label to register it with Argo CD.

This lab introduces the SSH authentication method, which is often preferred in production for its lack of user-dependency. Your task is to switch the application source to an SSH URL and configure authentication using GitHub Deploy Keys.

We walk through the process of generating an SSH key pair using ssh-keygen, adding the public key as a specific "Deploy Key" in GitHub, and configuring Argo CD to use the private key via the Settings panel.

We replicate the SSH configuration using the command line. This lecture demonstrates how to construct a Kubernetes Secret that stores the SSH private key and links it to the repository URL, ensuring a robust, code-friendly setup.

Security is paramount when dealing with access credentials. In this final lecture, we perform a necessary cleanup by revoking the Personal Access Tokens and deleting the SSH keys created during the labs to ensure no sensitive access points are left open

We outline the advanced orchestration topics covered in this section. You will learn how to secure and isolate applications using Projects, execute custom scripts via Sync Hooks, and define strict dependency orders with Sync Waves.

We introduce the AppProject Custom Resource Definition (CRD), which allows you to group applications logically. You will learn how Projects enable multi-tenancy by enforcing guardrails—such as restricting which Git repositories, clusters, and namespaces a specific team can deploy to.

In this lab, you are tasked with moving away from the permissive default project by creating a custom "Team Finance" project. Your goal is to configure strict whitelists that only allow deployments from a specific repository into a specific finance namespace.

We walk through the creation of the AppProject manifest and attempt to assign an application to it. You will witness how Argo CD blocks the deployment with an "Invalid Spec" error when the destination doesn't match the project's whitelist, and how to resolve it by aligning the configuration.

We take a brief detour into Kubernetes internals to explain Propagation Policies: Foreground, Background, and Orphan. Understanding these concepts is crucial for knowing how Argo CD handles the deletion of applications and their dependent child resources (like Pods and ReplicaSets).

We explain how to break the standard sync operation into distinct phases: PreSync, Sync, and PostSync. You will learn how to use Argo CD Hooks to run custom logic—such as database migrations or integration tests—before or after the main application deployment.

This lab challenges you to inject a "PreSync" hook into your deployment pipeline. Your task is to define a Kubernetes Job that simulates a database migration and configure it to run and complete successfully before Argo CD updates the main application.

We implement the database migration Job, applying the argocd.argoproj.io/hook annotation to place it in the PreSync phase. We also configure the hook-delete-policy to ensure the Job is cleaned up automatically after execution, keeping the cluster clutter-free.

A common question arises: "Do all hooks in the cluster run during a sync?" This lecture clarifies the scope of hooks, demonstrating that Argo CD provides strict isolation—only hooks defined in the specific application's source repository are executed during its sync operation.

While Hooks control when logic runs relative to the sync, Sync Waves control the order of resource creation within a phase. We explain how to use the sync-wave annotation with integer values to ensure dependencies (like ConfigMaps) exist before the resources that consume them.

In this lab, you will orchestrate a multi-step deployment sequence. Your objective is to use Sync Waves to ensure a ConfigMap is created first (Wave 1), followed by a database check Job (Wave 2), and finally the main application Deployment (Wave 3).

We implement the Sync Wave annotations across our resources and trigger a deployment to watch the ordered execution in real-time. We also discuss the best practice of using non-consecutive integers (e.g., 10, 20, 30) to allow room for inserting future steps without refactoring.

We outline the roadmap for this module, which begins by analyzing the risks associated with standard rolling updates. We then move to the practical setup, covering the installation of the controller, the command-line interface, and the graphical dashboard.

We analyze the critical drawbacks of the native Kubernetes Deployment resource, specifically its "all-or-nothing" update speed and lack of fine-grained traffic control. You will understand why relying solely on readiness probes often leads to production incidents and how Argo Rollouts solves this by enabling traffic shifting and metric-based analysis.

In this lab, you are tasked with preparing your environment for progressive delivery. Your objectives are to install the Argo Rollouts controller using the official Helm chart and to manually install the kubectl-argo-rollouts CLI plugin on your local machine.

We walk through the installation process, ensuring we use a specific chart version for consistency. You will see how to verify that the controller pods are running in the argo-rollouts namespace and confirm that the CLI plugin is successfully registered with kubectl.

The Argo Rollouts dashboard is a powerful visualization tool, but it is not enabled by default. This lecture demonstrates how to update your Helm release to set dashboard.enabled: true and how to access the interface locally using the kubectl argo rollouts dashboard command.