Alternatives to Docker: an overview of the container platform

With the Docker container platform, virtualization on an operating system level (Operating-system-level virtualization) is making a comeback. In just a few years, the developer team managed to revive the container technology based on core functionality. Docker has established itself beyond the boundaries of the Linux universe as a resource-saving alternative to hypervisor-supported virtualization through hardware emulation.

Thanks to the medial echo and a constantly growing ecosystem, Docker has emerged as a technological market leader in the field of container-based virtualization. However, the lean container platform is by no means the only software project in which virtualization techniques are developed on an operating system level.

Which Docker alternatives are available? And how do they differ from what the market leader offers?

When it comes to Unix-like systems such as Linux, virtualization on operating system level is usually based on the further implementation of native Chroot mechanisms. In addition, container projects such as Docker, rkt, LXC, LXD, Linux VServer, OpenVZ / Virtuozzo, and runC use resource-management native Linux kernel functionalities to implement isolated runtime environments for applications or the entire operating system.

Docker relies on basic Linux kernel functions to shield processes from each other, and enables applications to run parallel in isolated containers using the self-developed runtime environment runC –  without resource-intensive guest systems. This makes the lean container platform an attractive alternative to hypervisor-based virtualization. A detailed description of the Docker platform and its basic components can be found in our Docker tutorial for beginners.

The Docker container platform is distributed as a free Community Edition (CE), but there is also a fee-based Enterprise (EE) version available. The platform provides support for various Linux distributions. In addition, Docker CE has been available as a native app for Windows and MacOS since the release of version 1.12. Docker for Mac relies on the sleek hypervisor xhyve, but to create a runtime environment for the Docker engine and Linux kernel-specific functions for the Docker daemon, the hypervisor Hyper-V is available on Windows for the same purpose.

Since September 2016, Docker EE has also been available natively for Windows Server 2016. By collaborating closely with the Docker development team, Microsoft has installed several extensions into the Windows core, which enable Docker to start processes as containers in a sandbox without an abstracting hypervisor. Microsoft has made the source code of the specially developed driver hcsshim  available to its open source community via GitHub.

The following table shows the key features of the Docker platform:

A lively ecosystem has developed around the Docker core project over time. According to the developer, the Docker engine is involved in more than 100,000 third-party projects.

The main criterion for implementing the Linux container technology as part of the Docker project is the degree of isolation of individual processes on a common host system. When running application containers, Docker uses native Linux kernel features such as cgroups and namespaces. However, these encapsulated containers are not the same size, which is the case with full virtualization based on virtual machines. To ensure safe operation of application containers on productive systems, newer versions of the container platform support kernel extensions, such as AppArmor, SELinux, Seccomp, and GRSEC, can additionally shield isolated processes.

In February 2016, CoreOS released the first stable release of the container runtime environment with rkt version 1.0. In contrast to Docker, the competitor aimed to impress with its additional security features. These include, in addition to container isolation on a KVM basis, support of the kernel extension SELinux, as well as signature validation for images of the self-developed container specification App Container (appc). This describes the image format App Container Image (ACI), the runtime environment, an image discovery mechanism, and the ability to group images into multi-container apps, known as app container pods.

Unlike Docker, rkt supports other formats besides its own container images. The runtime environment is compatible with Docker images, and with the open source tool Quay any container format can be converted to ACI.

While the Docker platform relies on a central daemon that runs in the background with root privileges, rkt manages without these background processes and instead works with established init systems, such as systemd and upstart, to start and manage containers. This circumvents the Docker problem for users wanting to start the container via daemon, and not having the root rights and therefore only having restricted access to the host system.

Unlike Docker, rkt is not limited to Linux kernel functions such as cgroups and namespaces when virtualizing applications. With the runtime environment of CoreOS, containers based on KVM (kernel-based virtual machine e.g. LKVM or QEMU) and Intel Clear Container technology can also be started as fully-enclosed virtual machines.

The appc specification and its implementation rkt are supported by industry giants such as Google, Red Hat, and VMware.

To shield processes from each other, LXC uses the following insulation techniques:

• IPC, UTS, Mount, PID, network and user namespaces
• Cgroups
• AppArmor and SELinux profile
• Seccomp rules
• Chroots
• Kernel capabilities  

The aim of the LXC project is to create a software container environment that is as similar to a standard Linux installation as possible. LXC is developed alongside the open source projects LXD, LXCFS, and CGManager under the LinuxContainers.org project.

LXC was designed to run different system containers (full-system containers) on a common host system. A Linux container usually starts a complete distribution from an operating system image in a virtual environment. Users interact with it in a similar way to how they would a virtual machine.

Applications are rarely started in Linux containers. This makes the software significantly different from the Docker project. While LXC is primarily dedicated to system virtualization, Docker focuses on virtualizing individual apps and deploying them. In the beginning, Linux containers were also used, but nowadays, Docker relies on a self-developed container format.

