Docker

Docker Compose is an alternate CLI frontend for the Docker Engine, which specifies properties of containers using a YAML file rather than, for example, a script with options. This is useful for setting up reoccuring services that are use often and/or have complex configurations. To use it, install .

Docker Desktop is a proprietary desktop application that runs the Docker Engine inside a Linux virtual machine. Additional features such as a Kubernetes cluster and a vulnerability scanner are included. This application is useful for software development teams who develop Docker containers using macOS and Windows. The Linux port of the application is relatively new, and complements Docker's CLI frontends . An experimental package for Arch is provided directly by Docker; see the manual for more information. Unfortunately it contains files which conflict with the package so you will first need to remove if installed.

Also, to run Docker Desktop you will need to ensure the Linux system requirements, including virtualization support via KVM. To see a tray icon under Gnome, will be needed.

Finally, file sharing support requires mapping user and group ids via /etc/subuid and . See the Docker Desktop For Linux File Sharing instructions for more details.

The storage driver controls how images and containers are stored and managed on your Docker host. The default driver has good performance and is a good choice for all modern Linux kernels and filesystems. There are a few legacy drivers such as and which were intended for compatibility with older Linux kernels, but these have no advantages over on Arch Linux.

Users of btrfs or ZFS may use the or drivers, each of which take advantage of the unique features of these filesystems. See the btrfs driver and zfs driver documentation for more information and step-by-step instructions.

By default, the Docker daemon serves the Docker API using a Unix socket at /var/run/docker.sock. This is an appropriate option for most use cases.

It is possible to configure the Daemon to additionally listen on a TCP socket, which can allow remote Docker API access from other computers. This can be useful for allowing docker commands on a host machine to access the Docker daemon on a Linux virtual machine, such as an Arch virtual machine on a Windows or macOS system.

Note that the default docker.service file sets the flag by default, and Docker will not start if an option is present in both the flags and /etc/docker/daemon.json file. Therefore, the simplest way to change the socket settings is with a drop-in file, such as the following which adds a TCP socket on port 2376:

Reload the systemd daemon and restart docker.service to apply changes.

There are two parts to configuring Docker to use an HTTP proxy: Configuring the Docker daemon and configuring Docker containers.

See Docker documentation on configuring a systemd drop-in unit to configure HTTP proxies.

See Docker documentation on configuring proxies for information on how to automatically configure proxies for all containers created using the docker CLI.

See Docker's DNS documentation for the documented behavior of DNS within Docker containers and information on customizing DNS configuration. In most cases, the resolvers configured on the host are also configured in the container.

Most DNS resolvers hosted on are not supported due to conflicts between the container and host network namespaces. Such resolvers are removed from the container's /etc/resolv.conf. If this would result in an empty , Google DNS is used instead.

Additionally, a special case is handled if is the only configured nameserver. In this case, Docker assumes the resolver is systemd-resolved and uses the upstream DNS resolvers from .

If you are using a service such as dnsmasq to provide a local resolver, consider adding a virtual interface with a link local IP address in the block for dnsmasq to bind to instead of to avoid the network namespace conflict.

By default, docker images are located at /var/lib/docker. They can be moved to other partitions, e.g. if you wish to use a dedicated partition or disk for your images. In this example, we will move the images to .

First, stop docker.service, which will also stop all currently running containers and unmount any running images. You may then move the images from /var/lib/docker to the target destination, e.g. cp -r /var/lib/docker /mnt/docker.

Configure in /etc/docker/daemon.json:

Restart docker.service to apply changes.

If you decide to use a self signed certificate for your private registries, Docker will refuse to use it until you declare that you trust it. For example, to allow images from a registry hosted at , configure in the /etc/docker/daemon.json file:

Restart docker.service to apply changes.

In order to enable IPv6 support in Docker, you will need to do a few things. See and for details.

Firstly, enable the setting in /etc/docker/daemon.json and set a specific IPv6 subnet. In this case, we will use the private subnet. Make sure to use a subnet at least 80 bits as this allows a container's IPv6 to end with the container's MAC address which allows you to mitigate NDP neighbor cache invalidation issues.

Restart docker.service to apply changes.

Finally, to let containers access the host network, you need to resolve routing issues arising from the usage of a private IPv6 subnet. Add the IPv6 NAT in order to actually get some traffic:

# ip6tables -t nat -A POSTROUTING -s fd00::/80 ! -o docker0 -j MASQUERADE

Now Docker should be properly IPv6 enabled. To test it, you can run:

# docker run curlimages/curl curl -v -6 archlinux.org

If you use firewalld, you can add the rule like this:

# firewall-cmd --zone=public --add-rich-rule='rule family="ipv6" destination not address="fd00::1/80" source address="fd00::/80" masquerade'

