The most robust alternatives are containerd and lxd.
- containerd was pun out of the Docker engine to address community criticism. Pretty much every reason for creating rkt in the first place, has been addressed by containerd.
- lxd is very similar to containerd, but evolved out of the lxc userland tool.
There is also Podman and Cri-o, but I would not recommend those.
Unlike containerd and lxd, they were not created to solve an actual user problem, but to advance the interests of some vendors to the detriment of others.
> Unlike containerd and lxd, they were not created to solve an actual user problem, but to advance the interests of some vendors to the detriment of others.
Wow, I'd never heard of that. I've been using LXD for a while now and love it. From a quick glance at the docs, I'm not sure what benefits this has, apart from not requiring Snap. :D
If you're on a systemd distro, one advantage is you already have systemd-nspawn. Although, on debian boxes, it's split out into the systemd-container package.
Another advantage is it's somewhat integrated into the rest of systemd, having hooks into systemd-machined and the machinectl tooling, and an out-of-box instance unit file for systemd-nspawn@ where the instance name maps to the machine name. Meaning you can trivially start a container w/`systemctl start systemd-nspawn@that-contained-webservice` having nothing more than something useful in /var/lib/machines/that-contained-webservice/, or enable it to start at boot like any other systemd service i.e. `systemctl enable systemd-nspawn@that-contained-webservice`.
BTW, rkt was basically just a wrapper around systemd-nspawn, though the pluggable stages supported alternative containment mechanisms. The nspawn stage1 is what was originally shipped from the beginning.
It's less worrying if you view systemd as a mono-repo containing a collection of related projects maintained in one place, one of which is PID 1 - which really should have been renamed to systemd-initd.
The fact that Debian is able to isolate the nspawn-related bits into systemd-container without breaking everything speaks to the modular arrangement. Though the project may be a mono-repo under the systemd umbrella, it's not a monolithic beast antithetical to unix tradition as many like to claim.
It's odd how *bsd people don't get all up in arms about their core system pieces being in one repo, but the linux world loses their minds when sprawling messes get a little more consolidated even though it's for the better.
You say that the mono-repo contains a collection of "related" projects, but how many of those projects is it possible to install and use without installing and using at least one other project from the same repo?
It's possible to have a system with "ls" and without "grep", and vice versa, at least in principle. More importantly, it's possible to replace "ls" with a competing implementation, without having to change "grep". The systemd ecosystem is not structured in a way that lets alternatives be explored.
Systemd didn't take this over, nspawn is a pretty small wrapper around functionality that already existed. It turns out containers are not really that special compared to services, and most of the plumbing was already there in the service manager anyway.
> nspawn is a pretty small wrapper around functionality that already existed. It turns out containers are not really that special compared to services, and most of the plumbing was already there in the service manager anyway.
That's more than a little misleading. It's not like nspawn just calls into the service manager to get things done on its behalf via dbus or something like that.
If that were the case, rkt would only have worked on systemd hosts, since it used nspawn to setup its containers.
While it's true nspawn shares a bunch of code in common with the service manager, being in the same repository, it's a substantial program on its own and can function entirely independent of the service manager.
There was a time when nspawn actively required running on a systemd-booted host, but it was completely unnecessary and that check was removed while rkt was being developed. [0]
It's not some thin little ergonomic wrapper around existing service manager facilities.
This 'joke' has been repeated so many after every single release or even mention of systemd that it utterly baffles me how somebody could actually type it again.
systemd is a container runtime even without nspawn... you can control all of the namespaces and control groups via regular service units. Not sure if you can pivot_root too, but I would not be surprised.
- containerd was pun out of the Docker engine to address community criticism. Pretty much every reason for creating rkt in the first place, has been addressed by containerd.
- lxd is very similar to containerd, but evolved out of the lxc userland tool.
There is also Podman and Cri-o, but I would not recommend those.
Unlike containerd and lxd, they were not created to solve an actual user problem, but to advance the interests of some vendors to the detriment of others.