The Canonical Docker Snap: Architecture, Installation, and the Boundaries of Containerized Snap Management

The intersection of containerization technologies and package management systems represents a complex layer of system administration in modern Linux environments. The Docker snap, maintained by Canonical, serves as a critical bridge for users who rely on the snap ecosystem but require the robust container orchestration capabilities of Docker Engine. This package is not merely a binary wrapper; it is a carefully engineered distribution of Docker Engine, complete with the NVIDIA toolkit, specifically tailored for Ubuntu Core and other snap-compatible systems. Understanding the intricacies of this package requires a deep dive into its architectural constraints, its confinement model, the specific interfaces it demands, and the distinct philosophical and technical differences between running Docker inside a snap versus running snap inside Docker. The following analysis exhaustively covers the installation, configuration, development, and operational nuances of the Docker snap, providing a comprehensive resource for system administrators, developers, and enthusiasts navigating this specific technological niche.

Architectural Foundation and Distribution Model

The Docker snap package is sourced from a dedicated repository that houses the build scripts and configuration necessary to compile Docker Engine into the snap format. This is not an official build from Docker, Inc., but rather a derivative work created by Canonical. The underlying Docker Engine is built from an upstream release tag. However, this is not a verbatim copy of the upstream binary. Canonical applies specific patches to the source code to ensure compatibility with the snap format. These patches are essential because the snap confinement model imposes strict boundaries on file system access, network permissions, and process execution that standard Docker installations do not encounter.

The scope of hardware support for the Docker snap is extensive, reflecting Canonical's commitment to broad hardware compatibility across the Linux ecosystem. The package is available for multiple architectures, ensuring that users on diverse hardware platforms can utilize Docker within the snap ecosystem. These architectures include armhf, which targets 32-bit ARM processors often found in older embedded devices and single-board computers. It also supports arm64, the 64-bit ARM architecture that is dominant in modern mobile devices and increasingly prevalent in server environments and cloud infrastructure. For traditional x86_64 systems, the amd64 architecture is supported, alongside the legacy i386 architecture, ensuring backward compatibility for older 32-bit x86 systems. Furthermore, the package extends its reach to powerpc64el, which is crucial for IBM Power systems, riscv64, supporting the emerging RISC-V open instruction set architecture, and s390x, which covers IBM Z mainframe environments. This multi-architecture support is a significant feature, as it allows the Docker snap to be deployed in highly specialized industrial, enterprise, and embedded contexts where standard Docker installation methods might be incompatible with the system's package management policies or security models.

The inclusion of the NVIDIA toolkit within the snap is a notable feature. It allows users to leverage GPU acceleration within their containers without needing to install additional drivers or configuration tools outside of the snap. This integration streamlines the setup for machine learning workloads, scientific computing, and graphics-intensive applications that rely on CUDA. The NVIDIA support is not enabled by default in all configurations but can be toggled via snap configuration settings, providing flexibility for users who do not require GPU access and those who do.

Installation and Initial Configuration

The installation of the Docker snap is straightforward for users who have snapd installed and functioning correctly on their system. The primary command to install the latest stable release of Docker Community Edition (CE) using snap is a single line. This command instructs the snap daemon to fetch the package from the Snap Store and install it with the default options.

sudo snap install docker

Upon execution of this command, the snap daemon performs several critical steps. It downloads the compressed squashfs file containing the Docker binaries and dependencies. It then mounts this file system in a read-only manner and sets up the necessary mount namespaces. Crucially, the installation process involves connecting specific interfaces. Because the Docker snap is confined, it cannot access system resources freely. It must request and be granted access through snap interfaces. The confinement model is a security feature designed to prevent applications from accessing sensitive parts of the system without explicit permission.

During the initial installation, the snap connects automatically to a specific set of system interface slots. These interfaces are vital for the proper functioning of Docker Engine. The docker-support interface is required to allow the snap to interact with the Docker daemon's specific system requirements. The firewall-control interface grants the snap the ability to manipulate iptables rules, which is essential for Docker's networking functionality, such as setting up bridge networks and managing port forwarding. The home interface is connected automatically only on classic or traditional distributions. This interface allows the snap to access the user's home directory, enabling the storage of Docker-related files and configurations in a location familiar to the user. The network interface provides basic network connectivity. The network-bind interface allows the snap to bind to network ports, which is necessary for the Docker daemon to listen for commands and for containers to expose ports. The network-control interface allows for more advanced network configuration capabilities. The opengl interface is connected to support the NVIDIA toolkit, allowing the snap to interact with the graphics drivers.