A major difference between both virtualization technologies is that Linux containers can contain any number of processes, whereas only one process is executed in Docker containers, so complex Docker applications usually consist of multiple containers. An effective deployment of multi-container apps like these require additional tools.

Furthermore, Docker containers and Linux containers differ in portability. If a user develops software based on LXC on a local test system, the user can’t just assume that the container will run flawlessly on other systems (e.g. a productive system). The Docker platform, however, abstracts applications much more strongly from the quality of the underlying system. This allows the same Docker container to be run on any Docker host (a system on which the Docker engine has been installed), regardless of the operating system and hardware configuration.

LXC also comes without a central daemon process. Instead, container software integrates itself into init systems such as systemd and upstart to start and manage containers.

LXD from Canonical

As a follow-up project for LXC, the Linux distributor Canonical launched the Docker alternative LXD (pronounced 'lexdi') in November 2014. The project is based on the Linux container technology and expands it with the daemon process LXD. The software sees itself as a kind of container hypervisor. The technical structure of the container solution consists of three components: LXC serves as a command line client. Also, nova-compute-lxd is featured as an OpenStack-Nova-Plug-in. as well with niova-compute-lxd. Communication between the client and the daemon is done via a REST API.

The aim of the software project is to provide a user experience based on Linux container technology similar to the operation of virtual machines, without having to accept the overhead of an emulation of hardware resources.

Like LXC, LXD focuses on supplying full-system containers. This role, as a machine management tool, differentiates LXD from Docker and rkt, whose core functions lie in the area of software deployment. LXD uses the same isolation technology as the underlying LXC project.

The daemon of the container solution requires a Linux kernel. Other operating systems are not supported. Since communication with the daemon takes place via a REST API, it is possible to access the daemon remotely via a Windows or MacOS client. In a blog article from February 2017, the LXD project manager, Stéphane Graber, describes how the standard LXD client can be configured for the desired operating system.

Since VPSs run as isolated processes on the same host system and use the same system call interface, there is no additional overhead through emulation.

The open source project launched by Jacques Gélinas was, until recently, headed by the Austrian, Herbert Pötzl. The technology is used, for example, by webhosting providers who want to offer their customers separate virtual machines on a common hardware basis.

To provide the Linux kernel with operating system-level virtualization features, it must be patched. This Linux kernel modification ensures that the technology is fundamentally different from Linux containers (LXC), which rely on native isolation functions with cgroups and namespaces.

The last release was the VServer 2.2 in 2007.

Compared to the previous version, OpenVZ 7 offers a set of new command line tools, the so-called guest tools. These enable users to perform hosting tasks directly from the host system terminal. In addition, the self-developed hypervisor for the operation of virtual machines was replaced by the established standard technologies KVM and QEMU.

When using containers, OpenVZ continues to use its own format with Virtuozzo containers. Like LXC, this primarily serves the virtualization of complete systems (VPS) and is thus separated from Docker and rkt. However, unlike LXC, OpenVZ offers the possibility of live migration via checkpoint/restore in userspace (CRIU) to create persistent images of a running container.

Technically, OpenVZ and Virtuozzo represent an extension of the Linux kernel, which provides various virtualization tools at user level. Guest systems are implemented in so-called virtual environments (VE), which run isolated on the same Linux kernel. As with the other container technologies, the overhead is avoided by hypervisor-based hardware emulation. However, the shared Linux kernel means that all virtualized guest systems are specified to the system architecture and kernel version of the host system.

The core functions of OpenVZ include dynamic real-time partitioning, resource management, and centralized management of multiple physical and virtual servers.

• Dynamic real-time partitioning: each VPS is an isolated partition of the underlying physical server. The isolation includes its own file systems, user groups (including its own root server), process trees, network addresses, and IPC objects.

• Resource management: OpenVZ allocates hardware resources via so-called resource management parameters, which are managed by the system administrator in the global configuration file and the corresponding container configuration files.

To manage virtual machines and system containers, OpenVZ and Virtuozzo rely on the Red Hat Management tool libvirt, which consists of an open source API, the libvirtd daemon, and the command line utility, virsh.

While the Enterprise product, Virtuozzo, is delivered with the integrated GUI Parallels Virtual Automation (PVA), OpenVZ comes in the basic installation without a graphical user interface. However, users have the option to install it via third-party software. The OpenVZ developer team recommends the OpenVZ Web Panel from SoftUnity. Further alternatives can be found on OpenVZ Wiki.

As a non-profit organization of the Linux foundation, Docker and other companies in the container industry launched the OCI 2015 to establish an open industry standard for software containers. Currently, the OCI provides specifications for a container runtime environment (runtime-spec) and a container image format (image-spec).

The open source run-time environment, runC can be considered as a canonical implementation of these specifications.

The runtime environment of the OCI supports only containers in the OCI bundle format and requires only a root file system and an OCI configuration file to execute containers. A tool to create root file systems for containers is not provided in the project. Users who have the Docker platform installed can, however, access their export function to extract a root file system from an existing Docker container, expand it to a config.json and therefore create an OCI bundle. In addition, other external tools such as oci-image-tools, skopeo and umoci can be used to support image creation.

