What do the processes inside a Docker container look like?

Question

I've heard confusion come up several times recently around what a Docker container is, and more specifically what's going on inside, with respect to commands & processes that I invoke while inside a Docker container.

Can someone please provide a high level overview of what's going on?

Solution 1

Docker gets thrown into the virtualization bucket, because people assume that it's somehow virtualizing the hardware underneath. This is a misnomer that permeates from the terminology that Docker makes use of, mainly the term container.

However Docker is not doing anything magical with respect to virtualizing a system's hardware. Rather it's making use of the Linux Kernel's ability to construct "fences" around key facilities, which allows for a process to interact with resources such as network, the filesystem, and permissions (among other things) to give the illusion that you're interacting with a fully functional system.

Here's an example that illustrates what's going on when we start up a Docker container and then enter it through the invocation of /bin/bash.

$ docker run -it ubuntu:latest /bin/bash
root@c0c5c54062df:/#

Now from inside this container, if we run ps -eaf:

    

Switching to another terminal tab where we're logged into the host system that's hosting the Docker container, we can see the process space that the container is "actually" taking up:

    

Now if we go back to the Docker tab and launch several processes within it and background them all, we can see that we now have several child processes running under the primary Bash process which we originally started as part of the Docker container launch.

NOTE: The processes are 4 sleep 1000 commands which are being backgrounded.

    

Notice how inside the Docker container the processes are assigned process IDs (PIDs) of 48-51. See them in the ps -eaf output in their as well:

    

However, with this next image, much of the "magic" that Docker is performing is revealed.

    

See how the 4 sleep 1000 processes are actually just child processes to our original Bash process? Also take note that our original Docker container /bin/bash is in fact a child process to the Docker daemon too.

Now if we were to wait 1000+ seconds for the original sleep 1000 commands to finish, and then run 4 more new ones, and start another Docker container up like this:

$ docker run -it ubuntu:latest /bin/bash
root@450a3ce77d32:/#

The host computer's output from ps -eaf would look like this:

    

And other Docker containers, will all just show up as processes under the Docker daemon.

So you see, Docker is really not virtualizing (in the traditional sense), it's constructing "fences" around the various Kernel resources and limiting the visibility to them for a given process + children.

Solution 2

Inside the container, your processes should be isolated (quarantined). In fact you should not see any processes but those you specify (a shell at least). It is not for "sociability" testing. The only similarity with chroot is that the host kernel is used. Docker is great if you need to isolate something or use different versions of platform architecture software than that running on the host. (very old versions of Java or a different fork of Python say). Be acutely aware that the folders and binaries you are dealing with may not be the same as those on the host. It's not the same /bin folder etc.

EDIT : similarity with chroot rather than VMs.

Comments

[mckenzm]

Edited, I was thinking with a legacy Xen cap on. Clearly that is not the case when running Windows under KVM/Qemu or running a 64 bit VM on a 32 bit host under VirtualBox. (don't ask). It is similar to the pv vs hvm argument for AWS.

[Bhargav Nanekalva]

Also docker creates an isolated userspace per running container.