Practical lab guide
Lab: define the MicroBank platform contract
Establish a verified entry point, supported task, and ownership handoff before adding automation.
On this page
Before collecting evidence
Work through the four product bites first. You should now be able to name the supported user task, separate resource ownership from permissions, read a runbook decision and explain a fair usability comparison. This lab brings those ideas together; it does not require inventing a platform roadmap.
Read each inventory row as a question you need to answer. For example, “authoritative manifest” means the file that should control the next change—not every historical file that happens to contain a Deployment. If your old Kubernetes and GitOps copies disagree, compare the actual changes before choosing which one to carry forward.
A draft row might say “Ledger / selected image / Argo-managed Deployment / PostgreSQL plus transaction queue / saved-case read.” Replace those descriptions with inspected values in your private working record. If you have only read the earlier labs, record the runtime checks as pending and continue only with explicitly offline work.
What you produce
You’ll produce a small Markdown service contract, an evidence inventory, and a decision about the exact application profile you will support. No cluster installation or cloud account is required for this first lab. Complete it before using the following implementation examples so you can identify any changes needed for your setup.
1. Identify the working application
From your own MicroBank checkout, record:
git status --short
git rev-parse HEAD
git diff --stat
Do not reset or discard local changes to match a tutorial. The earlier curriculum inspected source revision f75da68; its guides ask you to add files in your own checkout. A separate branch may already contain a settlement worker or altered frontend. Those additions must be reviewed and reflected in the deployment contract before proceeding.
Make a service inventory: code directory, image identity, process, port, database, queue, startup/readiness checks, and expected transaction behavior. If you use the course baseline, it has two application services, Accounts and Ledger, plus local dependencies; it does not presume a settlement worker. If you choose a worker-based branch, add that workload and its tests explicitly before using the two-service platform examples.
2. Review the Advanced DevOps handoff
Use the Kubernetes lab, GitOps lab, and canary recovery as operating references.
| Required evidence | Decision if absent |
|---|---|
| Working images with source and architecture recorded | Complete the build and local transaction baseline |
| Real saved transaction case and matching Ledger result | Run the bounded local probe; do not invent a case |
| Latest hardening/resource changes in a reviewed manifest | Reconcile changed copies before choosing a base |
| Ledger restored to a Deployment after the canary exercise | Complete recovery before this baseline handoff |
| Exactly one reconciler per workload | Resolve ownership before another Application is created |
| Local synthetic schedules suspended during handoff | Inspect and suspend only this lab's named schedule |
For an existing local cluster, inspect without changing it:
kubectl --context kind-microbank-advanced -n microbank get deployments,services
kubectl --context kind-microbank-advanced -n argocd get applications
kubectl --context kind-microbank-advanced -n microbank get cronjobs
If the Rollouts CRD is installed, also inspect Rollout objects. An unknown resource-type error is not evidence that a prior canary completed. Use the saved operating record and actual installed components. Do not inspect or change another cluster because the named local one is unavailable.
3. Write the support contract
Save platform/service-contract.md with these fields, filled from actual observations:
Supported task: propose and reconcile a reviewed local MicroBank change
Application source revision and uncommitted changes:
Supported service set and dependency versions:
Artifact identities and CPU architecture:
Authoritative workload manifest:
Cluster/context/namespace:
Owner of workloads / databases / secrets / controllers:
Local transaction evidence and its limitations:
Start / resume / stop / reset procedures:
Known gaps and excluded targets:
Escalation and recovery evidence:
Keep raw case evidence, credentials, state, and kubeconfig private. Publish a sanitized account of what you did on your personal learning site if useful. This public Markdown course is the guide; it is not a credential store or production control plane.
4. Baseline the user task
Time one manual change from request to verified outcome. Separate waiting, download/build time, review, and recovery. Record failed attempts as well as successful ones. Use this same task in the portal capstone; a changed task cannot establish a fair before/after comparison.
Acceptance and cleanup
By the end, you should be able to explain the current application profile, identify its authoritative manifest, and distinguish a passing infrastructure check from a passing transaction. Missing evidence is recorded as pending. There is nothing to destroy in this documentation exercise. Proceed to the environment lab only with a working local baseline, or perform its render-only fixture checks with that limitation recorded.
Explain your result
Why is a source commit insufficient as a handoff? The same source can have different images, local modifications and deployment configuration. Why record an unsuccessful attempt? It identifies a support problem the portal might otherwise hide. Why not copy every old manifest into the platform base? Doing so obscures which declaration should win.
Your output is a usable support record with honest gaps. The next lab uses its selected two-service workload snapshot; it does not resolve an unknown application profile for you.
Sources
Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.