Chapter 12. Docker in production—dealing with challenges

 

This chapter covers

  • Bypassing Docker’s namespace functionality and using the host’s resources directly
  • Making more room by resizing your storage
  • Debugging a container’s network directly, using your host’s tooling
  • Tracing system calls to determine why a container isn’t working on your host

In this chapter we’ll discuss what you can do when Docker’s abstractions aren’t working for you. These topics necessarily involve getting under the hood of Docker to understand how such solutions can be needed, and in the process we aim to provide you with a deeper awareness of what can go wrong when using Docker and how to go about fixing it.

12.1. Performance—you can’t ignore the tin

Although Docker seeks to abstract the application from the host it’s running on, one can never completely ignore the host. In order to provide its abstractions, Docker must add layers of indirection. These layers can have implications for your running system, and they sometimes need to be understood in order for operational challenges to be fixed or worked around.

In this section we’ll look at how you can bypass some of these abstractions, ending up with a Docker container that has little of Docker left in it. We’ll also show that although Docker appears to abstract away the details of the storage you use, this can sometimes come back to bite you.

Technique 97 Accessing host resources from the container

Technique 98 Device Mapper storage driver and default container size

12.2. When containers leak—debugging Docker

Technique 99 Debugging a container’s network with nsenter

Technique 100 Using tcpflow to debug in flight without reconfiguring

Technique 101 Debugging containers that fail on specific hosts

12.3. Summary