Stage 10 - Production Docker
Production Docker is not about more commands. It is about predictable artifacts, observable containers, recoverable data, and repeatable deployment.
Production workflow
A production-ready image is small and explicit. It contains the runtime and application files, not compilers, test reports, source directories, package caches, or local credentials. Slim Debian images are often predictable for Java. Alpine is smaller, but musl-related compatibility issues can surprise teams.
CI build
tests and scan
push image tag
VPS pulls tag
container restarts
logs and metrics monitored
Logs, health, and deployment
Logging should go to stdout and stderr. Docker, the host, or a logging agent can collect those streams and send them to centralized storage. If the application writes only to files inside the container, logs may disappear with container replacement.
A VPS workflow should still be artifact-based. CI builds the image, runs tests, scans it, pushes an immutable tag, and the server pulls that tag. Deploying by building on the server or using latest makes rollback and investigation harder.
Image size is operational
Image size is not only a cosmetic metric. Large images take longer to pull, slow down deployment, consume more disk, and usually include more packages that can contain vulnerabilities. Smaller images are easier to move and easier to reason about.
However, smallest is not always best. Alpine can be excellent for some workloads, but Java teams sometimes prefer Debian slim because compatibility is more predictable. The correct production choice is the smallest image that is still understandable, compatible, and supportable by the team.
Multi-stage builds are the usual path: build with a full toolchain, then copy only runtime artifacts into the final image.
Observability before incidents
Production containers should be observable before something breaks. Logs should go to stdout and stderr. Metrics should be collected by the platform or an agent. Health checks should test a real readiness condition, not only whether the process exists.
A health check that only runs echo ok is almost useless. A better check calls an endpoint that confirms the application can answer requests and, when appropriate, reach critical dependencies.
Deployment is complete only when the team can see what is running, whether it is healthy, and how to roll it back.
Where production containers run
In production, containers run on servers or orchestration platforms, not on the developer laptop. A VPS is the simplest server model: you SSH into the server, install Docker there, pull images there, and start containers there.
The registry is the bridge between CI and production. CI builds the image and pushes it. The server pulls it. This avoids the unsafe pattern where a developer builds something locally and manually copies it to production.
For larger systems, Kubernetes or another orchestrator replaces manual docker run or Compose commands. The Docker concepts still matter: images are artifacts, containers are runtime processes, logs go to stdout/stderr, and persistent data must be handled deliberately.
Commands to run and inspect
Run these commands in a terminal on the machine where Docker is installed. For local learning, that is your laptop terminal. For a VPS, first connect to the server with SSH, then run the commands there. Do not paste commands blindly: run one command, inspect what changed, then run the next one.
docker build -t registry.example.com/api:${GIT_SHA} .
docker push registry.example.com/api:${GIT_SHA}
docker compose pull && docker compose up -d
docker logs -f api
Reference table
| Topic | What it means | Practical consequence |
|---|---|---|
| Slim image | Small runtime artifact | Less transfer and smaller attack surface |
| Health check | Real readiness signal | Process running is not enough |
| Immutable tag | Exact deployed version | Rollback and audit become possible |
Production readiness review
Before calling a Docker setup production-ready, verify five things: image tag is immutable, logs leave the container, health checks test real readiness, data has backup and restore procedures, and deployment does not depend on a developer laptop.
The common production mistake is treating Docker as deployment by itself. Docker packages and runs containers. A reliable production workflow still needs CI, registry, monitoring, rollback, and operational discipline.
Checkpoint
Finish the course when you can trace one change from commit to image tag, from image tag to running container, and from running container to logs, metrics, health checks, and rollback.
Practical production exercise
Trace one production release from commit to running container. Write down the commit hash, image tag, registry location, server pull command, health check, log destination, and rollback command. If one item is missing, production support will depend on memory instead of a repeatable workflow.