Review of Docker Cookbook by Sebastien Goasugen

The Docker Cookbook is a good resource on learning Docker...for its time. Sebastien Goasugen choose an effective tactic of modeling real world problems--such as building your own CI/CD pipeline with Docker-- along with existent tools to make the work easier.

The prose was packed with information and concise. Concision can be a double edged sword. Many of the examples relied on references to external code listings that made the book feel a bit incomplete. That's a matter of taste and economy, especially when a book is being printed on paper.

I wouldn't say it's a major drawback, though I would prefer a bit more inline to avoid the Split Attention Effect.

A limitation of the use of contemporary, cutting edge tools is that they may not survive. Some of the specific tools mentioned and applied at the time of writing in 2016-2017 don't stand up to scrutiny in 2024. Some examples are best read as templates for the types of problems one seeks to solve with Docker and the approach one would apply (survey existent tools, determine how to dockerize them if images aren't already available) more than step-by-step recipe with minimal thinking involved

There's also the obvious complication that Docker itself has evolved a lot in 10+ years. The motivating examples of straight+forward Dockerfiles remain timeless. Much the ecosystem around them --Docker Swarm, Docker Compose, Docker/Kubernetes integration, and more--have changed significantly. Obviously we can't blame the author for this, one of the general "gotchas" with any technical writing in the 21st century is that it's a snapshot in time and the technologies are evolving rapidly. One's writing is practically out of date the moment the paragraph is written.

When we're novices in software we usually favor books over specific technology stacks designed to solve specific problems in a direct way. We thus create a very fad driven--as a former colleague of mine like to complain Cargo Cult-- culture where we try to do everything with "Web 2.0/Mobile Apps/Blockchain/AI." Most of this is driven by people who don't really know what they're doing looking for someone else to give them the easiest solution possible, the Stack Overflow Effect.

As we gain experience, we start seeking literature that gives us timeless guidance. Works like Design Patterns, Refactoring, Continuous Integration, Test Driven Development By Example, and Clean Code become paramount because they are aimed at general software engineering. Their concepts apply whether you're balls-deep in a Docker-Kubernetes Microservice gRPC paradigm or stuck in COBOL Hell in some bank somewhere.

Obviously we shouldn't completely judge books in the first bucket (Specific technology stacks solving example problems) with the same criteria as the second (philosophical/theory books that work across domains but are less specific), but there are some books that can accomplish a nice intersection, modeling more general practices whilst solving specific problems. I think Glenn Smith and Peter Ledbrook's Grails in Action remains one of the best examples I've seen of this, building a Twitter clone in Grails whilst simultaneously modeling good practice such as writing unit/integration tests and thinking about maintainability/scalability.

Problems like partitioning a multi-tier web app architecture are essentially recurrent. They represent great chosen examples, perhaps even better than "trying to build Twitter."

Although the specific examples of problem domains are strong, I found the book rather light on general guidance for how to work with Docker. Probably as a consequence of how young Docker was at the time of writing and the general state of flux of the technology stack, there wasn't a lot of emphasis on how to layer one's Docker images, how to optimize builds, or the appropriateness of Docker in different contexts (should it be used for development images, or only as a deployment mechanism?)

My own personal history with Docker was one of skepticism. I worked at Amazon while Docker was eating the world. Amazon had developed its own internal build/deploy tools (the Brazil/Apollo stack). They were basically shell scripts and rsyncs to push bits around in virtual machines. They got the job done, once you learned the lifecycle.

Since we were already in a highly virtualized, non-bare metal context, Docker's appeal as a "more native integration with Linux" (with the insinuation that it was more efficient) didn't seem as valuable. Putting Docker containers inside of VM images reminded me of Gary Bernhardt's the Death of JavaScript talk-- a cascading fractal of complexity and inefficiency that spiraled because "tool X made Y easier, tool Z made Q easier, so everything becomes a mixed conceptual mess of virtualization inside virtualization for pure pwnage." Tools like Chef, Ansible, and Vagrant already existed for setup workflows and VM management.

For many years I stayed with VirtualBox VM images for my own company--though, to my shame, I never really invested in the automation. Fighting a couple of days to set up Arch Linux, taking a snapshot as a stable base (through the VirtualBox GUI! *gulp*), and customizing for projects as necessary seemed to "work well enough."

I saw the light after working with a client making a healthcare AI system completely on his developer MacBook Pro. He had PostgresSQL installed locally, the Google Cloud SDK, and a myriad of other tools. My own setup took 1-2 weeks to get working when he went on vacation. His use case was ideal for Docker, but he wasn't interested in investing the time.

I decided to spike transforming my own dev environment and tooling into a Docker image. After working through a few dragons on getting an IDE working in the container, the whole setup felt quite nice and took less than a day.

It was more than the feeling of "that wasn't that bad" that triggered the shift. The process of declaratively enumerating my dependencies in the Docker file--surfacing some surprises such as tools that I took for granted being available like unzip and curl have to be pacman installed in an Arch image) helped me get a much clearer sense of "my stack."

Being able to build off of different layers makes absorbing and tested upstream changes easy, just cut a new version of your image, update your dependencies, and regression test.

And this is where Docker really shines. The composability and granularity that you can get really set off warm and fuzzies from a security reviewer perspective and a software engineering perspective. It helps maintainability and evolution.

This was probably all available with Vagrant had I dived into "automating my environment" in that space, but Docker makes it so obviously simple and clean that I can justify its use even in mono-Java environments, though the value exponentiallly rises in polyglot with a lot of Component-Off-The-Shelf integrations.

The cookbook serves to show general classes of problems, motivating use. It would definitely be better to keep it as a live community wiki as tools come and go and techniques evolve. I would've liked to see more on things to do and things not to do. I'm still unclear on when I should use a Docker Swarm or Kubernetes, But it achieves its purpose in demonstrating a powerful tool and driving adoption.

I'd say the most important and lasting recipes are:

1. 1.14 Building a Docker Image with a Dockerfile
2. 1.18 Sharing Data in your Docker Host with Containers
3. 1.19 Sharing Data between Containers
4. 1.20 Copying data to and from Containers
5. 2.5 Optimizing Your Dockerfile by following best practices
6. 2.11 Running a Private Registry
7. 5.1 Understanding Kubernetes Architecture
8. 5.4 Starting containers on a Kubernetes Cluster with Pods
9. 5.7 Running Multiple Containers in a Pod
10. 9.3 Listening to Docker Events in your Docker Host
11. 9.4 Getting the Logs of a Container with Docker Logs
12. 10.1 CI/CD: Setting up a Development Environment
13. 10.2 CI/CD: Building a Continuous Delivery Pipeline with Jenkins and Apache Mesos