Chapter 7. Debugging Containers
Once you’ve shipped an application to production, there will come a day when it’s not working as expected. It’s always nice to know ahead of time what to expect when that day comes. It’s also important to have a good understanding of debugging containers before moving on to more complex deployments. Without debugging skills, it will be difficult to see where orchestration systems have gone wrong. So let’s take a look at debugging containers.
In the end, debugging a containerized application is not all that different from debugging a normal process on a system except that the tools are somewhat different. Docker provides some pretty nice tooling to help you out! Some of these map to regular system tools, and some go further.
It is also critical to understand that your application is not running in a separate system from the other Docker processes. They share a kernel, and depending on your container configuration, they may share other things like a storage subsystem and network interfaces. This means that you can get a lot of information about what your container is doing from the system.
If you’re used to debugging applications in a VM environment, you might think you would need to enter the container to inspect an application’s memory or CPU use, or to debug its system calls. However, this is not so! Despite feeling in many ways like a virtualization layer, processes in containers are just processes on the Linux host itself. If you want to see ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access