09 · GitOps deliveryLab 48 / 59
Challengegitops
Challenge: Deploy Through Git, and Prove Drift Is Reverted
No steps. Ship a new version without touching the cluster, then show that a manual change cannot survive.
- Time
- 40 min
- Level
- Intermediate
- Objectives
- 5 objectives
- Cost
- Low cost
Where this fits in the platform
Already built
This lab adds
- A cluster that follows Git, and reverts anything applied by hand
Which lets you
—
Before you start
You will need
- The EKS cluster, ECR repository and manifests from the earlier labs
- kubectl, and write access to the repository holding the manifests
You do not need these already — the lab environment below provides them.
You will be able to
- Establish a reconciliation loop between a repository and a cluster
- Demonstrate that the cluster follows Git rather than the operator
Cost — Low cost
Assumes the EKS cluster is already running. Argo CD itself is a few Pods on nodes you are already paying for.
The objective#
Make the cluster follow the repository, and prove it.
You have an EKS cluster, manifests in 04-Kubernetes/manifests, and images in
ECR from the pipeline labs. By the end:
- A version you did not deploy by hand is running.
- A change you make by hand does not survive.
- You can point at the commit responsible for what is running right now.
No instructions. The guided version exists if you are stuck for more than twenty minutes — but try first, because the failure modes here are the lesson.
Hands-on environment
Run this lab in a real terminal, free and in your browser. The environment is temporary and yours alone — break it as much as you like.
Start the challengeOpens in Killercoda, in a new tab — keep this page open for the steps.
This is the guided lab's environment — the same machine, with its walkthrough on the left. Work from the task above and leave those steps alone until you are done, or you are reading the answers.
Run it on your own machine
Run this lab on your own machine. One command starts the environment, with everything the lab needs already installed:
Works on kind. Substitute a local image for the ECR reference.
You will need:
- docker
- kubectl
- kind
git clone https://github.com/Waleeddarwesh/EgyKode-lab.git
cd EgyKode-lab
./egykode start k8s
./egykode shellYou need Docker and Git installed. Everything else runs inside the environment. The first start downloads it and takes a few minutes; later starts are seconds.
Not sure what you already have? Run: npm run doctor — it checks and changes nothing.
Run it on AWS
This lab builds real cloud infrastructure, so it needs your own AWS account. Follow the cost and cleanup notes above — the resources are yours, and so is the bill.
Anything you tick here is your own record. EgyKode cannot see inside that terminal, so the success criteria stay self-assessed even when the environment checks your work for you.
What you must demonstrate
Step 1 of 3
What you must demonstrate#
Deployment without touching the cluster. Change a version reference in the
repository, commit, and let something else do the rest. If you ran kubectl apply, you have not done this.
Reconciliation against drift. Modify a live workload directly — the replica count is the easiest to observe — and show that the change is undone, without you undoing it. Then say what would have happened had that behaviour been switched off.
A deployment record. Produce the Git revision that corresponds to the state currently running. Not "the last commit I remember pushing" — the revision the system itself recorded when it applied it.
Three things that will probably go wrong#
Deliberately not solved for you. Each teaches something the happy path cannot.
Nothing happens at all. No error, no event, no sync. The controller is running and behaving perfectly — it simply is not looking where you think it is. Two configuration values decide that, and one of them is easy to get wrong.
It syncs, but the Pod runs the old image. The manifest is right and the cluster disagrees. Ask what actually changed in the rendered output, and whether the tag you referenced exists where the node is pulling from.
It reports Synced while the application is broken. Sync status and health
status answer different questions. Work out which one you were watching, and
which one a user would care about.
Before you finish#
Destroy what you created and verify the cascade actually removed the workloads rather than orphaning them — there is a specific piece of metadata that decides this, and finding out which one is part of the exercise.
You are done when
0 of 5
The concept behind it
Phase complete · 09 GitOps delivery
You can now: A version deploys because Git changed, and a change you make by hand does not survive.
Next phase
Lab 48 of 59 on the project path