CoreOS's init system and configuration platform

systemd Overview

CoreOS uses systemd as the core of its distributed init system, fleet. Systemd is well supported in many Linux distros, making it familiar to most engineers. Every aspect of CoreOS is deeply integrated with systemd.

We chose systemd for a few primary reasons:

  • Performance
    Systemd boots extremely fast, with our goal to keep it under 1s.
  • Journal
    Systemd's logging journal has modern features such as JSON export, forward sealing, and indexing for fast querying.
  • Socket Activation
    While this might be a bit of a throw back to the inetd days, we think socket activation is particularly useful for inter-service dependency management.
Description=My Service

ExecStart=/usr/bin/docker run busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"

Example service file that runs a docker container.

Systemd has an extremely rich syntax that can describe the attributes of a particular service. Your services can express hard or soft dependencies, the order of launch relative to those dependencies, and identify conflicting services. Docker containers are much easier to manage when you can specify whether they automatically restart per container and customize the timing for restarting.

Service files are just plain text documents — they are easy to edit and store in version control. Generating service files on demand is also very simple. You can even prevent services from being started or stopped manually if you're controlling systemd programmatically.

But wait, there's more! Check out what people are saying about CoreOS on Twitter.

Using Fleet to Run Systemd Units

Fleet presents the cluster as a distributed init system by aggregating systemd running on each machine. Units are submitted into fleet and the units scheduled onto machines in the cluster based on fleet-specific configuration parameters encoded in the unit file.

Fleet provides a direct pass-through to systemd, which means that unit files can use systemd's advanced dependency management features. For example, two units can declare that they must reside on the same machine and Requires=, Before=, After= and BindsTo= parameters will work as expected. If the machine running these two units fails, they will be restarted in the correct manner on an eligible host elsewhere in the cluster.