What’s up, guys — welcome, or welcome back to another log. We’re picking back up with the Docker Deep Dive series, and today we’re hitting Chapter 6. This one’s all about Docker Images: what they are, how they work, and the little gotchas that can sneak up if you’re not paying attention. So let’s break this down and really understand what’s happening under the hood.
What is a Docker Image?
The book kicks off by explaining Docker images, and honestly, it’s the perfect place to start. Think of an image as a read-only frozen snapshot that has everything your application needs to run — binaries, libraries, dependencies, and more. The only thing missing is the kernel.
When you start a container, it’s spun up from an image. Once it’s running, the container and the image are tied together. You can’t just delete the image while a container is using it — you’d need to stop and remove that container first.
Images are designed to be lean. They don’t include a full operating system, just the essentials needed for your app at runtime. That’s why you’ll hear people talk about “slim images” or “minimal base images.” The goal is always the same: keep things lightweight, secure, and fast.
The book drops a great analogy here: images are build-time constructs, while containers are run-time constructs.
Where Are Images Stored?
When you install Docker, it sets up a local image repository on your machine. Think of it as a warehouse where all the images you pull or build are stored.
Every time you run docker pull, Docker grabs the image and saves it in that local repo. By default, Docker pulls from Docker Hub, which is the main public registry.
On Docker Hub you’ll find official, verified images. They’re marked with a little green badge, which means they’ve been scanned and signed off by Docker. These images live in the top-level namespace (for example, _/nginx).
There are also community or third-party repositories. These sit in second-level namespaces (something like /r/nginx/nginx-ingress). Some of these publishers are verified, but not all. The key takeaway? Be careful when pulling images from unverified sources. Just because an image exists doesn’t mean it’s safe.
Tags, Layers & Image Pulling
Now let’s talk about tags. A tag is basically a label that points to a specific version of an image. If you run docker pull redis:latest, the word latest is the tag. If you don’t specify a tag, Docker assumes you want :latest.
On Docker Hub, you can click on the “Tags” tab for an image and see all the versions you can pull. This is super handy when you need a specific release.
Here’s where it gets interesting: Docker images aren’t just one blob — they’re made up of multiple read-only layers. Each layer represents a set of file system changes, like adding a file or installing a package. Every instruction in a Dockerfile (RUN, COPY, ADD) creates a new layer.
The cool part is Docker reuses layers across images. If you’ve already pulled a base layer before, Docker won’t download it again. That makes image pulls much faster and saves bandwidth.
Even though images are stacked layers under the hood, Docker presents them to the container as a single unified filesystem. From the container’s point of view, it feels like one solid image.
Image Digests: The Real Identity
Tags are convenient, but they can be misleading. If you pull nginx:latest today, you might get a different version tomorrow. That’s where image digests come in.
A digest is a unique hash that identifies an exact version of an image. It’s Docker’s way of guaranteeing you’re always pulling the same thing, no matter when or where.
You can see an image’s digest on Docker Hub, or by running a command like docker inspect <image-name>. This hash is Docker’s built-in integrity check — proof that nothing has been tampered with.
Multi-Architecture Images
Not every machine runs on the same CPU architecture. You’ve got amd64, arm64, and others. Normally, this would be a headache because you’d need to pull the right image for each system.
But Docker solves that with multi-architecture images. These are actually manifest lists — metadata that tells Docker which architecture-specific image to grab based on the machine you’re running.
So if you pull an image on a Raspberry Pi, Docker automatically pulls the ARM version. Pull the same image on a laptop, and it’ll grab the amd64 version. You don’t have to think about it. If you want to peek under the hood, you can inspect this metadata using:
- docker buildx imagetools inspect <image-name>
Super useful if you’re running across different devices or platforms.
Image Security
Finally, let’s talk about security — because this is a big one. Docker makes it pretty simple to check images for vulnerabilities. With Docker Scout, you can scan images for outdated packages or known CVEs.
- docker scout quickview <image-name>
That command gives you a quick snapshot of any security issues. Docker Desktop even bakes this right in, so you don’t need extra tools. If you’re building anything serious, this is one of those “no-brainer” steps. Scan your images. Fix what you can. Don’t skip it.
Wrap-Up
Docker images are the foundation of containers. They might look simple at first glance, but once you peek under the hood, you see just how much is going on — tags, layers, digests, manifests, and security checks.
Now that you’ve got a clearer picture of how they work, you’ll be able to use them more confidently and avoid some of the common mistakes.
If this breakdown helped, stick around — I’ve got more chapters and more deep dives coming up. Stay curious, stay geeking, and I’ll catch you in the next one.
