Ultimate Argo Bootcamp by School of Devops® | 6 Projects

Get a map of the whole Argo suite before you build anything. This module walks through the story behind Argo, the GitOps principles Argo CD implements, and how ArgoCD, Argo Rollouts, Argo Workflows, Argo Events, and Argo Image Updater fit together. You will also see the architecture behind each tool (controllers and CRDs) and the use case this bootcamp builds, so you start the hands-on modules with a solid foundation.

Follow the timeline from the 2009 DevOps movement through Docker, Kubernetes, and the birth of Argo. You will see why Intuit built Argo CD, how GitOps started at Weaveworks alongside Flux CD, and when each Argo tool arrived: Workflows, CD, Rollouts, Events, and Image Updater. Knowing this history helps you understand what problem each tool was actually created to solve.

Learn the four GitOps principles that Argo CD is built on: declarative config, Git as the source of truth, approved changes through pull requests, and a software agent that continuously syncs and self-heals. You will see exactly where Argo CD fits in a CI/CD pipeline, why you keep a separate deployment repository from your source code, and how drift detection keeps your cluster matching Git.

Go past Argo CD and see what the other four tools do. You will learn how Argo Workflows runs DAG-based pipelines at scale, how Argo Rollouts adds blue-green and canary deployments that native Kubernetes cannot do, how Argo Events triggers automation from commits, webhooks, or Slack, and how Argo Image Updater bridges CI and CD by tracking your container registry. By the end you will know which tool solves which problem.

See the full project you will build across this bootcamp: a CI/CD pipeline for the Instavote microservices app. You will trace one flow end to end, where a commit fires an Argo Event, Argo Workflows runs the CI and pushes an image, Argo Image Updater updates the deployment repo, and Argo CD deploys through Argo Rollouts using blue-green in staging and canary in production. This ties every tool to a real, working use case.

Understand how Argo extends Kubernetes using controllers and CRDs. You will see how the built-in controller manager compares to custom controllers, then walk through the architecture of each tool: the Argo CD repo server, application controller, and Application CRD; the Rollout controller and its metrics integration; the Workflow executor; Argo Events sources, sensors, and the event bus; and how Image Updater reads annotations on Argo CD applications. This is the mental model you need before writing manifests.

Learn the real-world problems teams hit with Argo and how to handle them: config complexity with Kustomize or Helm, secrets with Kubernetes Secrets or Vault, RBAC and least privilege, scaling controllers, and troubleshooting through logs, the UI, and kubectl. You will also pick up best practices like starting small with one service, using GitOps for auditability, and wiring in monitoring with Prometheus and Grafana for automated rollbacks.

A quick recap of the conceptual foundation you just built: what Argo is, what each tool in the suite does (Argo CD, Rollouts, Workflows, Events, Image Updater), and where each one fits in the larger use case. You will leave ready for the hands-on work, starting with a three-node Kubernetes cluster set up using kind in the next module.

Before you touch ArgoCD, you need a cluster to work on. This lecture shows why we use kind (Kubernetes inside Docker) to spin up a three-node cluster on top of your Docker environment, and how it gives you a more production-like setup than a single-node minikube or Docker Desktop cluster. If you already run Kubernetes on cloud or VMs, you'll know when to keep it instead.

Get the Docker environment ready that everything else in this course sits on. You'll see how to launch an Ubuntu Linux server on DigitalOcean, install Docker automatically with a user-data init script, and confirm it works by checking both client and server with docker version. Already have Docker Desktop on Windows, Mac, or Linux? You can skip straight ahead. By the end you'll have a working Docker host ready for a kind Kubernetes cluster.

Build a real three-node Kubernetes cluster using kind, with no extra VMs or cloud servers needed. You'll install kind and kubectl, apply a cluster config with control plane, workers, and port mappings, then create the cluster and validate it with kubectl get nodes and kubectl get pods -A. You'll also add an optional visualizer and learn to stop, start, and reset the cluster with Docker. By the end you have a cluster ready for ArgoCD.

A quick wrap-up of the environment setup. Your Kubernetes cluster is now ready, and next you'll install the first tool in the Argo family, Argo Rollouts, to start building advanced release strategies on top of it.