If you use ufw, you need to first enable ipv6 forwarding following Uncomplicated Firewall#Forward policy. Next you need to edit /etc/default/ufw and uncomment the following lines

Then you can add the iptables rule:

# ip6tables -t nat -A POSTROUTING -s fd00::/80 ! -o docker0 -j MASQUERADE

It should be noted that, for docker containers created with docker-compose, you may need to set enable_ipv6: true in the part for the corresponding network. Besides, you may need to configure the IPv6 subnet. See for details.

By default, processes in Docker containers run within the same user namespace as the main daemon, i.e. containers are not isolated by the feature. This allows the process within the container to access configured resources on the host according to Users and groups#Permissions and ownership. This maximizes compatibility, but poses a security risk if a container privilege escalation or breakout vulnerability is discovered that allows the container to access unintended resources on the host. (One such vulnerability was published and patched in February 2019.)

The impact of such a vulnerability can be reduced by enabling user namespace isolation. This runs each container in a separate user namespace and maps the UIDs and GIDs inside that user namespace to a different (typically unprivileged) UID/GID range on the host.

Configure in /etc/docker/daemon.json. is a special value that will automatically create a user and group named for use with remapping.

/etc/docker/daemon.json

{
  "userns-remap": "default"
}

Configure /etc/subuid and with a username/group name, starting UID/GID and UID/GID range size to allocate to the remap user and group. This example allocates a range of 65536 UIDs and GIDs starting at 165536 to the user and group.

/etc/subgid

dockremap:165536:65536

Restart docker.service to apply changes.

After applying this change, all containers will run in an isolated user namespace by default. The remapping may be partially disabled on specific containers passing the flag to the docker command. See for details.

To run the Docker daemon itself as a regular user, install the package.

Configure /etc/subuid and with a username/group name, starting UID/GID and UID/GID range size to allocate to the remap user and group.

Enable the user unit: this will result in docker being started using systemd's socket activation.

Finally set docker socket environment variable:

$ export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock

By default, Docker cannot use the native overlay diff engine on Arch Linux, which makes building Docker images slow. If you frequently build images, configure the native diff engine as described in :

Then stop docker.service, reload the overlay module as follows:

# modprobe -r overlay
# modprobe overlay

You can then start docker.service again.

To verify, run docker info and check that is .

The following command pulls the archlinux x86_64 image. This is a stripped down version of Arch core without network, etc.

# docker pull archlinux

See also README.md.

For a full Arch base, clone the repository from above and build your own image.

$ git clone https://gitlab.archlinux.org/archlinux/archlinux-docker.git

Make sure that the , and packages are installed.

To build the base image:

$ make image-base

Alpine Linux is a popular choice for small container images, especially for software compiled as static binaries. The following command pulls the latest Alpine Linux image:

# docker pull alpine

Alpine Linux uses the musl libc implementation instead of the glibc libc implementation used by most Linux distributions. Because Arch Linux uses glibc, there are a number of functional differences between an Arch Linux host and an Alpine Linux container that can impact the performance and correctness of software. A list of these differences is documented here.

Note that dynamically linked software built on Arch Linux (or any other system using glibc) may have bugs and performance problems when run on Alpine Linux (or any other system using a different libc). See , and for examples.

The following command pulls the latest centos image:

# docker pull centos

See the Docker Hub page for a full list of available tags for each CentOS release.

The following command pulls the latest debian image:

# docker pull debian

See the Docker Hub page for a full list of available tags, including both standard and slim versions for each Debian release.

Google maintains distroless images which are minimal images without OS components such as package managers or shells, resulting in very small images for packaging software.

See the GitHub README for a list of images and instructions on their use with various programming languages.

Starting from Docker version 19.03, NVIDIA GPUs are natively supported as Docker devices. NVIDIA Container Toolkit is the recommended way of running containers that leverage NVIDIA GPUs.

Install the package. Next, restart docker. You can now run containers that make use of NVIDIA GPUs using the option:

# docker run --gpus all nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

Specify how many GPUs are enabled inside a container:

# docker run --gpus 2 nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

Specify which GPUs to use:

# docker run --gpus '"device=1,2"' nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

or

# docker run --gpus '"device=UUID-ABCDEF,1"' nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

Specify a capability (graphics, compute, ...) for the container (though this is rarely if ever used this way):

# docker run --gpus all,capabilities=utility nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

For more information see README.md and Wiki.

Install the package. Next, register the NVIDIA runtime by editing /etc/docker/daemon.json

/etc/docker/daemon.json

{
  "runtimes": {
    "nvidia": {
      "path": "/usr/bin/nvidia-container-runtime",
      "runtimeArgs": []
    }
  }
}

and then restart docker.

The runtime can also be registered via a command line option to dockerd:

