>> The rkt container runtime is not included.
rkt is dead
rkt is dead
Oh well. I always liked rkt, mostly as a sane alternative to Docker’s client/server and security model. What’s the best alternative nowadays ?
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.
I jest but systemd really is taking over a lot of functionality
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.
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.
Nearly all of them. Have you actually tried to do this? The only thing I can think of off the top of my head that won't really work separately is journald.
See: https://github.com/elogind/elogind https://github.com/gentoo/eudev
So yes, systemd is a mono-repo containing a bunch of loosely-coupled projects, but they are still coupled too tightly to sanely distribute and use separately without a fork.
That's not true, forking becomes necessary when what you actually want is a different implementation fulfilling the same dbus interface.
If you just wanted intact systemd-logind and none of the rest, you could fairly trivially build systemd from source and package just logind and libsystemd and get on with your life. Maybe you'd have to carry some patches to inhibit some things like cgroups meddling in the systemd way, but that's no different than what say Debian does for practically every upstream tarball it packages.
Those projects have in a very real sense forked the components for the purposes of modifying their implementations in ways too substantial for some small packaging-time patches to cover.
I'd argue that it actually speaks to the modularity and organization of systemd's code that forking was a more attractive option for these folks than starting over with just the dbus interface in hand.
The difference is the utilities you mention interoperate at the level of bare UNIX pipes and execv/argv. Systemd components are largely integrated via dbus (UNIX domain sockets), as they're mostly services, daemons, which users don't generally interact with via execv/argv.
You're comparing apples and oranges here, and I'd like to note that GNU has already consolidated a lot of those CLI utilities into monorepos and I expect more consolidation like that to happen in the future as it's a natural evolution as the system stabilizes and active developers move on to other projects.
I think your argument would be more valid if systemd weren't establishing stable dbus interfaces, and instead were inventing all sorts of snowflake, constantly changing interfaces, but that simply isn't the case.
We already have examples of systemd components being forked and used independent of the project, to fulfill some of those interfaces without bringing in the entirety of systemd. [0] [1] I have mixed feelings about those efforts, but it at least demonstrates an ability to relatively trivially break off pieces you like and leave out the stuff you don't.
This didn't _used_ to be the case, but then I just looked it up, and… Yay, it actually is now! † I just want to say thanks (to the whole systemd team) for that!
† https://systemd.io/PORTABILITY_AND_STABILITY/ — the last time I checked was when the freedesktop.org page was still current, so it had been a while.
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.
[0] https://github.com/systemd/systemd/commit/4f923a1984476de344...
Yes, it literally does? https://github.com/systemd/systemd/blob/master/src/nspawn/ns...
Additionally there is a lot of shared functionality in libsystemd. Take a look at the rest of the code in nspawn and see how little it actually accomplishes.
No, it literally doesn't. That's just registration with the service manager, and it's optional. Basically it's to make the service manager aware of nspawn's actions, when it's on a systemd host.
I already pointed out they share a lot of code. The service manager process doesn't do squat on behalf of nspawn.
- 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.
Where can I read more about that?
https://github.com/pascomnet/nomad-driver-podman is a WIP Podman driver. We're discussing creating our own containerd-based driver, but there's no plans yet.
https://www.cncf.io/archived-projects/ (https://web.archive.org/web/20200205190817/https://www.cncf....)