Domain 4 capstone -- from commit to running service

capstone · 100 min · Objective 4.1

Task

Bring the Automation domain together: describe infrastructure as code, apply it through a pipeline, orchestrate the result, and keep the repository as the source of truth. Every stage must be reproducible from the repo, and a bad change must be unable to reach production.

Steps

  1. Describe. Put an Ansible playbook (or OpenTofu configuration) in a git repository, structured so the whole environment is reproducible from it. Prove idempotence: a second apply changes nothing.
  2. Review as a diff. Make a change on a branch and show that the intended effect is visible as a tofu plan or ansible-playbook --check --diff before anything is applied.
  3. Pipeline. Wire lint, test, scan and deploy stages so a change failing any stage cannot deploy. Prove it with a deliberately failing change.
  4. Secrets. Show that no secret is in the repository -- a scanner blocks one, and real secrets are injected as masked variables or pulled from a store.
  5. Orchestrate. Have the deploy stage apply a Kubernetes Deployment named app and its Service, through a script deploy-from-repo.sh that runs kubectl apply -f on the manifests in the repository (the pipeline's run-pipeline.sh from the applied lab calls it as its deploy stage). Confirm the control loop maintains replicas and the Service routes by label.
  6. Reconcile. Make a manual change to the running cluster with kubectl edit or kubectl scale, then run ./deploy-from-repo.sh and show the manual change is reverted -- the repository is the source of truth. (Real GitOps runs that reconciliation continuously, with an agent in the cluster; here you run it by hand.)
  7. State. If using OpenTofu, show the state file contains secrets in plain text, is not committed, and is stored with locking.
  8. Write an evidence summary linking each property -- idempotent, reviewable, gated, orchestrated, reconciled -- to the command that proves it.

Verify

# idempotent
ansible-playbook -i inv site.yml | grep changed=0 && echo "second apply is a no-op"
# gated: failing change does not deploy
./run-pipeline.sh badtest 2>&1 | grep -qi 'deploy: ok' && echo "DEPLOYED despite failure -- fail" || echo "gate holds"
# orchestrated
kubectl get deploy app -o jsonpath='{.status.readyReplicas}'
# reconciled: manual change reverts on re-apply
kubectl scale deploy app --replicas=1; ./deploy-from-repo.sh
kubectl rollout status deploy/app --timeout=120s
kubectl get deploy app -o jsonpath='{.status.readyReplicas}'   # back to the declared count

The capstone passes when the environment is reproducible from the repo, a bad change cannot deploy, and a manual change to the cluster is reverted by re-applying the repo. That last property -- reconciliation -- is what makes the repository the source of truth rather than merely a record.

Notes

The domain's arc is that the repository stops being documentation and becomes the system: idempotence makes re-applying safe, the pipeline makes every change reviewed and gated, and reconciliation makes the running state track the repo rather than drift from it. The evidence summary is where you show the loop is closed.

This is an independent study companion for CompTIA Linux+ and is not produced by or endorsed by CompTIA.