For users operating on Ubuntu Core 16, a specific manual intervention is required. On this older LTS release, the docker:home plug is not auto-connected by default. This is likely due to the strict security model of Ubuntu Core, which minimizes the number of auto-connected interfaces to reduce the attack surface. To grant the Docker snap access to the home directory on Ubuntu Core 16, the user must manually execute the connection command.

sudo snap connect docker:home

This manual connection is a critical step for users on Ubuntu Core 16 who wish to store Docker configurations or data in their home directory. Failure to connect this interface may result in errors when attempting to save Docker images or configurations in standard locations.

Interface Management and Manual Connections

While the initial installation handles many connections automatically, certain interfaces require manual connection, particularly in development environments or specific configurations. The Docker snap has several plugs that must be connected to their corresponding system slots to enable full functionality. These connections are not always made automatically to maintain the principle of least privilege, ensuring that the snap only has access to the resources it explicitly requests and the system explicitly grants.

To enable full control over Docker, including the ability to run privileged containers or access specific system resources, users may need to connect additional interfaces. The following commands are used to manually connect these interfaces. It is important to note that these commands must be run with root privileges.

sudo snap connect docker:firewall-control :firewall-control sudo snap connect docker:network-control :network-control sudo snap connect docker:docker-cli docker:docker-daemon sudo snap connect docker:home

The connection of docker:docker-cli to docker:docker-daemon is particularly significant. This interface allows the Docker command-line interface (CLI) to communicate with the Docker daemon. In a standard Docker installation, this communication happens via a Unix socket or a TCP connection. In the snap environment, the interface ensures that the CLI has the necessary permissions to send commands to the daemon, respecting the confinement boundaries.

The docker:privileged interface is another critical connection for development and testing scenarios. When building or developing the Docker snap itself, or when running containers that require elevated privileges, this interface must be connected. The command to connect this interface involves linking the docker:privileged plug to the docker-support slot.

sudo snap connect docker:privileged :docker-support sudo snap connect docker:support :docker-support

The support interface is also connected to docker-support, ensuring that the snap can access necessary support files and resources. The disable and enable commands are also relevant in the lifecycle management of the snap. To disable the Docker snap, preventing it from running its daemon, the user can execute the disable command.

sudo snap disable docker

To re-enable it, the enable command is used.

sudo snap enable docker

These commands provide a quick way to stop and start the Docker service without removing the snap entirely, which is useful for troubleshooting or maintenance.

User Permissions and Socket Access

One of the most common challenges users face when managing Docker, regardless of the installation method, is permission issues. By default, Docker daemon processes run as the root user. Consequently, only the root user can control Docker by default. For non-root users to interact with Docker, they need access to the Docker Unix socket, which is typically located at /var/run/docker.sock. The Docker snap, being confined, adds an additional layer of complexity to this issue.

To allow a non-root user to control Docker, access to the Docker socket must be granted. There are several methods to achieve this, but the most common and secure approach involves creating a docker group and adding the user to it. However, with the snap installation, additional steps are required to ensure that the snap's confinement does not block access to the socket.

The process begins by creating a system group named docker. The group ID should be less than 1000 to indicate it is a system group.

sudo addgroup --system docker

Next, the current user is added to this docker group. This grants the user membership in the group that will have permission to access the Docker socket.

sudo usermod -aG docker "${USER}"

However, simply adding the user to the group is not sufficient if the socket file permissions are not configured correctly. The file permissions of /var/run/docker.sock must be adjusted to allow read and write access for the docker group. This can be achieved using the setfacl command, which sets file access control entries.

sudo setfacl -m g:docker:rw /var/run/docker.sock

This command modifies the Access Control List (ACL) of the socket file, granting read and write permissions to the docker group. After these steps, the user should log out and log back in to ensure that the group membership changes take effect.

To verify that the configuration is correct and that the user can control Docker, a test command can be run. The hello-world container is a standard test image used to verify Docker installations.

docker run hello-world

