Why Docker Books Still Matter in 2025

Here's the thing nobody wants to admit: most developers don't actually know Docker. They know enough Docker—enough to copy a Dockerfile from Stack Overflow, enough to type docker-compose up, enough to keep their project moving. But that's not the same thing as understanding what's happening under the hood.

Elton Stoneman gets this. The freelance consultant and former Docker employee just released the second edition of Learn Docker in a Month of Lunches, and when Manning Publishers approached him about updating it, his first thought was: "Who wants a Docker book in 2025?" (That's literally the title of his blog post about it.)

Fair question. Docker's been around for over a decade. Kubernetes has become the production standard. The technology feels ubiquitous at this point—so what's left to teach?

Turns out, basically everything.

The Gap Nobody Talks About

In a recent conversation with Docker Captain Bret Fisher, Stoneman described a pattern he sees constantly in his training work: "I've done a lot of Kubernetes courses and a prerequisite for that is some Docker knowledge and people come on and join the course and the first thing we do is talk about everyone's experience. And I always keep hearing the same story like yes, I know Docker because I joined a project. I had to learn the Docker file and the compose file and that's it. I didn't have time to stop and learn what those things really are. I just had to pick up the basics and run with it."

This is the reality of learning in production environments. You grab what you need, when you need it, and move on. No judgment—that's how projects work. But it means a lot of developers are running containerized applications without understanding multi-platform images, build optimization, security scanning, or proper configuration management.

It's like driving a car without knowing how the engine works. You can get where you're going, but when something breaks or you need to optimize performance, you're stuck.

Why Docker Still Matters When Kubernetes Gets All the Hype

Both Stoneman and Fisher came up through the old world—manually installing Windows servers, burning CDs, following deployment runbooks where one wrong click could break everything. They remember when "it works on my machine" wasn't a joke but a genuine crisis that could delay releases for days.

Docker solved something fundamental: it separated application dependencies from the host operating system. Your app gets everything it needs—the right Python version, the correct libraries, all the certificates and utilities—packaged into a portable unit that runs the same way everywhere.

"Still today, it's hard to imagine across Mac, Windows, and Linux, and especially different Linux distributions because there's different package managers for the operating systems that still today the best we've got for like a universal install and run utility is the Docker run command," Fisher points out.

This is worth sitting with. After a decade of innovation, Docker's basic approach—package everything, ship it anywhere, run it identically—remains the best solution we have. Nothing has meaningfully improved on it.

But here's where it gets interesting: Kubernetes has become such a dominant force in production environments that it drowns out the underlying Docker fundamentals. Companies market Kubernetes as the solution, conferences focus on orchestration at scale, and new developers jump straight to kubectl commands without understanding what's actually running in those pods.

Stoneman sees this gap firsthand. People show up to Kubernetes training expecting to learn container orchestration, but they're missing the foundation. They don't know how multi-platform images work, why their builds are slow, or how to scan for security vulnerabilities.

What Actually Changed in Five Years

The second edition isn't just a refresh—it reflects how the container ecosystem evolved. The biggest shift? Portability became real.

"Those core components being able to say in your application manifest, your Docker file, I need this version of Python, I'm going to install this version of this dependency and have that baked in and moving that anywhere. That's kind of been around since the beginning. But it's the the anywhere is has got more and more true," Stoneman explains.

Cloud container platforms now let you drop in any image and spin up containers instantly, paying only for the CPU you actually use. Kubernetes takes those Docker images and builds entire application models around them—portable across clouds, back on-premises, wherever you need.

The multi-platform story particularly fascinates me. Back when Docker first added ARM support, it seemed like a nice-to-have for Raspberry Pi hobbyists. Then AWS started offering ARM processors that were 60% cheaper. Then Apple switched all their machines to ARM. Suddenly that forward-thinking architecture support became crucial.

Now you can take one Dockerfile, build it for different architectures and operating systems, and ship it anywhere. Developers just type docker run and automatically get the right image for their platform—Linux ARM, Linux Intel, whatever. The complexity is handled behind the scenes by BuildKit and Docker's manifest system.

Stoneman updated every chapter to work seamlessly across Windows, Mac, Intel, and ARM. He also had to go through and remove all the hyphens—Docker Compose became docker compose (no hyphen), which sounds trivial but represents the tool's evolution from a separate utility into core Docker functionality.

The Beginner-to-Expert Journey

What separates a Docker beginner from an expert? Not the ability to run containers—that's table stakes. The gap shows up in:

Build optimization. Experts structure Dockerfiles to work with Docker's caching system, making builds fast and efficient. Beginners just stack commands and wonder why their CI/CD pipeline takes forever.

Security awareness. The Docker image format is structured and open, which means tools like Trivy can inspect your images and identify compromised dependencies. "You can say here's my application package tell me what's hackable about it and it will produce this huge list of CVEs and tell you which ones you really need to fix and which versions you have to update to fix them," Stoneman notes.

Configuration management. You want one image that runs everywhere—production, staging, development—with environment-specific configuration injected at runtime. Understanding how to properly handle secrets, environment variables, and config files separates functional containers from production-ready ones.

Multi-platform understanding. Knowing that a Docker image is actually an umbrella containing separate builds for different OS/architecture combinations, and understanding how BuildKit creates these in parallel, fundamentally changes how you think about deployment.

Claude can write you a Dockerfile. Stack Overflow has a Compose file for your use case. But neither will teach you why your images are bloated, which security vulnerabilities matter, or how to structure builds for speed.

The Month of Lunches Approach

The book's structure—one chapter per lunch hour—reflects Stoneman's training philosophy. Each chapter has some theory but focuses on practical exercises. You learn by doing, not by reading about doing.

Docker Compose gets several chapters because it serves dual purposes: it's both a development tool for running multi-container apps locally and a build tool that ensures consistency across your entire application stack. Even if you're deploying to Kubernetes in production, Compose provides a excellent on-ramp.

"Learn Dockerfile, learn Compose, and then move on to whatever you're doing in production," Stoneman says. "I think that's pretty much still the same."

It's a three-step program that acknowledges reality: most developers need to ship features, not become container experts. But those fundamentals—really understanding them—make everything else easier.

Fisher put it well: "Understanding what BuildKit is in building Docker images... understanding how those manifests connect and the layers of the Docker image connect to the manifest like there's this sort of tree structure of all these different they're technically all just files sitting on a web server in the cloud."

That level of understanding changes what's possible. It's the difference between using a tool and mastering it.

The question Stoneman posed—who wants a Docker book in 2025?—has a clear answer: everyone who's been running containers without really understanding them. Which, based on his training experience, is most people.

Docker didn't become ubiquitous because it's simple. It became ubiquitous because it solved a hard problem well enough that we stopped thinking about the problem. But that doesn't mean the complexity disappeared. It just got hidden behind convenience commands.

The fundamentals still matter. Maybe more now than ever.

—Tyler Nakamura