Three Modus engineers recently wrote a book about Docker and security best practices, Docker for Developers, published by Packt Publishing. Docker for Developers is perhaps the most comprehensive source of information on all things Docker and a wide range of technologies associated with Docker and deployment in the cloud. The book is oriented toward software development, deployment, and security. In this article, we’ll cover the beginnings of the book, the writing and publishing process, key learnings, and more.
Book Outline
Chapter 1: Introduction to Docker
Chapter 2: Using VirtualBox and Docker Containers for Development
Chapter 3: Sharing Containers using Docker Hub
Chapter 4: Composing Systems using Containers
Chapter 5: Alternatives for Deploying and Running Containers in Production
Chapter 6: Deploying Applications with Docker Compose
Chapter 7: Continuous Deployment with Jenkins
Chapter 8: Deploying Docker Apps to Kubernetes
Chapter 9: Cloud-Native Continuous Deployment using Spinnaker
Chapter 10: Monitoring Docker Using Prometheus, Grafana, and Jaeger.
Chapter 11: Scaling and Load Testing Docker Applications
Chapter 12: Introduction to Container Security
Chapter 13: Docker Security Fundamentals and Best Practices
Chapter 14: Advanced Docker Security – Secrets, Secret COmmands, Tagging, and Labels
Chapter 15: Scanning, Monitoring, and Using Third-Party Tools
Chapter 16: Conclusion – End of the Road, but not the Journey.
The Beginnings of the Book
In February of 2018, Modus published a blog post, also named “Docker for Developers.” It is still relevant today. The gist of the post is that you can do your development within Docker containers, install a project’s prerequisites within these containers, run and debug them on your workstation, and not have to install any particular software on your workstation except for Docker.
In a consulting company like Modus, we tend to work on a variety of projects using several different technologies. Development of these projects on a workstation without having to install multiple languages, database engines, and the like, as well as multiple versions of this software, can be problematic.
For instance, one project might use Node JS version 8 with MongoDB version 3, and another might use Node JS version 10 and MongoDB version 4. Do you uninstall one version of the software to work on one of the projects and then uninstall it and install another version of the software to work on the other? Docker to the rescue! You can build a container with Node JS version 8 and MongoDB version 3, and another with Node JS version 10 and MongoDB version 4. You can switch between the projects simply by choosing which container to run.
A content acquisition specialist from Packt Publishing found the blog post and decided to reach out to us to see if we’d be interested in writing a book about Docker. Modus immediately threw its support behind the project and assigned three of its engineers to write the book. The book was divided into 3 parts, with each author taking ownership for a particular section, and the others pitching in to help with writing content, testing, and proofreading where necessary.
Mike Schwartz took the lead on the first part, introducing Docker and demonstrating its use on the developer workstation. Richard Bullington-McGuire led the second part, introducing deployment strategies, continuous integration, Kubernetes, cloud deployment, scaling in the cloud, and monitoring it all. Finally, Andy Dennis headed up the third part, which provided an outline of Docker security.
Writing the Book
The first step in writing the book was to create an outline and to get that outline approved by Packt. The outline drove our efforts from the start. We didn’t just start writing the text, but instead, we worked on the code we wanted to present in the book. The code for all 16 chapters of the book can be found on GitHub.
Once we were satisfied with the technical deliverables, we then wrote the sections of the chapters of the book, presenting the code, why we wrote it the way we did, and how it all works. We organized the chapters with a purpose. The early chapters of each of the three parts start with simple examples, and as the chapters progress, the examples and concepts become more advanced.
For example, the first part of the book begins with a simple PHP application that increments a counter and prints the value on a web page. Each reload shows the next value of the counter. The next chapter presents a Node JS application that is a simple CRUD application using multiple containers, MQTT for inter-container communication, and multiple database back ends. The progression of topics shows how Docker and containers are technology agnostic – a PHP and a Node JS application are presented.
The second part of the book was a painstaking process of investigation of the technology to be presented, crafting code to exercise that technology, and documenting application deployment, monitoring, and scaling of a Docker application. We took screenshots of web pages for operations like setting up Amazon AWS EKS (Elastic Kubernetes Service) and deploying the application and designed the means of monitoring and load testing a demo application to demonstrate robust scaling. We created a small game called ShipIt Clicker to illustrate how to build, deploy, and extend a Docker-based application as it scales out. We cannot stress enough the detail about several important and useful technologies that are presented in this part of the book.
The third and final part of the book examines security issues and solutions when working with Docker locally and in the cloud. Security should be a first-class citizen and a high priority commitment in any deployed project. The purpose of this chapter was to show how you could take existing concepts around Dockerfiles and bake security into them through good practices. Finally, tooling available in the cloud or to install locally for scanning during development was explored to show you can bolster your security posture.
Working with Packt
We worked with a team of people at Packt, who guided us through the various stages of the development of the book. In the beginning, we had to negotiate things like the contractual terms, deadlines, and the book outline. As we wrote the book, Packt’s editors reviewed our content and were excellent at getting us to be clear in our writing and to assume nothing about the reader’s knowledge of Docker and the other technologies we presented. They kept us in line with the outline, and also encouraged us to write in a style consistent with the way Packt books are generally written.
Once the book was close to publishing, Packt provided technical reviewers who then read through our chapters, tested the code, and suggested improvements or caught any errors we made. This included a reviewer with outstanding credentials and domain expertise who did one final pass on the book, basically to bless our work.
The last stage of the writing process was to review the final PDF version this being our last chance to correct anything in our writing and to correct any errors in the transcribing process.
The book was then ready to publish!
Code In Action
In addition to writing code and text for the book, we each recorded “Code In Action” videos for each of the chapters. These are available on YouTube. The videos are silent – their sole intent is to execute the commands we present in the book to prove they work as advertised as of the time of the writing of the book and to demonstrate web content and menus where applicable.
Conclusion
The book took us around 10 months to write, with some slow down due to the COVID-19 situation. It provided each of us with the chance to not only test the skills we use every day but to also collaborate on a project that drew on all of our areas of expertise. While it took a lot of work, we all found it a rewarding experience.
