Docker

On Debian Stretch the docker package is described as follows:

Let that sink in. This is not the Docker you are looking for! That totally exceeds Red Hat’s Anaconda installer naming train wreck! So, do not try apt install docker. This is now a transitional package trying to rename their docker to wmdocker. But again, totally unrelated!

It looks like it’s the userland controls for some newish Linux kernel features. (Let’s not even waste too much time pondering how Windows people are running it — their reverse WINE? No idea. Don’t care.) The two notable features are cgroups and the overlay file system.

Cgroups, sometimes called Control groups, are to other Linux-managed resources what ordinary permissions groups are to file access. It seems there is a lot of fine grained control over these resources too. Old style unix file group ownership just controls who can access that file in a boolean way. Cgroups can even effectively replace other quota mechanisms (thank god). It looks like this feature can isolate and ration out CPU, memory, disk, and network. The network is probably instantaneous bandwidth and the disk is probably total bytes used because that is pragmatic. But while this is great, I’m not breathing a big sigh of relief that all desirable management controls are possible because I suspect they are not. I have had situations where I would have loved to ration out weird things like disk access bandwidth, not total bytes written. If you see some non-zero values when you look at /proc/cgroups then you’re probably using this feature. Note that on the host system, all the processes from the cgroups are visible and together in the kernel’s master process list; their PID numbers are completely different.

The other recent addition to the kernel that makes Docker possible is the overlay filesystem. Like the old aufs and unionfs, this is a union file system strategy. I am not sure what improvements exactly have been made but my guess is that this new system is much better at stacking many layers of file systems and also mounting to arbitrary points on a file system tree (not just top levels of volumes). It also can be exported over NFS. If you feel like you do not need anything but a way to manage installation cruft of dependency hogs, you might not need Docker at all; it’s possible that just sensibly using overlay mounts can suffice. Ubuntu has the overlayroot-chroot program which helps out doing the --rbind mounts for /proc/, /run/ /sys, etc, just like we used to do for Gentoo installs. Not sure about where /dev gets taken care of.

Sometimes I hear about "namespaces" being a thing. But that is kind of vague as in this official description: "Docker uses a technology called namespaces to provide the isolated workspace called the container. When you run a container, Docker creates a set of namespaces for that container." Circular definitions are definitions that are circular! Thanks, Docker! I think it just entails Docker doing things with remapping users and groups into other identities. The subuid man page is interesting. It may be a new (to me) extension of shadow-utils that allows for "subordinate user ids" i.e. a list of allowable ID remappings usually found in /etc/subuid and /etc/subgid.

I suspect a docker "container" is really just a cgroup configuration organized and set up plus an overlay filesystem over some base image’s file system plus a chroot.

Note that Docker is a privileged daemon process and anyone who can run it (any normal user who can create or run a container) can probably wreck the host system with an escalation. This is a good example and discussion of security. A process running inside the container might be able to be a bit more constrained, but be careful about such thinking.

Installation is quite unnerving for security sensitive applications. While entirely unremarkable to Windows (and Apple) users, this extremely privileged software needs you to give docker.com complete control of your system to do basically anything!

In theory there are ways to manage docker as a non-root user which may slightly help with security. But probably not since it misses the point of where I’m insinuating the attack surface really is. The real utility of adding your users to a docker group (helpfully set up by the Ubuntu package) is to spare them tedious sudo requirements. I don’t think it really contributes to meaningful security in any way. Still, it does in fact make using the tools a lot less annoying.

Once you are trusting them to do literally anything they want to your 1s and 0s, you should be able to pretend like the rest of the installation is easy! I think the "ce" here is "container engine"; we can go with that as a mnemonic anyway. Or maybe it’s "community engine" vs. the enterprisey version.

Wow. Doing docker run --help took 3.6 seconds on my system. YMMV.

Here are some systemd commands and such that can help check if things are automagically working more or less.

The official documentation clarifies important terminology: "A Docker registry stores Docker images. Docker Hub is a public registry that (in theory) anyone can use, and Docker is configured to look for images on Docker Hub by default."

To use Docker you need images. Images are like classes — a Docker container is an instance of an Docker image. Images are writeable layers stacked onto the container’s fixed layers.

The -p can map any needed ports (or they might be invisible outside the container). The -d is detach, like a background daemon. Official documentation for run command. The volume created by the middle command probably needs some kind of hook up on the run, but it’s something like that. That also shows where the volumes really live. Symlink it if you want access from a more convenient place.

