| Container Linux | |
|---|---|
| Developer | CoreOS team,Red Hat |
| OS family | Linux (based onGentoo Linux) |
| Working state | Discontinued[1] |
| Source model | Open source |
| Initial release | October 3, 2013; 12 years ago (2013-10-03)[2] |
| Final release | 2512.3.0[3] / May 22, 2020; 5 years ago (2020-05-22) |
| Final preview | 2513.2.0[4](Beta) / May 22, 2020; 5 years ago (2020-05-22) 2514.1.0[5](Alpha) / May 22, 2020; 5 years ago (2020-05-22) |
| Repository | github |
| Marketing target | Servers andclusters |
| Supported platforms | x86-64[6] |
| Kernel type | Monolithic (Linux kernel) |
| License | Apache License 2.0[7][8] |
| Succeeded by | Fedora CoreOS RHEL CoreOS Flatcar Container Linux |
| Official website | fedoraproject |
Container Linux (formerlyCoreOS Linux) is a discontinuedopen-source lightweightoperating system based on theLinux kernel and designed for providing infrastructure forclustered deployments. One of its focuses wasscalability. As an operating system, Container Linux provided only the minimal functionality required for deploying applications insidesoftware containers, together with built-in mechanisms forservice discovery and configuration sharing.[9][10][11][12][13]
Container Linux shares foundations withGentoo Linux,[14][15]ChromeOS, andChromiumOS through a commonsoftware development kit (SDK). Container Linux adds new functionality and customization to this shared foundation to support server hardware and use cases.[12][16]: 7:02 CoreOS was developed primarily byAlex Polvi, Brandon Philips, and Michael Marineau,[11] with its major features available as astable release.[17][18][19]
The CoreOS team announced theend-of-life for Container Linux on May 26, 2020,[1] offeringFedora CoreOS,[20] andRHEL CoreOS as its replacement.
Container Linux provides nopackage manager as a way for distributing payload applications, requiring instead all applications to run inside their containers. Serving as a single control host, a Container Linux instance uses the underlyingoperating-system-level virtualization features of the Linux kernel to create and configure multiple containers that perform as isolatedLinux systems. That way,resource partitioning between containers is performed through multiple isolateduserspace instances, instead of using ahypervisor and providing full-fledgedvirtual machines. This approach relies on the Linux kernel'scgroups andnamespaces functionalities,[21][22] which together provide abilities to limit, account and isolate resource usage (CPU, memory, diskI/O, etc.) for the collections of userspaceprocesses.[10][13][23]
Initially, Container Linux exclusively usedDocker as a component providing an additional layer of abstraction andinterface[24] to the operating-system-level virtualization features of the Linux kernel, as well as providing a standardized format for containers that allows applications to run in different environments.[10][23] In December 2014, CoreOS released and started to supportrkt (initially released asRocket) as an alternative to Docker, providing through it another standardized format of the application-container images, the related definition of the containerruntime environment, and aprotocol for discovering and retrieving container images.[25][26][27][28] CoreOS provides rkt as an implementation of the so-calledapp container (appc) specification that describes the required properties of theapplication container image (ACI). CoreOS created appc and ACI as an independent committee-steered set of specifications[29][30] aimed to become part of the vendor- and operating-system-independentOpen Container Initiative, or OCI, initially named theOpen Container Project (OCP) containerization standard,[31] which was announced by a group of large tech companies in June 2015.[32][33][34]
Container Linux usesebuild scripts from Gentoo Linux for automatedcompilation of its system components,[14][15] and usessystemd as its primaryinit system, with tight integration between systemd and various Container Linux's internal mechanisms.[10][35]
Container Linux achieves additional security and reliability of its operating systemupdates by employingFastPatch as a dual-partition scheme for the read-only part of its installation, meaning that the updates are performed as a whole and installed onto a passive secondary bootpartition that becomes active upon a reboot orkexec. This approach avoids possible issues arising from updating only certain parts of the operating system, ensures easy rollbacks to a known-to-be-stable version of the operating system, and allows each boot partition to besigned for additional security.[10][13][36] The root partition and itsroot file system are automatically resized to fill all available disk-space upon reboots; while the root partition provides read-write storage space, the operating system itself ismounted read-only under/usr.[37][38][39]
To ensure that only a certain part of thecluster reboots at once when the operating system updates are applied, preserving the resources required for running deployed applications, CoreOS provideslocksmith as areboot manager for Container Linux.[40] Using locksmith, one can select between different update strategies that are determined by how the reboots are performed as the last step in applying updates; for example, one can configure how many cluster members are allowed to reboot simultaneously. Internally, locksmith operates as thelocksmithddaemon that runs on cluster members, while thelocksmithctlcommand-line utility manages configuration parameters.[41][42] Locksmith is written in theGo language and distributed under the terms of theApache License 2.0.[43]
The updates distribution system employed by Container Linux is based onGoogle's open-sourceOmaha project, which provides a mechanism for rolling out updates and the underlyingrequest–response protocol based onXML.[6][44][45] Additionally, CoreOS providesCoreUpdate as a web-baseddashboard for the management of cluster-wide updates. Operations available through CoreUpdate include assigning cluster members to different groups that share customized update policies, reviewing cluster-wide breakdowns of Container Linux versions, stopping and restarting updates, and reviewing recorded update logs. CoreUpdate also provides anHTTP-basedAPI that allows its integration into third-party utilities ordeployment systems.[36][46][47]

