Whether you are new to Docker or a veteran DevOps engineer, there is always room to learn more about the container management platform.
Vincent Sesto, a DevOps engineer at Westpac New Zealand, explores the concepts and tools needed to successfully implement the popular container format in this collaboratively written book, The Docker Workshop, from Packt Publishing. Through the book, IT professionals learn how Docker's runtime environment is used to construct and run containers.
In this Q&A, Sesto discusses the architecture, technical benefits and common challenges behind the popular container technology.
Editor's note: This following interview has been edited for length and clarity.
What are the biggest challenges for IT administrators trying to learn more about Docker, and how does this book help them overcome them?
Vincent Sesto: Containers are different from VMs and should not be treated as if they are the same. In many cases, if an IT admin is moving a service from a server to a container, the service may need to be rearchitected before it can be implemented as a container. The challenge is that this takes time, and a lot of service owners or senior managers may not understand why. This book gives an IT admin the knowledge to help them rearchitect their service, as well as explain to senior managers why extra time is needed to implement a change like this.
Are there any misunderstandings that you've noticed with people getting started with Docker, and how would you advise them to avoid such mistakes?
Sesto: A lot of people assume Docker is secure by default, and [that] security can be an afterthought. If you start implementing good security habits from day one, it will help you in the long run.
Keep your containers as small as possible; limit the packages and functionality you [install]. Keep your containers regularly updated and scan them for vulnerabilities. And never deploy containers running with the root user.
What is the current status of the container security landscape?
Sesto: It is getting better, especially when using tools like AWS or Microsoft Azure for your image repositories. They have built-in scanning for image repositories, which is nice. A lot of companies still use their own image repositories, and they forget the actual step of scanning and making sure their images don't have any security issues.
For the company that I'm currently working for, it's tightly controlled. You're not allowed to have a root user on your container before it goes into Kubernetes; everything must be scanned. There are security teams who check all the base images that we use, and they have to be verified before we can use them.
With Docker being such a popular tool for developers to use, is there a particular interactive element that you enjoyed writing about?
Sesto: System resource usage and the metrics behind that. Docker gives you a good insight [about] how your applications use resources, such as memory and CPU. Those topics are a bit more advanced, but they are important to grasp. It helps you put something like larger computer systems into perspective, and how applications use memory and CPU in larger systems as well.
That's something great about Docker: It's just this small container where you can see your system, but you can also do a lot of experimentation. You can push a lot of resources and tests … into your application [or] service and get a clear understanding of how those requests then affect CPU usage [and] RAM, [for example].
Experience with collecting metrics and logs -- especially if you're working in that platform engineers' or DevOps engineers' space -- is sought after. It's something that I've been doing for a long time and I kind of take it for granted.
What was your favorite topic to write about in this book?
Sesto: [Docker Swarm] was one of the main orchestration tools when Docker first came out. I'd never worked with Swarm before, but it was surprising how useful it is.
It will be interesting to see how businesses move in the future with it. With increased functionality being added to Swarm and the support still being there, maybe some people will still take it up. But for me, it was a great learning experience to write the chapter because I had never really touched it before.
Were there any ideas or concepts that you initially included but removed during the editing process?
Sesto: For things we decided to leave out, there's the orchestration tool Portainer that went away a little bit. It could become more popular again soon, but, at the moment, [things] like that were taken out. Whereas we needed to make sure that we had a lot of information on something like Kubernetes, since it's one of the main drivers of Docker these days with so many people setting up Kubernetes clusters and environments.
To learn more about Docker and Docker Swarm, read this full chapter excerpt from The Docker Workshop.