1.1.2 Delivery Role

Delivery in the context of Docker refers to the function Docker performs as the mechanism that moves an application from a developer's machine into testing, staging, and production environments in a consistent, repeatable form. Rather than shipping source code and asking each environment to assemble its own runtime, Docker packages the application together with its dependencies into an image, and that image becomes the unit that is delivered everywhere downstream.

What "Delivery" Means in a Container Workflow

A Docker image, once built, is immutable. The exact bytes that were tested in a CI pipeline are the same bytes that run in production. This removes a large class of "it worked on my machine" failures, because the delivery artifact is no longer a description of an environment (a list of dependencies, a setup script) but a fully assembled, runnable snapshot of one.

docker build -t myapp:1.4.2 .
docker push registry.example.com/myapp:1.4.2

The build step produces the artifact; the push step delivers it to a registry, which acts as the distribution point between build and deployment.

The Registry as a Delivery Hub

Container registries (Docker Hub, a private registry, or a cloud provider's registry service) are central to the delivery role. They store tagged images and make them retrievable by any host with the correct credentials and network access.

docker pull registry.example.com/myapp:1.4.2
docker run -d --name myapp -p 8080:8080 registry.example.com/myapp:1.4.2

Each environment — staging, production, a developer's laptop — pulls the same tagged image rather than rebuilding from source. This guarantees environment parity: the runtime, libraries, and configuration baked into the image do not vary between environments, only the external configuration (environment variables, mounted volumes, secrets) does.

Versioning and Rollback

Tags give the delivery process traceability. A new release is delivered as a new tag, and a previous, known-good tag remains available in the registry. If a deployment introduces a defect, rolling back is a matter of redeploying the prior tag rather than reverting code and rebuilding.

docker run -d --name myapp -p 8080:8080 registry.example.com/myapp:1.4.1

This makes the delivery process reversible at the infrastructure level, independent of source control operations.

Delivery Inside a Pipeline

In a CI/CD pipeline, Docker typically occupies the stage between "build/test" and "deploy." A pipeline builds the image, runs automated tests against a container instantiated from that image, and — if the tests pass — pushes the image to a registry and triggers deployment.

docker build -t myapp:$CI_COMMIT_SHA .
docker run --rm myapp:$CI_COMMIT_SHA pytest
docker push registry.example.com/myapp:$CI_COMMIT_SHA

Because the same image that passed the test stage is the one delivered to production, the delivery role Docker plays also functions as a guarantee: what was validated is what ships.

Delivery Across Multiple Hosts

When an application is delivered to more than one host — a cluster of servers, or nodes managed by an orchestrator such as Kubernetes or Docker Swarm — the registry allows every node to retrieve an identical image independently. The delivery problem of "copy this exact software to many machines" is reduced to "every machine can reach the registry and pull a tag."

docker service create --name myapp --replicas 5 registry.example.com/myapp:1.4.2

This is what allows horizontal scaling and rolling updates to be handled as image-pull-and-restart operations rather than manual installation steps repeated across machines.