Cheat notes · Module 12 · Operate and grow
Reference architecture and the road to production
A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.
The idea
Every layer on one page: Terraform from the inventory builds clusters, Argo CD and the root app; ApplicationSets add platform capabilities and translate products; every change by every team travels the same journey. That journey, not the tools, is the operating model.
Remember
- Infrastructure: Terraform from
clusters/*.yaml: clusters, Argo CD, registrations, the root app. - Platform: ApplicationSets for add-ons, guardrails, observability and the product translation.
- Products: one declaration per product; a baseline and apps per environment and cluster; promotion by pull request.
- Operations: required checks, plan comments, production approvals, deployment records, trace, logs, drills.
- One inventory is consumed by every layer: the single source of truth for which clusters exist.
- Your repo can rebuild the fleet: tear it down with
terraform destroy; nothing is lost.
Pitfalls
- Drawing the architecture only from the diagram. Sketch it from memory first (GitHub, repo, Terraform, hub, spokes, the three product ApplicationSets, the journey), then compare.
- Leaving the production checklist as a list. Open one issue per item you will do first.
Commands
git diff --stat reference/main -- . ':!products/catalog' ':!product-deployments/catalog' | How your repo differs from the reference |
cd infrastructure/kind && terraform destroy | Tear the kind fleet down |
Test yourself
Answer in your head first, then open the answer.
What is the single source of truth for which clusters exist?
clusters/*.yaml, read by Terraform and the ApplicationSets.
Which layer would you split out first as the organisation grows?
Whichever ownership boundary hurts first: products into team repos, or infrastructure into its own repo.
What makes this a GitOps operating model rather than a set of commands?
Every change by any team travels the same journey: issue, pull request, checks, approval, merge, reconcile, healthy.
Where module 12 leaves you: You have a prioritised list of production work as issues in your repo, and a clean machine. The fleet is destroyed; your repo can rebuild it.