Like the Docker alternatives, rkt and LXC no central daemon process is used with runC. Instead, the container runtime environment is integrated with the init process, systemd.

The following table shows a comparison of all the alternatives to Docker presented in this article.

The concept of partitioning system resources by means of core isolation mechanisms and providing independently-encapsulated processes on the same system can be found in various Unix-like operating systems. Linux containers with the term 'jail' under BSD systems and the zones introduced with Solaris 10 are comparable. For Windows systems, there are the container concepts: Microsoft Drawbridge, WinDocks, Sandboxie, Turbo, and VMware ThinApp.

For each jail, independent user groups (whose rights are limited to the jail environment) can be defined via their own user management. For example, a user who has extensive privileges within a jail can’t perform critical system operations outside the virtual environment. This ensures that a hacker from a compromised jail can not cause any major damage to the system.

Similar to other approaches to virtualization on an operating system level, Solaris zones provide a resource-saving way to implement various isolated operating systems on a common system instance.

The native Docker engine for Windows Server 2016 differs from the Docker for Windows and Docker for Mac applications. While the latter allows the operation of the Docker engine developed for Linux using a lean virtual machine, the Docker version for Windows Server 2016 uses the Windows kernel directly. Classic Docker containers can’t be run on Windows Server 2016. Instead, a new container format called WSC (Windows Server Container) was developed as part of the Docker project. In addition, Microsoft offers a Hyper-V-based container variant that allows better isolation.

• Windows Server Container: with Windows Server Containers (WSC), Microsoft provides a container technology for the Docker platform, which enables process with advanced Windows Kernel functions to be isolated. As with Linux technology, Windows server containers share the underlying host system (container host)’s kernel.

• Hyper-V-Container: with Hyper-V Containers, Microsoft provides a way to shield container instances by using traditional hypervisor-based virtualization. Hyper-V Containers are virtual machines that can be controlled via the Docker platform, just like Windows Server Containers, but have a much higher degree of isolation with their own Windows kernel.

Even before Microsoft has implemented native container technologies in the Windows kernel as part of the Docker collaboration, various developers have dealt with resource-saving virtualization methods for Windows systems. Microsoft Drawbridge, WinDocks, Sandboxie, Turbo, and VMware are among the more well-known projects.

Microsoft Drawbridge

Under the name Drawbridge, Microsoft developed the prototype of a visualization technology, based on the concept of the Library OS – an operating system implemented as a set of libraries within an application. With Drawbridge, applications are run together with the Library OS in so-called Pico processes. These are process-based isolation containers with a kernel interface. In the Windows server container documentation, Microsoft specifies the Drawbridge experience as an important input for container server technology development for Windows Server 2016.

WinDocks

WinDocks is a Docker port for Windows, which is used to create and manage app containers for .NET applications and data containers for SQL servers. Unlike Windows server containers that are currently limited to Windows 10 and Windows Server 2016 systems, WinDocks is also available for older operating systems such as Windows Server 2012, Windows Server 2012 R2, as well as Windows 8 and 8.1. The software is offered for free as the Community edition and as an Enterprise product with customer support.

Sandboxie

Using Sandboxie, applications can run on Windows in an isolated environment called Sandbox. Similar to container technology, this method aims to shield the underlying host system and other applications from program activities of isolated applications. For this purpose, the tool switches between the application and the operating system in order to intercept hard disk write accesses, and redirect them to a protected area. In addition to accessing files, this also prevents write requests from the Windows registry database. Sandboxie is available for all current versions of Windows, as well as for XP and Vista as a free basic version. In addition, fee-based versions with extended functional spectrums are available for private users and commercial use.

Turbo (formerly Spoon)

Turbo is a Docker alternative for Windows, which packs applications and all their dependencies such as .NET, Java, or databases such as SQL Server or MongoDB in isolated containers. However, unlike Windows server containers, these are not natively supported by the Windows kernel, which is why a virtual machine (similar to Docker for Windows) is needed to compensate for inconsistencies. Turbo containers therefore run on the Spoon Virtual Machine Engine (SVM), which acts as an interface to the Windows kernel. The exchange of container applications also takes place at Turbo via a cloud-based hub. The software is well documented, but doesn’t receive as much attention compared to Docker.

VMware ThinApp

VMware ThinApp is a tool for application virtualization in a desktop environment. The software makes it possible to provide conflict-free applications in complex IT infrastructures. For this purpose, these, including all dependencies, are packaged in an executable EXE or MSI file and therefore isolated from the underlying operating system and other applications. The file created by ThinApp can be run on any Windows system without the need for installation (and therefore without admin rights) – optionally also from a portable storage medium (e.g. a USB flash drive). An alternative to Docker is the ThinApp when migrating legacy applications or isolating critical programs.