Deploy a container to the cloud

Before a cloud can run your image, the image has to live somewhere the cloud can download it from. These four commands build the image, give it a versioned name, log in to the registry, and upload it.

1. docker build -t myapp . builds the image from the Dockerfile in the current folder (.) and names it myapp locally.
2. docker tag myapp ghcr.io/you/myapp:1.0 gives it the full registry address: registry / your-name / image-name : version. The 1.0 is the version so you always know exactly what is running.
3. docker login proves who you are to the registry. The $TOKEN (a secret password) is piped in with --password-stdin so it never shows on screen or in your command history.
4. docker push …:1.0 uploads the image. Now the cloud can pull it by that exact name.

What the output means: Nothing dramatic prints — the image is now stored in the registry under the tag ghcr.io/you/myapp:1.0, ready for any machine to download.

Try this: Always tag a real version (or the git commit SHA), never rely on :latest. A pinned version is what makes a deploy reproducible and lets you roll back to a known-good image later.

Now you tell a managed service to run the image you just pushed. "Managed" means the cloud handles the servers, scaling, and HTTPS for you — you just describe what you want. This one command deploys the app and gives you a live URL.

1. gcloud run deploy myapp creates/updates a service called myapp on Google Cloud Run. The backslashes \ just let one command span several lines.
2. --image …:1.0 is the exact image to pull from the registry. --region picks which data center, and --port 8000 tells the service which port inside the container your app listens on.
3. --allow-unauthenticated makes the URL public (anyone can reach it). --set-env-vars ENV=prod passes a setting into the container at runtime.
4. --memory 512Mi and --max-instances 10 cap resources: how much RAM each copy gets, and the most copies it will scale up to under load.

What the output means: The service prints a Service URL like https://myapp-xxxx.a.run.app. That address is now live, with HTTPS (TLS) and autoscaling handled for you.

Try this: The same idea works on AWS App Runner/ECS and Azure Container Apps — "here's my image, port, and env; give me a scaling HTTPS endpoint." Learn the model once; only the flags differ.

