docker internal

docker
2 min read

Table of Content

docker-baseAbstract

A subsystem is a module that makes use of the task grouping facilities provided by cgroups to treat groups of tasks in particular ways. A subsystem is typically a “resource controller” that schedules a resource or applies per-cgroup limits, but it may be anything that wants to act on a group of processes, e.g. a virtualization subsystem.

“docker diff” is implemented by just scanning the container filesystem and the parent image filesystem, looking at the metadata for changes. Theoretically this can be fooled if you do in-place editing of a file (not changing the size) and reset the mtime/ctime, but in practice I think this will be good enough.

“docker commit” uses the above diff command to get a list of changed files which are used to construct a tarball with files and AUFS whiteouts (for deletes). This means you can commit containers to images, run new containers based on the image, etc. You should be able to push them to the index too (although I’ve not tested this yet).

Docker looks for a “docker-pool” device-mapper device (i.e. /dev/mapper/docker-pool) when it starts up, but if none exists it automatically creates two sparse files (100GB for the data and 2GB for the metadata) and loopback mount these and sets these up as the block devices for docker-pool, with a 10GB ext4 fs as the base image.

This means that there is no need for manual setup of block devices, and that generally there should be no need to pre-allocate large amounts of space (the sparse files are small, and we things up so that discards are passed through all the way back to the sparse loopbacks, so deletes in a container should fully reclaim space.

TTY

When you allocate a TTY, the creator only gets a single input stream, and a single output stream. Meaning that when you redirect a program’s STDOUT & STDERR into the TTY, they are getting muxed together.

For example, lets use the script utility to create a TTY and look at the streams it sets up:

# script -q -c 'ls -l /dev/fd/' /dev/null
total 0
lrwx------ 1 phemmer adm 64 Jan 25 23:58 0 -> /dev/pts/16
lrwx------ 1 phemmer adm 64 Jan 25 23:58 1 -> /dev/pts/16
lrwx------ 1 phemmer adm 64 Jan 25 23:58 2 -> /dev/pts/16
lr-x------ 1 phemmer adm 64 Jan 25 23:58 3 -> /var/lib/sss/mc/passwd
lr-x------ 1 phemmer adm 64 Jan 25 23:58 4 -> /var/lib/sss/mc/group
lrwx------ 1 phemmer adm 64 Jan 25 23:58 5 -> socket:[6636438]
lr-x------ 1 phemmer adm 64 Jan 25 23:58 6 -> /proc/859/fd

Notice that FD 0, 1, & 2 all go to the TTY.

If you look at a normal terminal session, you’ll see the same thing (STDIN, STDOUT, STDERR all going to the same TTY). The reason redirection works in your terminal is because you’re performing the redirection BEFORE it gets sent into the TTY device. If you perform the redirection inside the docker container, you can accomplish the same thing.

Refer to https://github.com/docker/docker/issues/19696 for more.

TTY

Related Articles