Etcd and fleet

Posted Oct 25, 2014 16:34 UTC (Sat) by kleptog (subscriber, #1183)
Parent article: Etcd and fleet

The last few years have been awesome in the Linux space. Docker bringing Linux containers to the masses. An extensible declarative system for describing services from systemd. And now the combination with stuff like etcd and fleet looks to completely change the way servers are set up and run.

Stuff like fleet would not have been possible with sysvinit, that's for sure.

I'm a little bummed by the fact that CoreOS is based on Gentoo though. Bad experiences.

Etcd and fleet

Posted Oct 25, 2014 19:14 UTC (Sat) by dlang (guest, #313) [Link] (4 responses)

why would something like fleet be impossible with sysvinit?

Etcd and fleet

Posted Oct 25, 2014 20:55 UTC (Sat) by kleptog (subscriber, #1183) [Link] (2 responses)

Because to be able to have a stable system and to do things like failover you have to be able to answer the question "is this service still running?" and be able to receive a notification when a service dies. Sysvinit doesn't do that, it just starts services and forgets about them.

Things like daemontools are a step up, since it can at least tell when something dies, but it doesn't have the same kind of control.

Since unit files can also do things like job scheduling, you'd have to write something to distribute cron jobs as well.

You could probably attempt it with sysinit, but you'd get completely lost in the half-baked status scripts, inconsistent logging and other annoyances.

Etcd and fleet

Posted Oct 25, 2014 21:01 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

"Is this service still running" is a rather complex question to answer, and it's far from clear that what an init system can do is sufficient.

There are lots of times when the process has not exited that the service is not healthy enough to function and failover is needed.

Sysvinit does support restarting processes if they exit, that's what inittab did. It did the job well and wasn't hard to manage (I had a server at one time with several hundred entries in inittab

Etcd and fleet

Posted Oct 25, 2014 23:42 UTC (Sat) by anselm (subscriber, #2796) [Link]

In sysvinit, when you run your services from inittab, you give up the convenience of being able to start and stop them manually using “/etc/init.d/SCRIPT start” (or whatever). You also give up the ability to start them in a defined order so as to obey dependencies on other services. When you run your services by means of init scripts, you give up automatic restarts (and must add them again by means of piling on more hacks). This is an arbitrary and inconvenient dichotomy.

Systemd handles all services identically, whether they're automatically restarted or not. Dependencies and manual start/stop are available for all services. Exactly under what conditions a service is restarted, as well as rate-limiting for restarts, can be extensively configured. Systemd also supports “watchdog” functionality that can restart a service if the process appears to be running but hasn't shown signs of life for a specific time. In this respect systemd is in fact considerably superior to sysvinit.

Claiming that ”sysvinit does support restarting processes if they exit” is technically correct (under certain limited circumstances, anyway). Claiming that sysvinit does it as well as systemd, however, is ludicrous.

Etcd and fleet

Posted Oct 28, 2014 5:17 UTC (Tue) by raven667 (subscriber, #5198) [Link]

On sysvinit a tool like fleet would have to do all of its own service management, it would have to a parent of all the processes, manage cgroups, etc., in effect it would have to be systemd itself.

Etcd and fleet

Posted Nov 2, 2014 1:07 UTC (Sun) by philipsbd (subscriber, #33789) [Link]

I want to clarify that CoreOS uses the same build system as Gentoo (portage) but a user of CoreOS will not know this. The CoreOS update mechanism is completely different[1], there is no emerge package manager on board and we ship very few user space tools relying on containers instead.

Please give it a shot. It is a quite different system than Gentoo. In fact the ChromeOS team basis their build system on Gentoo's portage too, but you would never know it.

[1] https://coreos.com/using-coreos/updates/