Container Linux provides no
package 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 underlying
operating system-level virtualization features of the Linux kernel to create and configure multiple containers that perform as isolated
Linux systems. That way,
resource partitioning between containers is performed through multiple isolated
userspace instances, instead of using a
hypervisor and providing full-fledged
virtual machines. This approach relies on the Linux kernel's
cgroups and
namespaces functionalities, which together provide abilities to limit, account and isolate resource usage (
CPU, memory, disk
I/O, etc.) for the collections of userspace
processes. Initially, Container Linux exclusively used
Docker as a component providing an additional layer of abstraction and
interface 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. CoreOS provides rkt as an implementation of the so-called
app container (appc) specification that describes the required properties of the
application container image (ACI). CoreOS created appc and ACI as an independent committee-steered set of specifications aimed to become part of the vendor- and operating-system-independent
Open Container Initiative, or OCI, initially named the
Open Container Project (OCP) containerization standard, which was announced by a group of large tech companies in June 2015. Container Linux uses
ebuild scripts from Gentoo Linux for automated
compilation of its system components,
Updates distribution Container Linux achieves additional security and reliability of its operating system
updates by employing
FastPatch 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 boot
partition that becomes active upon a reboot or
kexec. 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 be
signed for additional security. The root partition and its
root 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 is
mounted read-only under . To ensure that only a certain part of the
cluster reboots at once when the operating system updates are applied, preserving the resources required for running deployed applications, CoreOS provides
locksmith as a
reboot manager for Container Linux. 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 the
daemon that runs on cluster members, while the
command-line utility manages configuration parameters. Locksmith is written in the
Go language and distributed under the terms of the
Apache License 2.0. The updates distribution system employed by Container Linux is based on
Google's open-source
Omaha project, which provides a mechanism for rolling out updates and the underlying
request–response protocol based on
XML. Additionally, CoreOS provides
CoreUpdate as a web-based
dashboard 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 an
HTTP-based
API that allows its integration into third-party utilities or
deployment systems.
Cluster infrastructure 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. Beside the configuration management, also provides
service discovery by allowing deployed applications to announce themselves and the services they offer. Communication with is performed through an exposed
REST-based API, which internally uses
JSON on top of HTTP; the API may be used directly (through or , for example), or indirectly through , which is a specialized command-line utility also supplied by CoreOS. etcd is also used in
Kubernetes software. Container Linux also provides the 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. By using , Container Linux creates a distributed
init system that ties together separate systemd instances and a cluster-wide deployment; internally, it communicates with the daemon using a JSON-based API on top of HTTP, which may also be used directly. When used locally on a cluster member, communicates with the local instance over a
Unix domain socket; when used from an external host,
SSH tunneling is used with authentication provided through
public SSH keys. All of the above-mentioned daemons and command-line utilities (, , and ) are written in the Go language and distributed under the terms of the Apache License 2.0. == Deployment ==