3. Images, containers, and releases

Docker packages the environment a process needs. It solves repeatability, not hosting, scaling, monitoring, or database durability.

The three nouns

  • Dockerfile. The version-controlled recipe that describes how to build the package.
  • Image. The immutable artefact produced by the build. It contains the application, runtime, and installed dependencies.
  • Container. A running instance of the image, with the application process inside it.

One image can start many containers. Stopping a container does not erase the image, just as stopping a Python process does not erase the source code that started it. Chapter 27 turns these nouns into a real Dockerfile and a Compose stack.

The registry connects build and deployment

A release pipeline
commit
  ↓
tests
  ↓
docker build
  ↓
image tagged with a release identity
  ↓
registry
  ↓
deployment platform pulls that exact image
  ↓
new containers pass health checks
  ↓
traffic moves to the release

A registry stores images so the deployment environment does not need your laptop or your source directory. Docker Hub, GitHub Container Registry, and Amazon ECR all serve this role. Chapter 28 uses ECR because the deployment target is AWS ECS.

The release identity matters. A floating tag such as latest can point to different bytes tomorrow. A commit SHA or immutable digest lets you say exactly what was deployed and roll back to the previous artefact without rebuilding it.

Configuration arrives at runtime

The image should contain what is the same in every environment: code, runtime, system packages, and application dependencies. Configuration that changes between environments arrives when the container starts: database URLs, feature flags, service addresses, and secrets.

Environment variables are a delivery mechanism, not automatic secret protection. The production platform still needs a controlled place to store sensitive values, limit who can read them, record changes, and support rotation. Chapter 28 supplies those values to ECS without baking them into the image.

What Docker does not do

NeedDocker image alone?What completes it
Repeatable runtimeYesDockerfile and image
Public HTTPS addressNoHosting, DNS, certificate, routing
Persistent databaseNoVolume or managed database
Automatic restartNoContainer runtime or platform policy
Monitoring and alertsNoOperations tooling
Safe release automationNoCI/CD and health checks

That boundary is why "we use Docker" is not an answer to "where is the application hosted?" The image is the parcel. The registry is the depot. The deployment platform is the delivery system and destination.