1.1.1.2 Image Package Role

The image's role within Docker is to act as the packaging format: a self-contained, immutable bundle that holds everything an application needs to run, decoupled from any particular machine or runtime environment. Where a container is the running, dynamic side of Docker, the image is the static, distributable artifact that makes that container possible in the first place.

What an Image Packages

A Docker image typically contains a minimal base operating system filesystem (such as a slimmed-down Debian or Alpine Linux), any language runtime the application needs (a JVM, a Python interpreter, a Node.js binary), the application's own code and dependencies, and metadata describing default environment variables, the working directory, exposed ports, and the command to run on startup. All of this is captured once, at build time, so that running the application later requires no additional setup.

Building the Package

An image is produced by running docker build against a Dockerfile, which defines the sequence of steps used to assemble it:

docker build -t myapp:1.0 .

Each instruction in the Dockerfile — copying files, installing dependencies, setting configuration — becomes one layer in the resulting image. This layered structure is central to the image's packaging role: layers can be shared between different images that have a common base, which avoids duplicating identical data and lets Docker download or rebuild only what has actually changed.

Versioning and Identity

Images are tagged, giving each build a human-readable version identifier, such as myapp:1.0 or myapp:latest. Internally, every image is also addressed by a content hash, so two images with identical content are recognized as the same image even if they were built independently or tagged differently. This makes the image format suitable as a unit of versioning, not just packaging — a specific image tag can be pinned in a deployment, guaranteeing exactly the same packaged contents run every time.

Distribution

Because an image is a self-contained package, it can be pushed to and pulled from a registry independently of any specific machine:

docker push myorg/myapp:1.0
docker pull myorg/myapp:1.0

This is what allows the same packaged application to move from a developer's machine, through a CI pipeline, into a staging environment, and finally into production, without being rebuilt at each stage. The image, once built, is the single artifact that travels through the whole deployment pipeline.

Separating Package from Instance

The image's packaging role only makes sense in contrast to the container's runtime role. An image is read-only and inert; nothing happens until docker run instantiates it into a container. Many containers can be created from a single image, each independent, while the underlying image package itself never changes:

docker run -d --name instance1 myapp:1.0
docker run -d --name instance2 myapp:1.0

Why This Role Is Central to Docker

The image format is arguably Docker's most consequential contribution to software delivery: it gave the industry a standard, portable answer to "how do we ship an application together with everything it needs?" That standardization, later formalized as the OCI image specification, is what allows Docker images to be built once and run anywhere a compliant container runtime exists, independent of the underlying host's installed software.