How is the whole Docker show going? Here are some more diagnostics and a full test cycle.

That hex string identifier came from the "IMAGE ID" field of images sub-command.

Another fancier test.

Then you can point a browser at that machine (using http — not https!) and see a fancy web server serving a docker demo (obviously you’ll probably be able to find this on the real www but that’s not the point I guess). Unfortunately it tells you right away about how to access the "[Docker Dashboard]…for either Mac or Windows." Linux thing does not support Linux. Love it.

Another good test image that may be more useful generally.

Note here that bash is the value of the REPOSITORY field and latest is the TAG as viewed in docker images.

What exactly is Docker doing? It’s mostly faking you out into thinking you’re looking at a system when you’re only looking at some part of the system filtered by Linux namespaces. Here are some things to try both in a Docker created environment and also in the host environment. You can do this in a tmux session with two screens. Start by firing up a container.

Then look at the differences in the host session with stuff like this.

Here is the host system looking at the PID of a container’s namespace giving some hints about precisely what is isolated.

Since Docker is using cgroups there are some possibilities related to resource limiting (like classic quotas), prioritization (like classic nice), accounting (like classic pacct), control (freezing and suspending groups).

I’m kind of thankful the automagical graphical interface has no support for Linux. Not a problem.

There are two fundamentally different things that need management: images and containers. (Let’s ignore cgroup fancy jails for now — like 99% of Docker users do.) Think of an image like an old fashioned installation CD. You can’t really do much with that. If you want to change it, that’s kind of an involved PITA usually requiring a new thing. But once you get it the way you like it, you can now install that CD’s OS on as many machines as your patience allows. Each of the machines you install to will be "running that" OS and it is its own independent thing. In Docker, this is all done with overlay filesystems. There are overlay file systems for the base "install CDs" and there are more overlays for the "installations". These are images and containers respectively.

Something like this can create a container.

The -it puts you into an interactive terminal. You can then see this container on the host.

This should tip you off to the 12 character hex ID. What if you didn’t manage to connect to the container in an interactive way? Maybe the container is working and everything is set aside for it and it could be doing stuff but it maybe isn’t and you’d like to "switch to" it, whatever that means. Often it means chrooting to the top of the overlay containing this image and getting your cgroups to help you with the illusion that you’re "contained" and then running a shell. This can be done at any time with this.

Note that this also is how you can log in multiple times to the same running container. There is a similar but subtly different command called attach.

This one just hooks up your STDIO and SDTOUT to the container. If you already executed it with a bash shell, this will pick that up exactly and give you two points of control (e.g. from tmux). I got it to do that anyway. I don’t know which one it chooses if you do that with two or more bash processes running. What’s tricky is that when you want to detach I don’t know how you do that. When you exit the shell, it exits both of them and kind of nerfs the container.

There is a whole giant collection of docker container sub-commands.

A Dockerfile is a text-based script used to create a container image. Here is the Dockerfile official reference. Highlights:

Example Dockerfile:

You’ll often see MAINTAINER show up too, but it is deprecated. To achieve the same effect, use the LABEL instruction. I’m not sure if there’s an official format, but it seems pretty flexible.

An interesting one is COPY --from=<name>. This copies files from a previous FROM base-image AS <name> build. This can be used to make multi-stage builds. In case a build stage with a specified name can’t be found an image with the same name is attempted to be used instead.

Ok, you have a valid Dockerfile; now what? Now you have to "build" an "image".

It is also possible to create an image by changing files in a container and saving the modified file system as a new image. The commit command creates a new image from a container’s changes.

The penultimate argument is the current base container ID. Then the name of the new image. The change option contains Dockerfile syntax for what you’d like to be different.

When you have a Dockerfile set up (i.e. named Dockerfile and in the current directory) and ready you’ll need to build the container image with something like this.

The -t seems to be "tag" and its exact functionality can get complex but pretend this is just how you name the container in simple cases like this.

When dealing with Docker it can bring in who knows what and while it can do this somewhat efficiently, it’s easy to get all that efficiency blowing out some small root partition. The first question then is where is this in the file system. As far as I can tell, all Docker file system usage that it natively knows about is under /var/lib/docker. You can do other custom mounts to other interesting places, but if it’s intrinsic to Docker, that’s where to look for it.

Generally Docker containers seem to use some kind of fake file system that vaporizes when the container is removed. Actually there are a few possibilities.