If this command executes successfully and prints the standard welcome message, it indicates that the user has the necessary permissions to interact with the Docker daemon through the snap.

NVIDIA GPU Support

The Docker snap includes support for NVIDIA GPUs, allowing users to run containers that require GPU acceleration. This is particularly useful for machine learning, deep learning, and scientific computing workloads. The NVIDIA support is managed through the NVIDIA runtime, which is included in the snap.

To enable NVIDIA support, users can configure the snap using the snap set command. By default, NVIDIA support may be enabled, but it can be disabled if not needed.

snap set docker nvidia-support.disabled=true

This command disables NVIDIA support. To enable it, the opposite configuration would be applied, or the default settings would be left in place. Once enabled, users can run containers with GPU access by specifying the nvidia runtime.

A generic example of running a container with GPU support involves using the --runtime flag to specify the nvidia runtime and the --gpus flag to specify which GPUs to use.

docker run --rm --runtime nvidia --gpus all {cuda-container-image-name}

This command runs a container from the specified CUDA container image, using all available GPUs. The --rm flag ensures that the container is removed after it exits, keeping the system clean.

Alternatively, users can specify the NVIDIAVISIBLEDEVICES environment variable within the container to control which GPUs are visible.

docker run --rm --runtime nvidia --env NVIDIA_VISIBLE_DEVICES=all {cuda-container-image-name}

If the container image already has the appropriate environment variables set, users may only need to specify the nvidia runtime without additional arguments.

To validate that the NVIDIA environment is set up correctly, users can run a temporary container and execute the nvidia-smi command. This command displays information about the NVIDIA GPUs, including their status, memory usage, and power usage.

docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

If the command outputs the expected information about the GPUs, it confirms that the NVIDIA support is working correctly within the Docker snap.

Development and Building the Docker Snap

Developing the Docker snap package typically requires a "classic" Ubuntu distribution, such as Ubuntu Server or Ubuntu Desktop. Classic distributions do not enforce the strict confinement model of Ubuntu Core, making it easier to develop and test snaps.

The first step in developing the Docker snap is to install the snap tooling. The snapcraft command is the primary tool for building snaps. It needs to be installed with classic confinement to allow it to access the full system during the build process.

sudo snap install snapcraft --classic

Next, the source code for the Docker snap must be obtained. This is done by cloning the repository from GitHub.

git clone https://github.com/canonical/docker-snap cd docker-snap

Once in the repository directory, the snap can be built. The -v flag enables verbose output, providing detailed information about the build process.

snapcraft -v

After the build is complete, a new snap file is created. This file can be installed on the system for testing. The --dangerous flag is required because the snap is not signed by the Snap Store, and snapd will refuse to install it without explicit permission.

sudo snap install --dangerous ./docker_[VER]_[ARCH].snap

Replace [VER] with the version number and [ARCH] with the architecture of the built snap. After installation, the relevant plugs and slots must be manually connected, as they are not auto-connected in a development environment. The commands for connecting these interfaces are the same as those used in the production environment.

sudo snap connect docker:privileged :docker-support sudo snap connect docker:support :docker-support sudo snap connect docker:firewall-control :firewall-control sudo snap connect docker:network-control :network-control sudo snap connect docker:docker-cli docker:docker-daemon sudo snap connect docker:home

The upgrade.sh script is a utility included in the repository that simplifies the process of updating the Docker snap. This script updates the version tags in the snapcraft.yaml file for all parts except those related to NVIDIA. It does this by launching a virtual machine, installing Docker Engine Community Edition from the official Docker archive, and extracting version information using docker version, docker compose version, and docker buildx version. This automation ensures that the snap always tracks the latest stable releases of Docker and its associated tools.

Testing and Quality Assurance

The Docker snap undergoes rigorous testing to ensure its stability and reliability. Various tests are in place to cover different aspects of the snap's functionality. Automated smoke testing is performed via a GitHub workflow, ensuring that basic functionality is maintained after every change. Nvidia testing is conducted using Testflinger, a testing framework designed for embedded and IoT devices, ensuring that GPU acceleration works correctly across different hardware platforms. Spread tests and Checkbox tests are also used to validate the snap's behavior in various scenarios.

To run these tests against a specific revision of the Docker snap, users can install the edge channel of the snap. The edge channel contains the latest development builds and is ideal for testing new features and fixes.