Kick off the first tool in the Argo kit: Argo Rollouts. You'll learn why teams reach for Argo Rollouts instead of plain Kubernetes deployments, how it works, and which specs, controller, and CRDs you need to turn a deployment manifest into a rollout with a blue-green strategy. You'll install it on your cluster, build a blue-green release for staging step by step, and test yourself with the lab guide and quiz.

Understand the mission for this module: deploy to staging with a strategy that fixes the gaps in Kubernetes deployments. You'll see why recreate causes downtime and why rolling update leaves two versions live at once and is hard to roll back. From there you'll know exactly why blue-green with Argo Rollouts is the strategy you're about to build for the staging environment.

See exactly what Kubernetes deployments give you (recreate and rolling update) and where they fall short, then why Argo Rollouts fills the gap. You'll learn how it adds blue-green and canary releases, weighted traffic shifting through ingress controllers and service meshes, automated analysis with Prometheus and Grafana, and automatic rollbacks. By the end you'll know why blue-green for staging and canary for production is the plan for this project.

Learn to manage deployment manifests across environments with Kustomize overlays instead of Helm templates. You'll fork and clone the Argo Labs repo, install kustomize, and see how a base directory plus staging and prod overlays let you override just the values that change, like replica count and service type. Run kustomize build to preview each environment's merged output and get your manifests ready for GitOps with ArgoCD.

Install the Argo Rollouts controller and its CRDs, then create and switch to a staging namespace using kubectl config set-context. You'll see how Argo works by adding a controller plus custom resource definitions on top of the built-in Kubernetes controllers, and set up the kubectl argo rollouts plugin so you can list and inspect rollouts from the command line.

Understand how the blue-green deployment strategy works and how it differs from a rolling update. You'll learn why blue-green runs a full parallel version behind a preview service for testing, then cuts traffic over to the new version with almost no downtime, and how auto-promotion intervals and scale-down delays control the switch. Sets up the spec you'll write next in Argo Rollouts.

Deploy a plain Kubernetes deployment and service to staging using Kustomize with base and overlay directories, applied via kubectl apply -k. Then add a preview service pointing at the same pods on a second NodePort, wire it into the base kustomization, and verify with kustomize build. You'll walk away comfortable with Kustomize overlays and ready to convert the deployment into a rollout.

Migrate a Kubernetes Deployment to an Argo Rollout and add the blue-green strategy block. You'll change the kind and apiVersion, set the active and preview services, and configure autoPromotionEnabled, autoPromotionSeconds, and scaleDownDelaySeconds. Along the way you'll use git mv to rename the manifest cleanly and fix the Kustomize overlay, since replica counts can't be patched on a rollout the way they are on a deployment.

Trigger a live blue-green release by updating the image tag and watch the whole switch happen. You'll monitor it three ways: kubectl get all with service endpoints, the kubectl argo rollouts get rollout watch command, and the Argo Rollouts dashboard. See the preview service point to the new version first, auto-promotion cut the active service over, and the old ReplicaSet scale down after the delay.

Commit your rollout and preview service changes back to your forked Git repository so Argo CD can pick them up later, and create a GitHub personal access token to authenticate the git push. You'll also clean up the staging namespace with kubectl delete -k, clearing the way for the canary release lab in the next module.

A quick recap of the blue-green module: what you built with Argo Rollouts and why Kustomize was a handy alternative to Helm for managing your manifests. You'll also get a preview of what's next, moving into more advanced territory with the canary release strategy.

Starting from the 2024 CrowdStrike outage, see why canary releases matter: pushing an update to a small subset of users first instead of everyone at once. This module builds a production environment with Argo Rollouts, starts with a capacity-based canary, then adds an NGINX ingress controller for real traffic-routing rules rather than pod-count splitting.

Understand what a canary release is and why you'd roll a new version out to a small slice of traffic before it hits everyone. You'll see how Argo Rollouts shifts traffic step by step, starting with a simple capacity-based canary and building toward routing rules with an Nginx ingress controller. By the end you'll know how progressive delivery limits the blast radius when a bad version ships.

Set up a separate prod namespace in the same cluster and wire up the active and preview services your canary needs. You'll create a Kustomize overlay for prod, change the node ports so staging and production don't clash, and deploy the initial rollout. After this you can watch the rollout from both the Argo Rollouts dashboard and the command line, ready to switch strategy.

