Docker Image

A Docker image is composed of read-only layers, each representing an instruction in the Dockerfile. Layers are stacked to form the final image's filesystem. This architecture enables:

• Efficient storage: Identical layers are shared across images.
• Fast builds: Only changed layers are rebuilt.
• Immutable base: The base image layers are never modified, ensuring consistency.

An image is built from a Dockerfile, a text file with sequential commands (e.g., FROM, COPY, RUN). The build context is the set of files at the specified location (typically .) sent to the Docker daemon. Key commands include:

• FROM: Specifies the base image.
• RUN: Executes commands in a new layer.
• COPY/ADD: Add files from the build context.
• CMD: Defines the default executable for the container.

Images are stored and distributed via registries, such as Docker Hub or private registries. An image is identified by a tag, following the format [registry-hostname:port/][namespace/]repository:tag.

• The :latest tag is applied by default if none is specified.
• Tags are mutable pointers to a specific image digest (a SHA-256 hash), which is immutable.
• Pulling (docker pull) fetches an image from a registry; pushing (docker push) uploads it.

When a container is launched from an image, Docker adds a thin writable container layer on top of the image's read-only layers. This uses a Union File System (OverlayFS, aufs) with a copy-on-write (CoW) strategy.

• All file changes are written to the writable layer.
• If a file is modified, it is copied from the read-only layer to the writable layer.
• This maximizes efficiency and keeps the base image immutable.

A multi-stage build uses multiple FROM statements in a single Dockerfile to create lean final images. Each FROM instruction starts a new build stage.

• Early stages can contain build tools and compilers.
• Only the final stage's artifacts are included in the output image.
• This pattern drastically reduces image size and attack surface by excluding build dependencies.

The true, immutable identifier for an image is its content-addressable digest, a SHA-256 hash (e.g., sha256:abc123...). This ensures:

• Verifiable integrity: The digest changes if any layer content changes.
• Reproducible deployments: Pinning to a digest guarantees the exact same image is used.
• A tag is a mutable, human-friendly name that points to a digest. Using image@sha256:... is a best practice for production.

A Docker image is built from a stack of immutable, read-only layers, each representing an instruction in the Dockerfile. This architecture enables:

• Efficient storage: Identical layers are shared across images, reducing disk usage.
• Fast builds and pushes: Only changed layers are rebuilt or transferred.
• Layer caching: Unchanged intermediate build steps are reused, accelerating development cycles.

A Dockerfile is a text file containing a set of instructions used to automate the creation of a Docker image. Each instruction (e.g., FROM, RUN, COPY, CMD) creates a new layer in the final image.

Example Dockerfile:

DockerfileCopy
FROM node:18-alpine
WORKDIR /app
COPY package*.json .
RUN npm install
COPY . .
CMD ["node", "server.js"]

The docker build command executes this file to produce a runnable image.

A Docker container is a runnable instance of a Docker image. When you execute docker run, the Docker engine combines the image's read-only layers with a thin, writable container layer on top. This creates an isolated userspace process with:

• Its own filesystem, networking, and process tree.
• Resource limits defined at runtime.
• Ephemeral state; changes in the writable layer are lost when the container stops, unless persisted via volumes.

The Docker image format evolved into the Open Container Initiative (OCI) Image Format Specification, a vendor-neutral standard. This standardization enabled:

• Interoperability: Images built with Docker can be run by other OCI-compliant runtimes like containerd and Podman.
• A broader registry ecosystem: Registries like Google Container Registry (GCR), Amazon ECR, and Azure Container Registry all support the OCI format.
• Foundation for Kubernetes: The standard image format is a core component of the container orchestration ecosystem.

A Docker container is a runtime instance of a Docker image. It is a lightweight, isolated process that runs the application defined by the image. Key characteristics include:

• Isolation: Uses kernel namespaces and cgroups to isolate the container's view of the OS, network, and filesystem.
• Ephemerality: Containers are designed to be stateless and disposable; persistent data is stored in volumes or bind mounts.
• Portability: The same image runs identically on any system with the Docker Engine, ensuring consistency from development to production.

A Dockerfile is a text file containing a set of instructions used to build a Docker image. It defines the base image, application code, dependencies, and runtime configuration. Common instructions include:

• FROM: Specifies the base image (e.g., ubuntu:22.04, node:18-alpine).
• COPY / ADD: Adds files from the host into the image.
• RUN: Executes commands to install packages and configure the environment.
• CMD / ENTRYPOINT: Defines the default command to run when a container starts.

A Docker layer is an intermediate image created by each instruction in a Dockerfile. Images are built as a series of read-only layers stacked on top of each other. This architecture provides key benefits:

• Caching: Unchanged layers are cached, drastically speeding up subsequent builds.
• Efficiency: Multiple images can share common base layers, reducing storage and transfer size.
• Immutable History: Each layer is a diff of the filesystem changes from the previous layer. The final, runnable image is a thin read-write layer on top of this stack.

A multi-stage build is a Dockerfile technique that uses multiple FROM statements to create lean final images. It separates the build environment from the runtime environment.

• Build Stage: Uses a larger base image with compilers and build tools to compile the application.
• Final Stage: Uses a minimal base image (like alpine); only the compiled binaries and essential runtime files are copied from the build stage.
• Result: The final image is significantly smaller and more secure, as it excludes build tools and intermediate artifacts.