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:
[Unit] Description=My Service Requires=docker.service After=docker.service [Service] ExecStart=/usr/bin/docker run busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done" [Install] WantedBy=multi-user.target
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.
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
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.