Write the canary strategy into your rollout spec using weighted steps and pauses. You'll add a Kustomize overlay that overrides just the strategy and replica count, disable blue-green by setting it to null, and define 20/40/60/80/100 percent steps with a wait between each. You'll come away able to author a canary spec and control how fast a new version rolls out.

Watch a canary release run end to end as you bump the image tag in the base rollout and apply it. You'll see traffic shift 20 percent at a time as pods scale up and down, track each step on the Argo Rollouts dashboard and through service endpoints, and roll out several versions in a row. This shows how a canary differs from a plain rolling update and where automated rollbacks fit in.

Install the Nginx ingress controller with Helm and add an ingress rule that routes vote.example.com to your service by hostname instead of IP. You'll fix the common pending-pod scheduling issue by labelling a node ingress-ready to satisfy the affinity rule, then edit your local hosts file to reach the app. This sets up host-based and path-based routing as the foundation for traffic shifting.

Move traffic shifting off pod capacity and onto the Nginx ingress controller. You'll add trafficRouting to the canary strategy, point it at the stable and canary ingresses, and use setCanaryScale to hold the canary pods at a fixed count for faster rollbacks. After this the ingress controller decides the weight sent to each version, independent of how many pods are running.

A recap of the progressive canary module: writing the canary spec with steps, running a capacity-based canary across active and preview services, and layering an Nginx ingress controller on top to route traffic by rule rather than pod count. You'll also see what's next, tying these rollout strategies to GitOps with Argo CD and pull-request-driven promotion to production.

A quick look at where GitOps came from and why Argo CD became the standard tool for continuous delivery on Kubernetes. This module covers how Argo CD works, configuring applications through both the UI and YAML manifests, and plugging in the blue-green and canary strategies you already built. You'll set up a pipeline that auto-deploys to staging and gates production behind a pull request.

Set up the Git side of a GitOps workflow so staging deploys automatically and production needs a manual approval. You will create a release branch, add branch protection rules on GitHub, and require a pull request before any merge. By the end you can lock down the release branch and use trunk-based development to gate production deployments with ArgoCD.

Write the production ArgoCD Application spec by exporting your existing staging app to YAML and editing it. You will clean up the manifest, point it at the release branch and the prod path and namespace, and apply it directly so the Application still lives in the argocd namespace. By the end you can define a prod Application by hand and watch its first sync with Kustomize and Argo Rollouts.

Watch a full continuous delivery pipeline run end to end. You commit an image tag change to main, see ArgoCD auto-sync staging with a blue-green rollout, then raise a pull request from main to the release branch to trigger a canary deployment to production. By the end you understand how the pull request acts as a manual lever for prod releases with ArgoCD and Argo Rollouts.

A recap of everything in the ArgoCD module: installing the controllers and CRDs, configuring the UI, writing Application and project specs, and pointing sources at Git or Helm repositories. You will review how staging was built through the UI and production through hand-written YAML, plus how ArgoCD sync options work. Solid closing checkpoint before moving on to Argo Workflows and CI.

Meet Argo Workflows, the first tool built in the Argo suite, designed to run steps and jobs in sequence, in parallel, or as a directed acyclic graph (DAG). You will see why it works for far more than pipelines, from ML jobs to scheduled tasks. This module focuses on one job: building a continuous integration (CI) pipeline with Argo Workflows.

See where the CI pipeline fits now that blue-green, canary, and the ArgoCD delivery pipeline are done. You will map out the build, test, and package stages you will create with Argo Workflows, much like you would in Jenkins. By the end you understand the goal for this module: a container-based CI pipeline that publishes an image to Docker Hub, ready to link with Argo Events and Image Updater later.

Learn how Argo Workflows works as a Kubernetes-native engine built on CRDs and controllers. You will see the three workflow types (steps, DAG, and sequential), how a spec uses an entry point to call leaf templates like clone, build, and test, and the template kinds available: container, container set, script, resource, and data. By the end you can read an Argo Workflow manifest and know which template fits each CI stage.

Spin up Argo Workflows fast in a browser-based Killercoda playground instead of overloading your local kind cluster. You will launch the environment, open the Argo Workflows UI server, clear the namespace filter to see all workflows, and inspect the controller, CRDs, and API resources it installs. By the end you have a clean cloud lab ready for submitting workflows with the argo CLI.

