🐳 Mastering Docker Images: The Comprehensive Guide¶

The Image Concept: Blueprints for Runtime¶

A Docker image is a read-only, immutable package containing everything required to run an application: code, runtime, system libraries, environment variables, and config files.

The Build-Time vs. Run-Time Distinction¶

• Image (Build-Time): A static blueprint stored on disk.
• Container (Run-Time): A dynamic, living instance of an image.
• Relationship: You can instantiate multiple containers from a single image. Once a container is running, it is "bound" to its parent image. You cannot delete an image while containers (even stopped ones) are still referencing it.

The "No Kernel" Architecture¶

Images are remarkably small because they lack an OS Kernel.

• Containers share the Host OS Kernel (Linux or the lightweight utility VM on Windows/macOS).
• The only OS-related components in an image are Filesystem objects (bins, libs, configs).

Immutability¶

Once an image is created, it cannot be changed. Updates are made by creating a new image with a new version tag or digest.

Image Anatomy and Layering¶

Docker creates images by stacking independent, read-only layers. This "stack" is presented as a single, unified object through a Union File System (UnionFS).

• Efficiency through Sharing: If multiple images share a base layer (e.g., alpine), Docker only stores and pulls that layer once.
• Layer Composition: Every command in a Dockerfile (like RUN, COPY, ADD) creates a new layer.
• Copy-on-Write (CoW): When a container starts, Docker adds a thin Writable Layer on top of the image. Any changes made during execution are stored here, leaving the underlying image pristine.

The Storage Driver & Filesystem Abstraction¶

Docker uses storage drivers to stack these layers and present them as a unified filesystem.

• The Industry Standard: Almost all modern Docker setups use the overlay2 driver.
• Alternative Options: Depending on the host OS and requirements, Docker also supports zfs, btrfs, and vfs.
• The Abstraction Layer: Regardless of which storage driver is used (the "how"), the developer and user experience remain identical (the "what"). The driver handles the complexity of merging layers into a single file tree seamlessly.

Storage and Registries¶

The Local Repository (Image Cache)¶

• Linux: Typically found at /var/lib/docker/<storage-driver> (usually overlay2).
• Desktop: Stored within the managed Docker Desktop VM.
• Mechanics: Pulling an image checks your local cache first. Docker only downloads layers that are missing from your local repository.

Image Registries¶

Registries are centralized warehouses for images.

• OCI Compliance: Modern registries implement the OCI Distribution-Spec, ensuring interoperability across different container engines.

• Official vs. Unofficial:

  • Official: Curated and vetted by Docker and vendors (e.g., redis, nginx). They reside at the root of the Docker Hub namespace.
  • Unofficial: User-contributed. They require a prefix: username/repository.

Naming and Tagging¶

Naming Convention¶

A fully qualified image name follows this structure: [REGISTRY_HOST]/[ORG_OR_USER]/[REPOSITORY]:[TAG]

• Default Registry: docker.io (Docker Hub).
• Default Tag: latest.
• Official Repos: These live in the top-level namespace (e.g., redis, nginx, alpine) and are vetted for security.

# Pulling from a custom registry (GitHub Container Registry)
docker pull ghcr.io/username/app-name:v1.2.0

[!WARNING] The latest Tag Trap: The latest tag is just a default label. It is mutable, meaning the image it points to can change. In production, always use specific version tags or digests for reproducibility.

Image Inspection and History¶

docker image inspect¶

Provides the full JSON metadata of an image, including the RootFS (a list of all layer SHA256 hashes). Shows high-level metadata (Architecture, OS, Config, Environment variables).

docker image inspect <IMAGE_ID>

docker history¶

Shows how the image was built.

• Metadata Instructions: Commands like ENV, EXPOSE, and CMD add metadata but create 0B layers.
• Filesystem Instructions: RUN, COPY, and ADD create layers that consume disk space.

Note: In 2026, many layers in docker history appear as <missing>. This is normal; it simply means those layers were built on a different machine (e.g., the official build server) and are not individually manageable on your local host.

Immutability via Digests¶

Tags are "pointers" and can be changed. Digests are cryptographic SHA256 hashes of the image's content.

• Content-Addressable Storage: If the content of an image changes, its digest must change.
• Pulling by Digest: For maximum security (preventing "Tag Poisoning"), pull images by digest to ensure you get the exact bits you tested.

docker pull alpine@sha256:5b10f432ef3da1b8d4c7eb6c487f2f5a8f096bc91145e68878dd4a5019afde11

Distribution vs. Content Hashes¶

To save bandwidth, Docker compresses images during transport.

1. Distribution Hash: The hash of the compressed layer data (checked during pull/push) used during transport to ensure no tampering occurred.
2. Content Hash: The hash of the uncompressed layer data (used by the storage driver).

Multi-Architecture Images¶

The modern web runs on amd64 (Intel/AMD) and arm64 (Apple Silicon, AWS Graviton). Docker uses Manifest Lists to hide multiple architectures behind a single tag.

1. Manifest List (or Index): A high-level list of which architectures an image supports.
2. Manifest: The specific blueprint for a specific architecture.

The Workflow: When you docker pull, the Docker Engine checks your local CPU architecture, looks at the Registry's Manifest List, and automatically pulls the correct binary for your system.

Creating Multi-Arch Images with Buildx¶

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t username/app:v1 --push .

• Emulation (QEMU): Slow, runs target architecture in a VM.
• Build Cloud: Uses native cloud hardware; significantly faster and provides a shared cache for teams.

Security: Vulnerability Scanning¶

Docker Scout is the current industry standard for supply chain security, replacing legacy scanning tools.

• Quickview: docker scout quickview gives an instant risk assessment.
• CVES: docker scout cves provides deep analysis and remediation advice (e.g., "Upgrade base image from Python 3.11-alpine to 3.14-alpine").
• Policy Evaluation: Can block images from being pushed if they contain critical vulnerabilities.

docker scout quickview <image_name>

Maintenance and Deletion¶

Removing Images (rmi)¶

Use docker rmi to remove images by Name, ID, or Digest.

• Dangling Images: Images with no tags (result of a new build using an existing tag). Clean them using docker image prune.
• Shared Layers: Docker won't delete the actual layer files until the last image referencing them is removed.

Bulk Deletion¶

To purge all local images (use with extreme caution):

# Force delete all local images (Use with caution!)
docker rmi $(docker images -q) -f

Note: The -f (force) flag should be avoided if possible. Forcing deletion of an image in use by a container creates a "dangling" image state where the tag is removed but the data remains.

Managing the Lifecycle¶

• List Images: docker image ls (or docker images). Use --digests to see SHA hashes.
• Remove Image: docker rmi <ID_or_Name>.
  • Docker won't delete a layer if it's still being used by another image.
  • You cannot delete an image used by a running (or stopped) container.
• Cleanup: docker image prune removes "dangling" images (images with no tags). docker system prune -a is the "nuclear" option to clean all unused images.

Comments