Drilling Holes Into Containers

Container management software is often deployed in containers itself. But how can code running inside a container look at other containers? Let's have a look how components like cAdvisor and datadog agents can gather that sort of data.


In First Steps with Docker, we have already seen the -v switch in docker run that allows mounting files or directories from the host into the container. This is can be used for exchanging data between host and container, but it can also allow for more insight into the host. Mounting of the following paths is often used:

• /var/lib/docker. A lot of information is stored in that directory, allowing management software to create its notion of the container landscape on the host
• /sys contains a lot of cgroup information which controls resource limits
• /var/run/docker.sock is a Unix domain socket providing a REST API to docker. In our case, the socket can be passed on into the container, providing all information available through the Docker remote API. Using this interface avoids to have a lot of internal knowledge how the information in /var/lib/docker is structured. Note this API could also be made available through TCP/IP.

When trying this out, simply get a container and add -v statements when starting, e.g.

docker run -t -i -v /var/run/docker.sock:/var/run/docker.sock bash

Then API commands can be used, e.g.

echo -e "GET /images/json HTTP/1.1\n" | netcat -U /var/run/docker.sock

A more extreme way of exporting system data is to mount the host's /proc file system somewhere into the container's file system (mounting over the container's original /proc directory will collide with apparmor, so a different mount point is the way out).
I didn't see any software yet going after that interface, but it provides information about all host processes in the container context -- and should probably be described as carving walls out of containers, rather than drilling holes into them...