Container Linux provides etcd, a daemon that runs across all computers in a cluster and provides a dynamic configuration registry, allowing various configuration data to be easily and reliably shared between the cluster members.[6][37] Since thekey–value data stored withinetcd is automaticallydistributed andreplicated with automatedmaster election andconsensus establishment using theRaft algorithm, all changes in stored data are reflected across the entire cluster, while the achievedredundancy prevents failures of single cluster members from causing data loss.[28][49] Beside the configuration management,etcd also providesservice discovery by allowing deployed applications to announce themselves and the services they offer. Communication withetcd is performed through an exposedREST-based API, which internally usesJSON on top of HTTP; the API may be used directly (throughcurl orwget, for example), or indirectly throughetcdctl, which is a specialized command-line utility also supplied by CoreOS.[10][13][50][51][52] etcd is also used inKubernetes software.
Container Linux also provides thefleet cluster manager, which controls Container Linux's separate systemd instances at the cluster level. As of 2017, "fleet" is no longer actively developed and is deprecated in favor of Kubernetes.[53] By usingfleetd, Container Linux creates a distributedinit system that ties together separate systemd instances and a cluster-wideetcd deployment;[49] internally,fleetd daemon communicates with localsystemd instances overD-Bus, and with theetcd deployment through its exposed API. Usingfleetd allows the deployment of single or multiplecontainers cluster-wide, with more advanced options includingredundancy,failover, deployment to specific cluster members, dependencies between containers, and grouped deployment of containers. A command-line utility calledfleetctl is used to configure and monitor this distributed init system;[54] internally, it communicates with thefleetd daemon using a JSON-based API on top of HTTP, which may also be used directly. When used locally on a cluster member,fleetctl communicates with the localfleetd instance over aUnix domain socket; when used from an external host,SSH tunneling is used with authentication provided throughpublic SSH keys.[55][56][57][58][59]
All of the above-mentioned daemons and command-line utilities (etcd,etcdctl,fleetd andfleetctl) are written in the Go language and distributed under the terms of the Apache License 2.0.[8][60]
When running on dedicated hardware, Container Linux can be either permanently installed on local storage, such as ahard disk drive (HDD) orsolid-state drive (SSD),[61] or booted remotelyover a network usingPreboot Execution Environment (PXE) in general, oriPXE as one of its implementations.[62][63] CoreOS also supports deployments on varioushardware virtualization platforms, includingAmazon EC2,DigitalOcean,Google Compute Engine,Microsoft Azure,OpenStack,QEMU/KVM,Vagrant andVMware.[13][64][65][66] Container Linux may also be installed on Citrix XenServer, noting that a "template" for CoreOS exists.
Container Linux can also be deployed through its commercial distribution calledTectonic, which additionally integrates Google'sKubernetes as a cluster management utility. As of April 2015[update], Tectonic is planned to be offered asbeta software to select customers.[29][67][68] Furthermore, CoreOS providesFlannel as a component, implementing anoverlay network required primarily for the integration with Kubernetes.[29][69][70]
As of February 2015[update], Container Linux supports only thex86-64 architecture.[6]
Following its acquisition of CoreOS, Inc.[71] in January 2018, Red Hat announced[72] that it would be merging CoreOS Container Linux with Red Hat's Project Atomic to create a new operating system, Red Hat CoreOS, while aligning the upstream Fedora Project open source community around Fedora CoreOS, combining technologies from both predecessors.
On March 6, 2018, Kinvolk GmbH announced Flatcar Container Linux, a derivative of CoreOS Container Linux.[73] Flatcar tracks the upstream CoreOS alpha, beta, and stable channel releases, with an experimental Edge release channel added in May 2019.[74]
LWN.net reviewed CoreOS in 2014:[75]
For those who are putting together large, distributed systems—web applications being a prime example—CoreOS would appear to have a lot of interesting functionality. It should allow applications of that type to grow and shrink as needed with demand, as well as provide a stable platform where upgrades are not a constant headache. For "massive server deployments", CoreOS, or something with many of the same characteristics, looks like the future.
Announced at the DockerCon conference in San Francisco on Monday, the Open Container Project (OCP) will maintain and develop a common container runtime and image format based in part on code and specs donated by Docker.