GitOps Workflow Simulator
Learn GitOps principles through interactive scenarios. Understand Git as source of truth, automated sync, and drift detection.
Category: DevOps
What You Will Learn
- Understand the GitOps deployment model
- Trace changes from commit to production
- Learn reconciliation and drift detection
Topics covered: gitops, kubernetes, argocd, educational, interactive
// simulator
GitOps Workflow Simulator
Learn GitOps principles through interactive scenarios. Understand Git as source of truth, automated sync, and drift detection.
GitOps Workflow Simulator
Learn GitOps principles through interactive scenarios
GitOps is a modern approach to continuous deployment where Git serves as the single source of truth for declarative infrastructure and applications.
Git as Source of Truth
All desired state is stored in Git repositories
Automated Sync
Operators continuously reconcile actual state with desired state
Drift Detection
Automatic detection and correction of configuration drift
- How GitOps operators synchronize Git state with Kubernetes clusters
- Understanding sync status, health status, and configuration drift
- When to use automatic sync vs manual approval
- How to handle deployments, rollbacks, and drift correction
Overview
GitOps treats a Git repository as the single source of truth for what should run in a cluster, and an operator such as Argo CD or Flux keeps the cluster matching it. This simulator lets you watch that loop. You create commits, deploy one, and follow the change as it moves from Git to the GitOps operator and from the operator to Kubernetes, with the sync and health status updating along the way. You can switch automatic sync on and off to see the difference between an operator that applies every commit and one that waits for a manual sync. A drift scenario changes the live cluster by hand, the way a quick kubectl edit would, and shows the operator detecting that the cluster no longer matches Git. Three challenges then ask what a GitOps operator should do about configuration drift, what the GitOps way to roll back is, and which sync policy suits critical production workloads. The core idea is that changes reach production through Git commits, so history, review and rollback all come from the repository.
Try this
- Create a new commit and deploy it, following the change from Git to the operator to Kubernetes.
- Turn automatic sync off, run the drift scenario and use the manual sync to bring the cluster back in line.
- Answer the "Deployment Rollback" challenge and compare it with how you roll back today.
Frequently asked questions
- What is GitOps?
- A way of operating infrastructure where the desired state lives in Git and an automated operator continuously reconciles the running system to match it. Changes are made through commits and pull requests, not direct commands.
- What is configuration drift?
- A difference between the live system and its declared configuration, usually caused by manual changes. GitOps operators detect it and can revert the change automatically.
- How do you roll back in GitOps?
- Revert the commit in Git, or point the application back to a known good revision. The operator then syncs the cluster to that state, and the rollback is recorded in history like any other change.
Try next
// simulator
Preview Environment Simulator
See how a pull request becomes a temporary copy of your app, complete with a private URL, safe test data, review checks, and automatic cleanup.
// game
Heroku-Style Name Generator
Generate names the way Heroku, Docker, Kubernetes, and petname do, see how the word lists combine, and learn when the birthday problem makes random names collide.
// simulator
How Docker Works Under the Hood
Watch what really happens when you run docker run -p 8080:80 nginx, one layer at a time. Step down the whole stack: the CLI, the daemon, the registry pull, containerd, the OCI runtime bundle, runc, the running container, and the shared Linux kernel. Every stage shows the real low-level command you can run yourself, so it doubles as a tour of the primitives that make a container: namespaces, cgroups, and runc. A container is not a small VM, and this shows you why.