# /usr/bin/dockerd --add-runtime=nvidia=/usr/bin/nvidia-container-runtime

Afterwards GPU accelerated containers can be started with

# docker run --runtime=nvidia nvidia/cuda:9.0-base nvidia-smi

or (required Docker version 19.03 or higher)

# docker run --gpus all nvidia/cuda:9.0-base nvidia-smi

See also README.md.

nvidia-docker is a wrapper around NVIDIA Container Runtime which registers the NVIDIA runtime by default and provides the nvidia-docker command.

To use nvidia-docker, install the package and then restart docker. Containers with NVIDIA GPU support can then be run using any of the following methods:

# docker run --runtime=nvidia nvidia/cuda:9.0-base nvidia-smi

# nvidia-docker run nvidia/cuda:9.0-base nvidia-smi

or (required Docker version 19.03 or higher)

# docker run --gpus all nvidia/cuda:9.0-base nvidia-smi

You can use the following Dockerfile to build a custom Arch Linux image with CUDA. It uses the Dockerfile frontend syntax 1.2 to cache pacman packages on the host. The environment variable must be set on the client before building the Docker image.

Docker attempts to enable IP forwarding globally, but by default systemd-networkd overrides the global sysctl setting for each defined network profile. Set in the network profile. See Internet sharing#Enable packet forwarding for details.

When systemd-networkd tries to manage the network interfaces created by Docker, e.g. when you configured in the Match section, this can lead to connectivity issues. Try disabling management of those interfaces. I.e. networkctl list should report in the SETUP column for all networks created by Docker.

If you run into error messages like

# e.g. Java
java.lang.OutOfMemoryError: unable to create new native thread
# e.g. C, bash, ...
fork failed: Resource temporarily unavailable

then you might need to adjust the number of processes allowed by systemd. The default is 500 (see ), which is pretty small for running several docker containers. Edit the docker.service with the following snippet:

[Service]
TasksMax=infinity

If systemctl fails to start docker and provides an error:

Error starting daemon: error initializing graphdriver: devmapper: Device docker-8:2-915035-pool is not a thin pool

Then, try the following steps to resolve the error. Stop the service, back up (if desired), remove the contents of , and try to start the service. See the open GitHub issue for details.

If you are getting an error message like this:

ERROR: Failed to create some/path/to/file: No space left on device

when building or running a Docker image, even though you do have enough disk space available, make sure:

• Tmpfs is disabled or has enough memory allocation. Docker might be trying to write files into but fails due to restrictions in memory usage and not disk space.
• If you are using XFS, you might want to remove the noquota mount option from the relevant entries in (usually where and/or /var/lib/docker reside). Refer to Disk quota for more information, especially if you plan on using and resizing Docker storage driver.
• XFS quota mount options (, , prjquota, etc.) fail during re-mount of the file system. To enable quota for root file system, the mount option must be passed to initramfs as a kernel parameter rootflags=. Subsequently, it should not be listed among mount options in for the root () filesystem.

In case docker-machine fails to create the VM's using the virtualbox driver, with the following:

VBoxManage: error: VBoxNetAdpCtl: Error while adding new interface: failed to open /dev/vboxnetctl: No such file or directory

Simply reload the virtualbox via CLI with .

The issue is that Docker's scripts add some iptables rules to block forwarding on other interfaces other than its own. This is a known issue.

Adjust the solutions below to replace br0 with your own bridge name.

Quickest fix (but turns off all Docker's iptables self-added adjustments, which you may not want):

/etc/docker/daemon.json

{
  "iptables": false
}

If there is already a network bridge configured for KVM, this may be fixable by telling docker about it. See where docker configuration is modified as:

If the above does not work, or you prefer to solve the issue through iptables directly, or through a manager like UFW, add this:

Even more detailed solutions are here.

Beginning on November 1st 2020, rate limiting is enabled for downloads from Docker Hub from anonymous and free accounts. See the rate limit documentation for more information.

Unauthenticated rate limits are tracked by source IP. Authenticated rate limits are tracked by account.

If you need to exceed the rate limits, you can either sign up for a paid plan or mirror the images you need to a different image registry. You can host your own registry or use a cloud hosted registry such as Amazon ECR, Google Container Registry, Azure Container Registry or Quay Container Registry.

To mirror an image, use the , and push subcommands of the Docker CLI. For example, to mirror the tag of the Nginx image to a registry hosted at cr.example.com:

$ docker pull nginx:1.19.3
$ docker tag nginx:1.19.3 cr.example.com/nginx:1.19.3
$ docker push cr.example.com/nginx:1.19.3

You can then pull or run the image from the mirror:

$ docker pull cr.example.com/nginx:1.19.3
$ docker run cr.example.com/nginx:1.19.3

If you see this error when running a container, install instead of (legacy) and reboot.