We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Kubernetes & Containers
A lightweight, immutable package containing everything needed to run an application: code, runtime, libraries, and config. Built with a Dockerfile and stored in a registry.
In short
A container image is a read-only, layered package that bundles an application together with everything it needs to run: the code, the language runtime, system libraries, and default configuration. You build it from a Dockerfile, store it in a registry like Docker Hub or Amazon ECR, and a container runtime turns it into a running container.
In short
A container image is a read-only, layered package that bundles an application together with everything it needs to run: the code, the language runtime, system libraries, and default configuration. You build it from a Dockerfile, store it in a registry like Docker Hub or Amazon ECR, and a container runtime turns it into a running container.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Container Image across a run of lessons, not one page. These 4 alone are about 61 minutes of step-by-step reading, every one with a quiz.
Centralized storage for container images, the Docker Hub, ECR, and GHCR of the world.
Tagging, semantic versioning, and immutable deployments for container images.
Managing application and infrastructure configuration in version-controlled files instead of manual settings.
Publishing, distributing, and consuming reusable code packages across your organization and the open-source world.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Container Registrypay once,
yours for life
A container image is a frozen snapshot of a filesystem plus the metadata needed to start a process from it. Inside you will find a minimal Linux userland (or a stripped-down base like Alpine or Debian slim), your compiled binary or interpreted code, the runtime such as Node 20 or Python 3.12, the shared libraries those depend on, and a default command to run on startup.
The image is immutable. Once built and tagged, its content never changes. If you need a new version of the app, you build a new image with a new tag. This is the property that makes deployments predictable: the image that passed tests on a laptop is byte-for-byte the same image that runs in production.
An image is not a container. The image is the template on disk; a container is a running instance created from it, with its own writable layer on top. You can start a hundred containers from one image, the same way you start many processes from one executable.
Images are built from layers. Each instruction in a Dockerfile that changes the filesystem (RUN, COPY, ADD) produces a new layer, which is a tarball of the files that changed relative to the layer below it. Layers stack using a union filesystem like OverlayFS, so the running container sees one merged view.
Layers are content-addressed by their SHA256 digest. That means two images that share a base layer store and transfer that layer only once. If a base image layer is already on a node, pulling a new app image only downloads the small top layers that differ. This is why a 5 MB code change does not force a 900 MB redownload.
Tying it together is the image manifest: a JSON document listing the digests of each layer plus a config blob that holds the entrypoint, environment variables, exposed ports, and architecture. A multi-arch image uses a manifest list so the same tag (say my-app:1.4) can resolve to an amd64 image on an Intel server and an arm64 image on an Apple Silicon laptop.
All of this follows the OCI (Open Container Initiative) image spec, which is why images built with Docker run under containerd, Podman, or CRI-O without modification.
Reach for container images whenever you want the same artifact to run identically across a developer machine, CI, and production. They are the unit of deployment for Kubernetes, AWS ECS, Google Cloud Run, and almost every modern CI pipeline. They solve the classic problem of an app working in one environment and breaking in another because of a missing library or a different OS version.
The cost is image size and supply-chain risk. A careless Dockerfile that installs a full build toolchain can produce a 1.5 GB image that is slow to pull and ships dozens of vulnerable packages. The fixes are well known: use small base images, use multi-stage builds so compilers are not shipped, and scan images with tools like Trivy or Grype before pushing.
Images are also only as trustworthy as where they came from. Pull from a known registry, pin to a digest rather than a floating tag like latest in production, and sign images with cosign so a node can verify provenance before running them.
Say you have a Go web service. A multi-stage Dockerfile uses a golang:1.22 image to compile the binary, then copies just that binary into a tiny base such as gcr.io/distroless/static. The compiler, the Go module cache, and the source code never make it into the final image, so it ships at around 10 to 20 MB instead of several hundred.
You tag it as myco/api:1.4.0, push it to Amazon ECR, and Kubernetes pulls it onto worker nodes. Because the distroless base layer is already cached on those nodes from earlier deploys, only the few-megabyte binary layer transfers. Each new release is a new immutable tag, so a rollback is simply pointing the deployment back at myco/api:1.3.0, which is still sitting in the registry.
Docker Hub
The most widely used public registry; hosts official base images like nginx, postgres, and python that most other images build on top of.
Amazon Elastic Container Registry
Stores private images for AWS workloads; ECS and EKS pull from it to launch tasks and pods.
Kubernetes
Schedules containers onto nodes by pulling the image named in a Pod spec, then runs it through containerd or CRI-O.
Google Cloud Run
Takes a container image and runs it as a serverless, autoscaling service with no cluster to manage.
The image is the read-only template stored on disk or in a registry. A container is a running instance created from that image, with its own writable layer on top. One image can spawn many containers, just like one executable file can run as many processes.
A Dockerfile is the recipe: a text file of instructions like FROM, RUN, COPY, and CMD. The image is the built result of running those instructions. You edit the Dockerfile, run docker build, and get an image out.
Layers are reused and cached by their content hash. Shared base layers are downloaded and stored only once across many images, and a small code change rebuilds only the top layers. This keeps builds fast and pulls small.
Start from a small base like Alpine or distroless, use multi-stage builds so compilers and build tools are left out of the final stage, combine RUN steps to avoid extra layers, and delete package manager caches. A typical Go or Rust service can ship under 20 MB this way.
No. The latest tag is a moving target that can point at different content over time, which breaks reproducibility and rollbacks. Pin to an explicit version tag, or better, to the image digest (the SHA256), so every node runs exactly the bytes you tested.
Container Images: Most of the Size Was the Base and the Libraries, and Slimming Kept Every Score
What makes a model's container image big, and what does slimming cost? I built real Docker images of the features chapter's model: the full python:3.13 base, slim, slim with a hash lock and no pip cache, a multi-stage build, and alpine. Unpacked, they measured 1,569.1, 521.9, 460.8 and 464.2 MB; alpine did not build, because scikit-learn has no musl wheel. 77% of the full image was its base. All four images predicted the same numbers as each other, and 33 of 26,851 differed from the Mac in the last binary digit, with test AP equal to the bit.
Container Registry
Centralized storage for container images, the Docker Hub, ECR, and GHCR of the world
Image Versioning
Tagging, semantic versioning, and immutable deployments for container images
Cold Start: The First Request Waited for Python to Import Its Libraries
What does a fresh copy of a model service do before its first answer, and what does the first request pay? I started the chapter's service 80 times on a one-core EC2 box, in ten ways, with a clock reading at every step. A bare process with its files in memory answered first after 1,499 ms, and 96.9% of the time until its port opened was Python importing libraries: scikit-learn alone took 824 ms, while reading and unpickling the model took 2.0 ms. With the page cache emptied the start took 2.81 times as long. The container image, whose Python is a different build, added 539 ms (container and build not separated), and an image with a compiled standard library gave 200 ms of that back. The first request took 4,680 us against 1,849 us for the second; one warm-up request before a readiness check brought it to 1,655 us. Under 539 random arrivals a second, a warmed service and a cold one could not be told apart. As a check that every way of starting served the right model on the right rows, all 32,379 scores were equal to the bit. Every AWS step is recorded so you can build the box yourself.
Docker
A platform for packaging applications into lightweight, portable containers. 'Works on my machine' becomes 'works everywhere.'
Container
A lightweight, isolated environment that packages an application with its dependencies. Shares the host OS kernel, unlike VMs. Starts in milliseconds.
Artifact Registry
A repository for storing build outputs like Docker images, JAR files, and npm packages. Docker Hub, GitHub Container Registry, and Artifactory are common registries.
Kubernetes
An orchestration platform that automates deploying, scaling, and managing containerized applications. K8s is the operating system for your cloud.
Kubernetes Pod
The smallest deployable unit in Kubernetes: one or more containers sharing network and storage. Pods are ephemeral; if one dies, K8s creates a replacement.
Kubernetes Service
A stable network endpoint that load-balances traffic across a set of pods. Pods come and go, but the Service's IP and DNS name stay constant.
This page explains the idea. The course covers it step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
See the System Design Masterclass coursecourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Container Image in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
