[EN] - CoreOS: first impressions
15/01/2015This post isn’t a tutorial to install or use CoreOS, but rather my impressions of the system.
Introduction
CoreOS is a Linux distribution redesigned to provide the necessary resources to maintain a modern, highly scalable and easy to manage infrastructure.
Unlike Ubuntu or Debian, CoreOS doesn’t have a package manager, so any software that you want to install will use Docker containers by default. Docker provides process isolation and CoreOS take advantage of that, allowing applications to be distributed in a cluster easily.
Another difference between most Linux distributions is that the system is maintained as a whole, so the CoreOS makes use of a double root partition scheme. This scheme allows the system to install the update on a different root partition that is in use.
See the example, the system is initialized to use the partition A, the
CoreOS checks for available updates, then downloads and installs it in
the B partition. This ensures that network boundaries rates and I/O do
not cause an overload in applications in progress, as this update
process is isolated with cgroups.
To complete the upgrade the machine must be rebooted and that the system
will use the B partition, if any problem happens while updating the
system, CoreOS will perform a rollback and return to use the A partition.
Etcd
One of the main requirements of running a cluster is the ability to
communicate between the nodes. CoreOS accomplish that through ETCD,
a global key-value scheme responsible for managing the discovery
of services, which allows us to create dynamic applications.
Application containers running on your cluster can read and write data into etcd. Common examples are storing database connection details, cache settings, feature flags, and more.
CoreOS uses a file called cloud-config which allows customization of
network configurations, systemd units and other OS-level options.
The file is saved in the YAML format and is processed during startup
of the machine.
In addition it is responsible for storing the settings that allow for ETCD discover the cluster where the machine should join. An example of cloud-config file would look like this:
coreos:
etcd:
# generate a new token for each unique
# cluster from https://discovery.etcd.io/new
discovery: https://discovery.etcd.io/<token>
addr: $private_ipv4:4001
peer-addr: $private_ipv4:7001
fleet:
public-ip: $private_ipv4 # used for fleetctl ssh command
units:
- name: etcd.service
command: start
- name: fleet.service
command: start
In each ETCD the client node is running and configured to communicate with other nodes in the cluster:
The operation of ETCD to share configuration data is based on an REST API (HTTP and JSON) by default in: http://127.0.0.1:4001/v2/keys/. Use docker with ETCD is very interesting, because ETCD runs on every host at the same ip address. This way you can send a single container for different nodes in a cluster.
Fleet
For clusters control the system provides a tool called Fleet, it works as a process manager that facilitates the configuration of applications from a single point.
In the cluster environment, each node has its own systemd, which is a
boot system to manage local services. The fleet kicks in providing an
interface to control each present systemd on the cluster nodes.
This way you can start or stop services, list information of running
processes across the cluster.
Besides that, the fleet controls the processes distribution mechanism
choosing the less busy hosts to start the services. All this flexibility
ensures a simple implementation to separate nodes in containers:
Conclusion
The CoreOS is very different from most Linux distributions that I’m used to, its design was created to facilitate the management of clusters and portability of applications.
I’m impressed by the CoreOS project and soon I’ll invest more time in it. Next, I’ll post about creating clusters with CoreOS + Docker. Tune in to learn more about Docker and CoreOS.