It makes little sense to operate containers on a general-purpose OS distribution, and as a result, there are specialized container OS options. The best choice depends on everything from the hosting environment to the applications that will use it.
No container OS selection process is going to produce a good outcome if internal requirements and priorities aren't carefully evaluated first. Define several aspects of the containerization project that the OS will support:
the scope of the expected container deployment;
whether or not it could benefit from containerized OS features;
whether the container hosts also run some traditional apps.
Take the container OS choice seriously from the start. Set the allowable resource footprint for the container OS, server cost and IT operations budget to devote to the project. The container OS host matters; some OS options demand significantly more system resources than others, which can rule out certain servers and will almost always constrain what's available for the containers. Many OSes also bring along a lot of bloat, such that software elements have to be maintained but aren't used. Other OSes impose undue management burdens on IT operations staff. A careless selection could force a migration to a different OS later.
The container OS choice in context
Evaluate the current predominant OS in use across application workloads. Most container users run Linux, but many IT shops evaluating containers are accustomed to operations on Microsoft Windows Server. Some container OSes support multiple guest containers, but the best option is to use one that matches your IT operations staff's experience. Changing the OS mix in the IT estate can lead to retraining, as well as new update and maintenance procedures. If the organization's primary OS vendor does not also offer a container-tailored version, then give preference to choices that offer easy operations and maintenance.
When matching a container OS to a host OS, consider interoperability, but also be realistic in the overall enterprise application set. Some organizations maintain a cadre of Microsoft Windows Server applications for aspects such as productivity support while they build out a Linux presence. These IT teams should focus on Linux OS options to match that shifting development focus. Select an easy-to-work-with container OS that will ease the transition from Windows Server.
When matching a container OS to a host OS, consider interoperability, but also be realistic in the overall enterprise application set.
Be wary of choosing a container OS that is significantly different from the current Linux platforms in use. Staff will work with the existing Linux environment even as emerging container deployments are added on, and vast differences in management can lead to costly errors. If necessary, improve operations efficiency for diverse OSes through a DevOps tool, such as Kubernetes for container orchestration.
Container OSes and their uses
Organizations that intend to stick with Windows Server for the container OS face a complicated decision. Windows Server 2016 supports containers, but earlier versions do not. Also, the Nano Server deployment option for Windows Server 2016 is a container OS, but not a host OS. Nano Server is optimized for Azure deployments, wherein the environment provides reliability and scalability. Operations personnel can fix problems with Windows Server and tweak settings, but the immutable Nano Server is maintained differently -- by fetching a new build of the runtime image.
Editor's note:When Microsoft released Windows Server 2016, Nano Server was a deployment option that could run various infrastructure roles. Shortly thereafter, however, Microsoft set a new course for Nano Server: It will refactor the OS to only support containers in the fall semiannual channel release of Windows Server 2016 (Windows Server 2016 version 1709).
Any OS specifically designed for container hosting is simpler to manage than the full-scale, general-purpose Linux or other OS installation. RancherOS and Ubuntu Core are the smallest and simplest of the major container OS choices. RancherOS is a good choice for distributing containers on systems with limited resources, and it provides a small array of administration tools.
Container Linux by CoreOS supports Docker containers, but CoreOS also offers its own container runtime, Rkt, as an alternative. In January 2018, Red Hat moved to acquire CoreOS. Some organizations prefer Rkt to Docker for its simplicity and process model, which integrates with a variety of networking systems. If your organization isn't yet committed to a specific containerization platform, take the time to compare Docker to CoreOS Rkt. Container Linux by CoreOS is also a popular OS for users already highly skilled in container orchestration.
Compare Docker and CoreOS rkt container software.
For users committed to Docker, Boot2docker hosts containers with minimal exposure to Linux operations complexity. It hides most of the underlying Linux host processes from users and provides convenient access to container network ports to facilitate integration. Many Windows Server users exploring Linux containers like this approach.
There are also container OS options for users who don't want full general-purpose Linux but do need a bit more than a bare-bones container host. Ubuntu Core uses snap packages, which are immutable zip files that contain applications with their dependencies, to provide an application management layer. Linux admins that are shifting workloads to containers should evaluate this model. Red Hat Atomic Host is a stable Linux OS that includes a collection of container operations tools into the OS, including Docker, Atomic, Etcd and Flannel. Red Hat Atomic Host is based on upstream Project Atomic, which also works with other Linux distros. Conversely, VMware Photon Platform is a good place for a VMware user to start a container exploration, and Mesosphere DC/OS is a favored big data platform.
