Containerize, ship & operate an app

Before you can containerize or deploy anything, you need an app that answers requests. This tiny model of a web service takes a URL path (like / or /healthz) and returns an HTTP status code plus a little JSON reply. The star of the show is /healthz — a health check the platform will ping to decide if your app is safe to send traffic to.

1. def handle(path, db_ok=True, cache_ok=True): is the function. path is which URL was requested; db_ok and cache_ok say whether the database and cache are reachable (they default to healthy).
2. if path == "/": the home route returns status 200 (HTTP for "OK") and a small status object. 200 is the code every healthy response uses.
3. The /healthz route computes healthy = db_ok and cache_ok — it's only healthy if both dependencies are up. If healthy it returns 200; if not, it returns 503 ("Service Unavailable") so the platform stops routing to it.
4. Anything unrecognized falls through to return 404 — HTTP for "not found". The loop at the bottom calls handle on three paths, then calls it once more with db_ok=False to show the degraded case.

What the output means: Each line prints the path and the (status, body) it returned. / and /healthz give 200; /missing gives 404; and the last line — with the DB down — flips to 503 and "degraded", exactly what a deploy system needs to see to hold back traffic.

Try this: Change the last call to handle("/healthz", cache_ok=False) and predict the output: it should also be 503, because health needs both checks to pass. This /healthz endpoint is what the Compose healthcheck and canary later rely on.

A real app is more than one process — here it's an API plus a Postgres database. Docker Compose lets you describe both in one YAML file and start the whole stack with a single command (docker compose up). Indentation matters in YAML: nested lines belong to the key above them.

1. services: lists the containers. api is your app: build: . means "build the image from the Dockerfile in this folder", and ports: ["8000:8000"] maps port 8000 on your machine to 8000 in the container so you can reach it in a browser.
2. depends_on: { db: { condition: service_healthy } } is the key line: the API won't start until the database reports healthy. This prevents the classic bug where the app boots faster than the DB and crashes on the first query.
3. The db service uses the official postgres:16 image and sets the user, password, and database name through environment: variables that Postgres reads on first boot.
4. volumes: ["dbdata:/var/lib/postgresql/data"] plus the bottom volumes: { dbdata: {} } give the database a named volume — disk that survives restarts, so your data isn't wiped every time the container stops.
5. The healthcheck: runs pg_isready -U app every 5 seconds (up to 5 retries). That command is what flips the DB to "healthy" and unblocks the API's depends_on.

What the output means: There's no console output here — this is configuration. Running docker compose up would start Postgres, wait until pg_isready passes, then start the API on http://localhost:8000.

Try this: Imagine deleting the depends_on block. The API could start before the DB is ready and error out. Keeping it is why one command reliably brings up the entire stack.

This is a GitHub Actions pipeline — the automation that runs every time you push code. It does what a careful engineer would do by hand, but automatically and in order: test → build → scan → push. If any step fails, the pipeline stops and nothing ships.

1. on: { push: { branches: [main] } } is the trigger: this whole file runs whenever someone pushes to the main branch.
2. The test job checks out your code, sets up Python 3.12, installs dependencies, and runs pytest -q. If tests fail, the job fails — the gate that stops broken code from going further.
3. The ship job has needs: test, meaning it only runs after tests pass. That dependency is what enforces "never deploy red code".
4. Inside ship: IMG=ghcr.io/${{ github.repository }}:${{ github.sha }} builds an image name tagged with the exact commit (github.sha). Tagging by commit means every deploy is traceable and rollback is just re-deploying an older tag.
5. docker build creates the image; the commented trivy image line is a security scan gate (fail on HIGH/CRITICAL vulnerabilities); docker push uploads it to the registry. The final echo stands in for the canary deploy step.

What the output means: No local output — this runs on GitHub's servers. Green checkmarks appear on your commit when test then ship succeed; a red X means the pipeline stopped at the failing step and nothing was deployed.

Try this: Uncomment the trivy image line in your head: now a build with a critical CVE would --exit-code 1 and fail the job, blocking the docker push. That's how a scan becomes a hard gate rather than a suggestion.

Before promoting a release to all users, professionals run two checks: a readiness gate (is this build allowed to deploy at all?) and a canary (roll out to a few users first, watch for errors, abort if it spikes). This code models both decisions in plain Python.

1. ready(tests, image_score, health, secrets_clean) collects problems into a list: tests must be green, the image scan score must be ≥70, a healthcheck must exist, and no secrets may be baked into the image. It returns (not problems), problems — True only when the problem list is empty.
2. canary(err_by_stage, threshold=0.02) walks through rollout stages like (5%, 50%, 100%). At each stage it checks the error rate err; if it exceeds the 2% threshold it returns "aborted" immediately instead of continuing.
3. If every stage stays under the threshold, the loop finishes and returns "promoted to 100%" — the release is safe for everyone.
4. The three calls at the bottom exercise it: a clean readiness check, a healthy release that passes every canary stage, and a bad release whose error rate jumps to 9% at the 50% stage.

What the output means: ready: True [] means no problems, so deploy is allowed. The healthy release prints promoted to 100%. The bad release prints aborted at 50% (err 9%) — the canary caught the spike and stopped the rollout before it hit everyone.

Try this: Lower image_score in the first call to 60 and re-read: ready now returns False with ["image score low"]. This is exactly how a pipeline blocks a risky build automatically.

This ties the entire lesson together into one function: a commit flows through the delivery pipeline stage by stage, and the outcome is either live, blocked, or rolled back. It's the mental model for everything you built above.

1. stages = ["lint","test","scan","build"] lists the ordered gates every commit must clear before it can deploy.
2. The loop uses commit.get(s, True) — it looks up each stage's result, defaulting to True (passing) if not mentioned. The first stage that is False causes return f"blocked at {s}", stopping the pipeline right there.
3. If all gates pass, the last line checks canary_ok: a passing canary returns "live (canary passed)"; a failing one returns "rolled back" — the safety net that reverses a bad release automatically.
4. The three print calls show each path: a fully passing commit, a commit whose test is False, and a commit that builds fine but fails the canary.

What the output means: Three lines: live (canary passed) (everything green), blocked at test (failing tests never reach deploy), and rolled back (deployed but the canary tripped the automatic reversal). Code → live, observable, reversible.

Try this: Add "scan": False to the first commit and predict the result — it should now print blocked at scan, because scan comes before build in the stage list and the loop stops at the first failure.