Start running real Argo Workflows from the examples directory. You'll submit the hello-world container template with argo submit --watch, follow it live in the Argo UI, and read logs with argo logs. Then you'll pass input parameters into a container, override defaults with -p, and see why generate name gives every run a unique name.

Move past single containers into orchestration. You'll run a steps-based workflow to see sequential and parallel steps, then build a DAG (directed acyclic graph) where you declare dependencies explicitly and get the classic diamond shape. By the end you can pick steps or DAG for the job, and use withItems to fan out steps like b1, b2, b3 in a hierarchical workflow.

Pass data between steps using artifacts. You'll generate a file in one step, output it as a named artifact, and consume it in the next step where Argo archives it as a tar.gz. Then you'll use the script template to run inline bash or Python inside a container and capture its result as an output parameter — the same pattern you'll reuse for CI build, test, and package jobs.

Handle state and control in your workflows. You'll share a dynamically provisioned PVC across steps with a volumeClaimTemplate, watch it appear and clean up with kubectl get pvc, and add manual approval using the suspend template (plus a time-based delay). You'll also run a resource template to create Kubernetes objects, hit RBAC permission errors, and clean up with argo delete.

Plan a real CI pipeline for a Python Flask voting app before writing any YAML. You'll map out the clone, build, test, and package stages, see why steps (not a DAG) fit a sequential pipeline, and why a shared volume carries the cloned code across stages. Then you'll create a Kubernetes secret with a Docker Hub access token so the package stage can push the image.

Read the full CI workflow spec line by line. You'll see how clone, build, test, and image-build run as steps, how a workspace PVC and a Docker config secret mount into every stage, and how the clone step outputs a commit SHA used to tag the image uniquely. You'll also learn why Kaniko builds and pushes container images inside Kubernetes without a Docker daemon.

Run your CI pipeline end to end with argo submit, passing repo URL, branch, image, and Dockerfile path as parameters. You'll watch clone, build, test, and Kaniko image-build execute, confirm the PVC binds, and see the image land on Docker Hub tagged by commit ID. Then you'll push a new commit, rerun, and verify the fresh image with docker run to prove the pipeline picked up your change.

Pull the whole workflows module together. You'll recap setting up Argo Workflows on a Killercoda cloud lab, running container, parameter, steps, DAG, artifact, volume, and script examples, and building a working CI pipeline with clone, build, test, and Kaniko package stages. This sets up the next module, where Argo Events connects CI to CD and triggers the pipeline automatically.

Get an overview of the two tools that close the last gaps in an Argo pipeline: Argo Events, which triggers your workflows from Git pushes, webhooks, Slack messages, or queue events, and Argo Image Updater, which watches your registry and updates the image tag in Git to trigger deployment. By the end you will know how these tools connect CI to CD for a fully automated flow.

See where the full use case stands and what is left to automate. You will map the two missing links: using Argo Events to trigger the Argo Workflows CI pipeline on every Git push, and using Argo Image Updater to update the deployment tag when a new image lands in the registry. Walk away understanding how these connections put your CI/CD pipeline on autopilot.

Understand how Argo Events works through its core pieces: event sources, sensors, and workflow templates. You will learn why a webhook event source plus a polling pod works in any environment without exposing your cluster to the internet, unlike a direct Git webhook. This sets you up to wire an event source to a sensor that launches your CI workflow from a template.

Install the Argo Events controller and its components into a dedicated namespace, add the RBAC it needs to launch workflows, and check everything with kubectl get all. You will create a webhook event source listening on port 12000, convert your CI pipeline into a reusable WorkflowTemplate, and add the registry credentials secret so images can publish to Docker Hub.

Build the Argo Events sensor that watches your webhook event source and submits the CI workflow from its template. You will set the dependency on the GitHub webhook, point the trigger at your workflow template, and pass in the repository URL, branch, image tag, and Dockerfile path, the same values you would give an argo submit command. This completes the event flow from source to sensor to workflow.

Deploy a GitHub poller as a Kubernetes CronJob that checks your repository every minute and fires the webhook event source when it spots a new commit. You will set your repository, add the GitHub token secret so the poller can read commit history, and watch a push automatically kick off the CI pipeline through Argo Events, no manual submit needed.

