Learning bite
Local deployment contract
Describe what a target must provide before claiming that an application can run there.
On this page
Portability starts with dependencies
A container image packages a process and its filesystem, but the process still needs a place to run and services to talk to. A target contract is a plain description of those requirements. It makes “this application can run here” a statement you can check rather than a guess based on Kubernetes compatibility.
Make the assumptions visible
MicroBank's local Kubernetes profile depends on more than a scheduler. It needs images for the node architecture, two PostgreSQL databases, messaging endpoints, credentials, DNS, storage, and a verification method. A reusable application definition can work on a new target only when that target supplies those dependencies.
Define a target contract containing cluster context, namespace, architecture, registry access, database endpoints, messaging mode, secret references, storage class, ingress decision, telemetry destination, and teardown owner. Keep credentials out of the record.
Local is a real target with limits
kind provides a disposable Kubernetes environment. The previous profile's node-local volumes do not establish cloud durability or backup. Its LocalStack services emulate selected AWS APIs; they do not create an EKS control plane, IAM security boundary, or real cloud networking.
The contract also includes exclusions: no public endpoint, no real customer data, and no scheduled synthetic tests outside the local profile. The same image can still fail on another target because of architecture, egress, identity, or filesystem differences.
Follow Ledger outside its container
Choose Ledger from the MicroBank profile you actually built. Draw arrows from it to its database, queue endpoint, image registry and secret delivery mechanism. For each arrow, ask four questions: how is the destination found, how is the caller authorized, what network path exists, and what happens when it is unavailable?
| Requirement | Local implementation to inspect | Portability question |
|---|---|---|
| Image | Locally loaded or reachable registry image | Is the target CPU architecture supported? |
| Database | The selected PostgreSQL service and volume | Who supplies a durable endpoint and tests restore? |
| Messaging | LocalStack endpoint used by the AWS SDK | Which real API or application adapter replaces it? |
| Credentials | Named local Secret dependency | Who supplies scoped credentials in the new target? |
| Verification | Saved local transaction case | Which bounded acceptance check is appropriate there? |
The contract is not an instruction to copy local credentials or local host mounts to a cloud cluster. It is a checklist of dependencies to satisfy through target-specific mechanisms.
As a guided review, open one rendered Deployment and trace each environment reference to its source. Use unknown for anything you cannot locate. A render can succeed with an unresolved runtime dependency, so valid YAML is not enough to mark the row complete.
Try it
Populate the contract from your actual local run. Mark a dependency as unknown until you have inspected it. Compare it with the rendered workload: each Secret reference and DNS name must have an owner and a target-side implementation.
Before cloud work, verify that the profile contains no local node mounts, dummy cloud keys, or scheduled probes that will be copied accidentally. Changing an environment label cannot remove an AWS SDK dependency from the application.
Checkpoint and revision
Explain which parts of the contract are portable, which require target adaptation, and which require application changes. “Runs on Kubernetes” is one compatibility claim, not a complete portability test.
Compare your reasoning
A portable workload definition is useful, but a cloud target also needs identity, network, storage and operations. Keep periodic synthetic checks and deliberate failures local as agreed. The next bite selects one target and records what must change before provisioning it.
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.