Your app needs settings (like which environment it's in) and secrets (like a database password). You must never bake these into the image — instead you inject them when the container runs. This command shows the two kinds side by side.

1. --set-env-vars "ENV=prod,LOG_LEVEL=info" passes ordinary, non-secret settings as environment variables. Your app reads them with os.environ at startup.
2. --set-secrets "DATABASE_PASSWORD=db-password:latest" pulls a real secret from the cloud's secret manager and hands it to the container at runtime — the password is never stored in the image or printed in logs.
3. Both become environment variables inside the container, so your code reads a password exactly the same way it reads a plain setting — it doesn't need to know which is which.

What the output means: The service redeploys with ENV, LOG_LEVEL, and DATABASE_PASSWORD available inside the container as environment variables.

Try this: This is why the same image runs on your laptop and in prod: the code is identical, only the injected config changes. Secrets live in the secret manager, not in your source code.

The cloud platform repeatedly calls a health check endpoint to ask "are you okay?" A good one checks the things your app depends on (database, cache), not just "is the process running." If a dependency is down, you say so, and the platform stops sending traffic.

1. def health_check(deps): takes deps — a dictionary mapping each dependency name to True (ok) or False (down), e.g. {"db": True, "cache": False}.
2. all(deps.values()) is True only if every dependency is ok. If even one is False, healthy becomes False.
3. status = 200 if healthy else 503 picks the HTTP status: 200 means "all good," 503 means "service unavailable." Platforms treat 503 as a signal to reroute traffic away and restart or replace the instance.
4. It returns the status plus a small report saying "healthy" or "degraded" and which checks passed — useful when a human looks at it.

What the output means: The three prints show all-ok returning 200, then two cases where one dependency is down returning 503 with "degraded".

Try this: Add a third dependency, e.g. health_check({"db": True, "cache": True, "queue": False}), and confirm it returns 503 — any single failure fails the whole check.

A canary rollout sends the new version to a small slice of users first (5%), watches for errors, then widens (25% → 50% → 100%) only if things stay healthy. If errors spike at any stage, it stops and rolls back — so a bad release hurts only a few users, not everyone.

1. steps is the list of traffic percentages to try in order; error_rate_at(pct) is a stand-in that reports the observed error rate at each stage (in real life this comes from your monitoring).
2. The for pct in steps: loop walks each stage in turn, checking the error rate before widening traffic further.
3. if err > threshold: — if this stage's error rate exceeds the limit (0.02 = 2%), it prints ABORT, return False (stop and roll back), and never widens traffic.
4. If every stage stays under the threshold, the loop finishes and it prints promoted to 100% and return True — the new version is fully live.

What the output means: release A holds 0.5% errors the whole way and is promoted to 100%. release B is fine at 5% but jumps to 8% at 25%, so it ABORTs — exactly the point of a canary.

Try this: Change release B's spike condition to trigger at 50% instead of 25% (0.08 if p >= 50 else 0.005) and watch it get further before aborting. Fewer users hit the bad version the earlier you catch it.

Before you promote a build to production, you want an objective checklist that says yes or no — no gut calls at 2am. This function collects every reason a build should be blocked; if the list is empty, it's safe to deploy.

1. def ready_to_deploy(state): takes state, a dictionary describing the build (did tests pass? image quality score? health endpoint present? etc.).
2. blockers = [] starts an empty list. Each if checks one rule and, when it fails, appends a human-readable reason — tests not green, image score under 70, no health endpoint, secrets baked in, or an unpinned image tag.
3. return (not blockers), blockers hands back two things: True only when there are zero blockers (an empty list is falsy, so not blockers is True), plus the list of reasons so you can see why if it's blocked.

What the output means: The first call has a clean state, so it prints deploy? True. The second has a low image score and no health check, so it prints False followed by the exact list of blockers.

Try this: Flip one field to a bad value — e.g. set tests_passed=False in the first call — and watch a new reason appear in the blockers list. This is how CI decides go/no-go automatically.

An SLO (Service Level Objective) is a promise like "99.9% of requests succeed." The flip side is an error budget: the small share of failures you're allowed. This function measures how much of that budget you've spent so you know if you're still within your promise.

1. allowed = window_requests * (1 - slo_pct/100) computes how many errors are permitted. A 99.9% SLO leaves 0.1% — so over 1,000,000 requests you may have up to 1,000 errors.
2. used_pct = 100 * observed_errors / allowed is what fraction of that budget the real errors used. Over 100% means you've blown past the promise.
3. It returns that percentage plus observed_errors <= allowed — True if you're still within the SLO, False if you've burned through the budget.

What the output means: 600 errors out of 1,000 allowed = 60.0% of budget used, still within SLO (True). 1,500 errors = 150.0% — over budget, so False.

Try this: These four numbers — latency, traffic, errors, saturation — are the signals you watch on a live service. When the error budget nears 100%, that's your cue to slow down risky releases.

This ties everything together: a tiny deployer that keeps a history of versions and only promotes a new one if it's healthy. If a deploy is unhealthy, it automatically keeps the last good version live — that's rollback, done for you instead of in a panic.

1. class Deployer stores two things: revisions (a history list of every tag it tried) and live (the version currently serving traffic).
2. deploy(self, tag, healthy) always records the tag in history. If healthy is True, it sets self.live = tag and reports the new version is live.
3. If healthy is False, it does not change self.live — so the previous good version keeps serving. That is the automatic rollback.
4. The calls deploy v1.0 and v1.1 (both healthy), then v1.2 unhealthy — so it stays on v1.1.

What the output means: You see v1.0 then v1.1 go live; v1.2 is UNHEALTHY so v1.1 stays live. The last line confirms serving: v1.1 even though all three tags are in the history.

Try this: Because images are immutable and version-tagged, rolling back is just "point traffic at the previous revision." A team that makes this automatic never scrambles to hotfix under pressure.