sudo snap install docker --edge

After installing the edge revision, users can install the Checkbox runtime and frontend. Checkbox is a testing platform used by Canonical to test hardware and software compatibility.

sudo snap install checkbox22 sudo snap install checkbox --channel 22.04/stable --classic

Once Checkbox is installed, users can run the checkbox-cli command to execute the tests.

checkbox.checkbox-cli

In the Checkbox interface, users can press f to filter for Docker plans. A list of available test plans will be displayed. Among these, the "Fully automated QA tests for Docker containers" is a key test plan that validates the core functionality of the Docker snap. Users can select this test plan and press Enter to continue. The test will then run automatically, executing a series of checks to ensure that Docker containers can be created, run, and managed correctly within the snap environment. This comprehensive testing approach helps identify and resolve issues before they reach the stable channel, ensuring a high level of quality for end-users.

The Limitations of Snap Inside Docker

While the Docker snap allows Docker to run within the snap ecosystem, the reverse is not straightforward. Running snap inside a Docker container presents significant challenges. This is because snap requires systemd to be running as the first process in the system. Docker containers, by design, do not run systemd as the PID 1 process. Instead, they run a specific application or service. This architectural difference creates a fundamental incompatibility.

Even if one were to bypass the systemd requirement by running snapd as the first process in the container, snap requires specific capabilities to manage Linux kernel namespaces. These capabilities are often restricted in Docker containers for security reasons. Attempting to install snapd or run snap commands in a standard Docker container would likely fail due to these missing capabilities.

The community consensus, as reflected in discussions on Docker forums, is that a container is not a virtual machine. Containers are designed to isolate applications, not to provide a full operating system environment. If a user requires a full operating system with systemd running inside an isolated environment, LXD is the recommended solution. LXD can run full OS images in LXC containers, which are more similar to virtual machines in terms of resource isolation and system service management. Docker was not designed for this use case, and attempting to force it often leads to complex and fragile configurations.

Alternative Approaches: Docker for Snapcraft

While running snap inside Docker is challenging, the reverse workflow—using Docker to build snaps—is a common and supported practice. Snapcraft, the command-line tool for writing and publishing software as snaps, can be run inside a Docker container. This approach is particularly useful for developers who are working on macOS or Windows, as snapcraft requires a Linux environment to build snaps.

A Docker image created by codeghar provides a convenient way to run snapcraft in a container. This image is based on Ubuntu 16.04 Xenial, a version that is known to work well with snapcraft. By running this Docker container, developers can execute snapcraft commands as if they were on a native Ubuntu system. This workflow allows for consistent build environments across different host operating systems, ensuring that snaps are built in a controlled and reproducible manner.

This approach highlights the complementary nature of Docker and snaps. While they are not always compatible in a nested runtime environment, they can be used together in a build pipeline to leverage the strengths of both technologies. Docker provides the isolation and portability for the build environment, while snapcraft provides the tooling for creating secure, auto-updating packages.

Summary of Technical Specifications

The following table summarizes the key technical specifications and characteristics of the Docker snap as derived from the reference materials.

Conclusion

The Docker snap represents a sophisticated integration of containerization technology within the secure and managed environment of the snap ecosystem. By providing a patched version of Docker Engine with broad architecture support and integrated NVIDIA toolkit capabilities, Canonical has created a solution that caters to a wide range of users, from desktop developers to enterprise administrators. The confinement model, while imposing certain restrictions, ensures a higher level of security and system integrity. The requirement for manual interface connections and careful permission management reflects the trade-offs inherent in running complex system services within a confined environment.

The challenges associated with running snap inside Docker highlight the fundamental differences between application containers and full operating system virtualization. This distinction reinforces the importance of choosing the right tool for the job: Docker for application isolation and deployment, and LXD or native installations for full OS management. Conversely, the ability to use Docker to build snaps demonstrates the flexibility of these technologies when used in a complementary manner. For developers and system administrators, understanding the nuances of the Docker snap, from its installation and configuration to its development and testing processes, is essential for leveraging its full potential in modern Linux environments. The ongoing maintenance and testing efforts by Canonical ensure that the Docker snap remains a reliable and up-to-date option for those who choose to adopt it.