Learn how Argo Image Updater bridges CI and CD by watching your registry and committing new image tags to the deployment repo that Argo CD syncs. You will see why it needs Argo CD to run, how it reads application annotations to know which app and repo to update, and how to install it as a controller in the Argo CD namespace alongside Argo Rollouts.

Watch the full GitOps pipeline run end to end. You will create a git-credentials secret with a commit-access token, annotate the staging application so Argo Image Updater filters registry tags by regex, and see it commit the new tag automatically. From there Argo CD triggers a blue-green rollout to staging, and a pull request to the release branch promotes it to production with a canary release.

Download the Lab Guides for Argo Image Updater.

Recap of everything you built with Argo Events: event sources, sensors, and converting a workflow into a workflow template. You'll revisit the git-based polling that triggers your CI pipeline on every new commit, and see how Argo Image Updater closes the gap between CI and CD by watching a container registry and committing new image tags back to your manifest repo. By the end you have a working, connected GitOps CI/CD pipeline.

Your CI/CD pipeline works, but progressive canary releases still lean on manual testing at each traffic step. Here you'll see why Argo Rollouts is worth swapping in for the default Kubernetes deployment: it can watch a release as it happens, run automated checks, and roll back on its own. This module wires rollouts into Prometheus and Grafana so functional tests, load tests, and metric analysis drive the release for you.

Walk through Mission #6, where you make your blue-green and canary releases safer by adding experiments and analysis to Argo Rollouts. You'll plan how to run a functional test before shifting traffic and a load test with live monitoring partway through the canary, so a version that can't handle realistic load gets rolled back automatically. This is why rollouts replace default Kubernetes deployments for advanced release control.

Understand the AnalysisRun, AnalysisTemplate, and Experiment CRDs and how they slot into a canary release. You'll learn the difference between an experiment (fresh pods and a canary service, no traffic shifted) and an analysis (checks that run while traffic is shifting), plus how to gate each canary step on a fitness test up front and latency-based load testing later. The goal: safer, more reliable releases with automatic rollback.

Set up the monitoring stack your automated analysis will depend on. You'll enable the Kubernetes metrics server so kubectl top nodes and kubectl top pods work, then install the kube-prometheus-stack Helm chart from Artifact Hub to bring up Prometheus and Grafana with dashboards pre-wired. By the end you can log into Grafana on its NodePort and explore CPU and memory metrics per namespace.

Get Prometheus scraping metrics from your NGINX ingress controller. You'll confirm the metrics are missing, redeploy ingress-nginx with metrics enabled, and use kubectl port-forward to check the raw data in the Prometheus UI. Then you'll import a Grafana dashboard from JSON to watch request volume and latency live — the exact signals your canary analysis will use later to decide whether to promote or roll back.

Read through the AnalysisTemplate manifests before you apply them. You'll see the fitness-test template that curls the canary service, the load-test template that drives traffic with siege, and the latency template that runs a Prometheus query and rolls back if latency crosses 50 milliseconds. You'll also learn how metric intervals, failure limits, and success conditions decide whether a release keeps going or gets pulled.

Wire the experiment and analysis into your canary strategy hands-on. You'll patch the prod rollout to run a fitness-test experiment before the first traffic shift and a load-test plus latency analysis after 60%, add a canary header so tests hit only the new version, and fix the ingress node IP the load test resolves to. Then you'll register the templates in your Kustomize resources and apply everything with kubectl apply -k.

Watch a canary release run end to end with Argo Rollouts driving experiments and analysis runs on autopilot. You will push a new image tag, trigger the rollout, and follow the weight shifting from 20% to 60% to 100% while latency, success rate, and load test metrics are checked against thresholds. By the end you can inspect experiments and analysis runs with kubectl and read the signals that decide whether a version rolls out or rolls back.

Download the Lab Guides for this Module.

A recap of how you wired canary releases into a full monitoring stack using Argo Rollouts, Prometheus, and Grafana. You will see the difference between experiments and analysis, how analysis templates and metrics turn a rollout into a self-checking, auto-rollback pipeline, and how the five tools — Argo CD, Rollouts, Workflows, Events, and Image Updater — come together into one CI/CD setup for safe continuous delivery on Kubernetes.