Docker-in-Action.pdf
In 2011, I started working at Amazon.com. In that first week my life was changed as I
learned how to use their internal build, dependency modeling, and deployment tool-
ing. This was the kind of automated management I had always known was possible but
had never seen. I was coming from a team that would deploy quarterly and take 10
hours to do so. At Amazon I was watching rolling deployments push changes I had
made earlier that day to hundreds of machines spread all over the globe. If big tech
firms had an engineering advantage over the rest of the corporate landscape, this was it.
Early in 2013, I wanted to work with Graphite (a metrics collection and graphing
suite). One day I sat down to install the software and start integrating a personal proj-
ect. At this point I had several years of experience working with open source applica-
tions, but few were as dependent on such large swaths of the Python ecosystem. The
installation instructions were long and murky. Over the next several hours, I discov-
ered many undocumented installation steps. These were things that might have been
more obvious to a person with deeper Python ecosystem knowledge. After pouring
over several installation guides, reading through configuration files, and fighting an
epic battle through the deepest parts of dependency hell, I threw in the towel.
Those had been some of the least inspiring hours of my life. I wanted nothing to
do with the project. To make matters worse, I had altered my environment in a way
that was incompatible with other software that I use regularly. Reverting those changes
took an embarrassingly long time.
I distinctly remember sitting at my desk one day in May that year. I was between
tasks when I decided to check Hacker News for new ways to grow my skillset. Articles
about a technology called Docker had made the front page a few times that week.
That evening I decided to check it out. I hit the site and had the software installed
within a few minutes. I was running Ubuntu on my desktop at home, and Docker only
had two dependencies: LXC and the Linux kernel itself.
Licensed to Stephanie Bernal <nordicka.n@gmail.com>
PREFACE xiv
Like everyone else, I kicked the tires with a “Hello, World” example, but learned
little. Next I fired up Memcached. It was downloaded and running in under a minute.
Then I started WordPress, which came bundled with its own M y SQL server. I pulled a
couple different Java images, and then Python images. Then my mind flashed back to
that terrible day with Graphite. I popped over to the Docker Index (this was before
Docker Hub) and did a quick search.
The results came back, and there it was. Some random user had created a Graphite
image. I pulled it down and created a new container. It was running. A simple but fully
configured Graphite server was running on my machine. I had accomplished in less
than a minute of download time what I had failed to do with several hours a few
months earlier. Docker was able to demonstrate value with the simplest of examples
and minimum effort. I was sold.
Over the next week, I tried the patience of a close friend by struggling to direct our
conversations toward Docker and containers. I explained how package management
was nice, but enforcing file system isolation as a default solved several management
problems. I rattled on about resource efficiency and provisioning latency. I repeated
this conversation with several other colleagues and fumbled through the container
story. Everyone had the same set of tired questions, “Oh, it’s like virtualization?”
and “Why do I need this if I have virtual machines?” The more questions people
asked, the more I wanted to know. Based on the popularity of the project, this is a
story shared by many.
I began including sessions about Docker when I spoke publicly. In 2013 and 2014,
only a few people had heard of Docker, and even fewer had actually tried the software.
For the most part, the crowds consisted of a few skeptical system administrator types
and a substantial number of excited developers. People reacted in a multitude of
ways. Some were pure rejectionists who clearly preferred the status quo. Others could
see problems that they experienced daily solved in a matter of moments. Those peo-
ple reacted with an excitement similar to mine.
In the summer of 2014, an associate publisher with Manning called me to talk
about Docker. After a bit more than an hour on the phone he asked me if there was
enough content there for a book. I suggested that there was enough for a few books.
He asked me if I was interested in writing it, and I became more excited than I had
been for some time. That fall I left Amazon.com and started work on Docker in Action.
Today, I'm sitting in front of the finished manuscript. My goal in writing this book
was to create something that would help people of mixed backgrounds get up to
speed on Docker as quickly as possible, but in such a way that they understand the
underlying mechanisms. The hope is that with that knowledge, readers can under-
stand how Docker has been applied to certain problems, and how they might apply it
in their own use-cases.