CoreOS is a new operating system with a completely changed mindset. The idea goes away from single servers and moves completely towards security and high-availability clusters. All the management is done at cluster level. CoreOS ships and integrates with components that simplify the overall cluster management.

Within this series, we’re diving through the components of CoreOS and their roles within the ecosystem. Further, we set up a cluster, deploy services (applications), use service discovery and share important system information throughout the cluster.

CoreOS Series Overview

CoreOS

The term CoreOS is kind of confusing. Actually, CoreOS is the name of three things: the company, the operating system and the platform. Generally speaking, the company CoreOS develops an operating system also called CoreOS and offers a managed Linux platform. Within this series of articles about CoreOS, we completely focus on the operating system.

CoreOS is a minimal and powerful operating system with the key idea that you never ever need to worry about system updates. At its core, CoreOS runs a minimal system kernel and ships with out-of-the-box support for container systems like docker and nspawn (there will be support for rkt soon).

With CoreOS, you’re able to spin up a cluster easily and the entire system is build for high-availability clusters. Security patches and system updates are applied automatically. The required system reboots are handled automatically with the help of etcd. By default, only one machine at a time will reboot within the cluster.

You need to get into a completely new mindset of managing your servers. Free your mind from running a single server including an operating system with integrated package manager.

CoreOS takes the high-availability approach to a new level and utilizes components like etcd, fleet and docker to pursue its goal. The following sections explain each component in more detail.

Docker

CoreOS itself follows the philosophy of providing a minimal kernel and use containers as its “package manager” for applications. Every service and application runs isolated from one another. CoreOS currently leverages Docker as its platform to run applications on clusters.

Docker itself is a containerization platform that allows you to create stand-alone containers of any application. Containers run (long lived) processes in isolation which makes it more convenient to distribute applications throughout the cluster.

Docker allows you to package and distribute your application including all required dependencies. CoreOS uses Docker containers to run applications on top of the minimal host system. Multiple applications can run side-by-side on the same host. Running applications within containers makes cluster orchestration a lot easier. They can be moved within the cluster without the need to install application dependencies on every host.

etcd

Running applications within a cluster requires a consistent set of global data on each cluster node. Additionally, the aspect of service discovery has an important role within a cluster and therefore, a tool called etcd is developed.

etcd is a distributed key-value store designed for high-availability and cluster consensus. Its idea is to provide consistent reads and writes within the cluster even in case of host failure. Data is distributed and stored across all machines within the cluster. etcd uses the Raft consensus algorithm and is robust against leader failures. If the leader fails, it automatically performs leader election and makes one follower the leader.

CoreOS installs system updates and reboots automatically. These reboots are handled with etcd and locksmith. If you’re running a cluster with 10 machines and all machines are rebooting at the same time right after the update, there won’t be any service available to handle requests and the sense of high-availability vanishes. To prevent a reboot of the entire cluster, CoreOS uses etcd to handle restarts of machines (by default one machine at a time).

CoreOS uses etcd for automatic host detection for a cluster. Each CoreOS cluster has its own cluster identifier and etcd handles the connection of new hosts into the cluster. Further, etcd is targeted towards service discovery to let applications announce itself to etcd.

A common use-case is to store the database connection details into etcd as key-value data. All hosts within the cluster can read the information and also watch for changes to reconfigure apps dependent on the database connection.

etcd is shipped with CoreOS by default. Additionally, a command line tool called etcdctl is integrated with CoreOS as well. You can interact with etcd using either the HTTP/JSON-API or the etcdctl utility. The HTTP/JSON-API is exposed by default on http://127.0.0.1:4001/v2/keys/ and also available for every docker container running on a local machine. You can take advantage of the values stored within etcd from your apps running inside a container.

fleet

We mentioned earlier, that we need to change our thinking from single servers to clusters when using CoreOS. This also includes the change in thinking about how to start services on your cluster. For single servers you can use systemd to start services and for CoreOS clusters, there is a tool called fleet.

fleet is a cluster-level service scheduler and enables cluster orchestration. With fleet you can manage your cluster of machines as if they share a single init system. Imagine fleet as follows: instead of starting services on a specific machine, you use fleet to submit services into your cluster and the cluster manager (fleet itself) decides on the machine to start it.

CoreOS ships with fleet and also the command line tool fleetctl for management purposes. With the help of fleetctl, you’re able to get the state and information of your services submitted and running within your cluster. Besides the fact that you start applications (called services) on your cluster, you can define additional service conditions. A condition can be the placement of services on a specific host next to another service.

fleet uses systemd to start processes on machines. The processes require a defined systemd unit file with custom options. Once a service configuration is passed into fleet, you can manage them at cluster level from any other cluster machine.

Outlook

CoreOS has a completely new mindset about an operating system. Every design decision was made in regard to security and high-availability. Cluster orchestration is made simple with the help of tools like etcd, fleet and docker. You need to change your thoughts about hosting an application from a single server to a cluster level. CoreOS gets managed at cluster level and the platform makes sure your applications are available even though a host fails and stops working.

Within the next post, we’re going to set up a CoreOS cluster from scratch.

---

Additional Resources

• Changelog Podcast episode providing a great introduction to CoreOS and its components
• Docker
• rkt GitHub repository
• etcd GitHub repository
• fleet GitHub repository
• CoreOS homepage