It is easy to forget, in our age of AI and LLMs and slop and coding agents, that merely 10 years ago the “cloud” and “DevOps” and “containers” were all the rage. It seems like a century ago, yet it was not only during the 21st century, but it was almost yesterday. The sensation that time is flying is not anymore a privilege for the people above 40 years old.
Precisely at the time this magazine started annoying its readers with pleas for contributions and tongue-in-cheek commentary, containers and Kubernetes were slowly becoming the most coveted new technology in town. It is (still) quite impressive for this author, who started his career deploying applications via FTP in 1997, to see CI/CD pipelines building containers, storing them in a “registry”, and then watching an Argo CD system being triggered out of nowhere, running a Helm chart and deploying yet another version of your application in real time, automatically, several times a day.
This is the kind of revolution that containers enabled; putting applications in production was, indeed, complex and tedious. Managing them was even more complicated. Containers enabled a layer of communication and flow between developers and sysadmins that was hitherto unprecedented. Now you can mess things up faster than ever, and you can roll them back even faster.
So, back in 2018, when this magazine saw the light, containers were synonymous with the word “Docker”. For many of us in the industry, “building a Docker container” was the mot du jour, the prime directive, and the door to new opportunities.
Enter the Library entry of this month: “The Docker Book” by James Turnbull, which was for half a decade (between 2014 and 2019) the official resource to learn about the ins and outs of this new technology. The author has also written “The Terraform Book”, “The Logstash Book”, “The Packer Book” (can you see the pattern here), and “Monitoring with Prometheus” (ah, sadly not following the same name convention), and has worked for quite a few companies in the DevOps space; you are in good hands here.
The book deals with the usual container workflows: build an image, push it to a registry, pull it back, run it, get rid of it. The reason most of your projects have a file named Dockerfile (or, more recently, Containerfile) at the root of their Git repository can be traced back to this basic procedure.
At least the latest versions of the book also dealt with the following issue: what about running lots of containers at the same time? For a while, Docker Compose and later Docker Swarm appeared as suitable solutions for the conundrum. A single mechanism allowing you to run as many containers as you need–because once you run a container, you want to run thousands of them. And the new fad called “microservice architecture” screamed for monoliths to be broken down into pieces, as small as possible, stuck inside containers, and run on an orchestrator. That was the new hype at the time.
As time has shown, both projects, Docker Compose and Docker Swarm, ultimately yielded under the massive pressure of Kubernetes and the whole Cloud Native Computing Foundation landscape web page, able to take down your browser given its massive size. Do not click on the previous link unless your computer has 32 GB of RAM or more.
Kubernetes became DevOps by antonomasia:
The “container orchestration wars” are over, my general, and Kubernetes won.
And through Kubernetes, Docker containers also won.
Docker, the company and the tool, are slowly fading away into oblivion. It is quite a telling story, that of a company creating and releasing a massive standard, yet unable to stay relevant in the market just a decade later. Even Docker Hub, the first container registry ever, has been slowly left behind by individuals and organizations (and not only because of its drastic terms of service changes) in favor of other solutions, of which there is no shortage nowadays: Harbor, Sonatype Nexus, GitLab, GitHub, Quay, AWS, Azure, or even the registry bundled inside every OpenShift cluster.
Following this trend, “The Docker Book” is no longer available for purchase or download. And rightfully so. The book belongs to a time when you had to sudo your way around containers, something that was, needless to say, a heresy, and a source of white hair for quite a few security boffins.
Tools like Podman, its UI counterpart, Podman Desktop, and their terminal acolyte, Podman TUI, do not have such requirements. These new tools, fully open-source, implement the OCI standard and give you the same containers without you having to request any privilege at all. (Disclaimer: I am employed by the very company that makes Podman, but I recommend its use regardless of this fact.)
Maybe a new version of “The Docker Book” could be made, called “The Podman Book”; that is something I’ve tried to do in a much smaller scale. But let us be honest, a much better alternative in this respect would be “Podman in Action” by Daniel Walsh.
In any case, “The Docker Book” remains a highlight of a rare moment in time, when the whole of the software and IT industries tacitly endorsed the same concept simultaneously, almost unconsciously, redefining a certain idea of productivity for the decades to come.
Cover photo from the book website.