Container Image: A Blueprint for Your Application

WHY IT EXISTS To solve the "it works on my machine" problem. Before containers, deploying software required managing complex dependencies and environment differences between development, testing, and production. Container images create a standardized, portable package that runs predictably anywhere.

THE MENTAL MODEL A container image is like a detailed recipe and all its non-perishable ingredients, vacuum-sealed for transport. The recipe is the image configuration (what command to run, what ports to open), and the ingredients are the filesystem layers (your code, libraries, base OS). A running container is the final cooked dish, created from that sealed package.

HOW IT WORKS An image is composed of several key parts defined by the Open Container Initiative (OCI) spec. An image manifest lists all contents and their unique, content-addressed identifiers. This points to a stack of read-only filesystem layers. Each layer represents a change, like adding a file or installing a package. When you run the image, these layers are stacked, and a final writable layer is added on top for the running container. A configuration file specifies runtime details like environment variables, the default command to execute, and network ports. An optional image index can point to multiple manifests to support different CPU architectures (like amd64 and arm64) with the same image name.

WHEN TO USE IT Use container images as the fundamental artifact for shipping and deploying applications. They are essential for using tools like Docker and Podman, and for deploying to container orchestrators like Kubernetes or Nomad. They are the standard unit of deployment in modern CI/CD pipelines.

WHEN NOT TO USE IT Images are not for stateful data that needs to persist. While you can write data inside a container, it's lost when the container is removed. For databases, file uploads, or logs that must survive restarts, use external volumes or managed cloud services instead of storing data in the image or the container's writable layer.

ONE CANONICAL EXAMPLE A Dockerfile defines the steps to create an image. FROM ubuntu:22.04 starts a new layer based on Ubuntu. COPY ./app /app adds another layer with your application code. CMD ["/app/start"] sets the default command in the configuration. Running docker build executes these steps, creating a new, portable image with a unique ID, ready to be run as a container anywhere.