Yeah but elevated permissions may be needed from time to time anyway. Either on the client, the baremetal server or the container. Running everything as root is even for containers not recommended. Considering how popular these have become, it's a bit of an irony that systemd isn't available on the container without considerable detours.
Same - we now use systemd to sandbox our apps, set resource limits, hide the rest of the system, mount read-only FS, etc. Add a custom SELinux policy for your service, and you get a compelling alternative to containerization (at least at runtime).
I don't always run containerized applications, but when I do, I prefer them completely systemd-free, thank you.
Sometimes I wonder if systemd is actually a part of big plan of moving everyone to microservices and containers and maybe even unikernels — anything, just anything without this abomination.
I've liked it from the beginning (coming from upstart), but I think my one frustration is that you can't run systemd in an unprivileged container— and this is not simply an implementation gap, it's an intentional design choice:
You can argue that a process manager for an unprivileged container should be more like supervisor or systemd user services. However, it would be really convenient to be able to globally install unit files (say, using a deb package), and have them work whether it's bare metal, a VM, or a container.
I see, interesting.
I guess you are saying that systemd service wouldn't work because it's not available inside the container.
FWIW it's possible to run a rootless podman container with a working systemd inside the container. I've near tried running podman in podman using systemd though.
I'm not about to argue against systemd, it's great software, and it's in every distro right now for a reason. Understanding apt (+/- how to package for it), systemctl, and the options you've laid out in your unit file are not trivial, and I would argue that they are less trivial (or harder) than understanding what's happening with containers, especially if you're running rootless containers, and/or using a container tool like podman which does without the daemon.
--cpus 2 --memory 500M
is easier, and gets you the same results though they may not be as permanent or as well managed -- the management and external stuff is an orthogonal concern, and that's not the situation I was addressing. The original point was insinuating that throwing up a binary and getting it to run. your filesystem is also not available to the container by default, and in this way docker sort of fails closed. If you're running a rootless container, the story is even better.
One thing you have not covered is filesystem isolation, which docker also does very easily. There is a lot to configure on the systemd side[0] and the parts that are overlapping are just easier to configure and run with docker. Systemd is the better tool to build repeatable installs for pet processes, but again, there is a lot of knowledge underneath that is related. People to this day still complain that systemd does too much (I personally like it a lot, and it's great to have everything in one place).
[EDIT] Just to make myself clear, systemd is an amazing tool -- I like it, I run it, I'm not smart enough to administer a more complicated setup -- but docker is easier, for a large part of the small subset of systemd's capabilities that docker covers.
If you use systemd, you can use standard packages from your distro to run up services inside a container. That's basically the only reason I considered it.
Even in systemd, there is enough sandboxing function, so I use it.
If we need to get away from version dependencies. I think we'll consider containers as well.
systemd is far superior to anything else out there. It matured at roughly the same time as docker.
However it doesn't support being the CMD in a Dockerfile. Which is why it's not very common in software deployment scenarios in the post-container world.
For older deployments, it may not be worth switching to systemd because the base OS may not be compatible.
So it's kind of a catch-22.
If you are on baremetal, systemd is much preferable to run it/supervisord
Sure but what ws their recommended way instead of putting systemd in the image, just use supervisord. Not even comparable.
Anyway , the past is the past. Docker were clearly wrong in their decision to put off systemd inside containers, and was most probably for political reasons because it was very very requested feature.
What about raw systemd? It can do resource control, service monitoring and restart and seems pretty lightweight compared to Docker. Fewer ways to footgun with data being erased, no separate shells or finding a tool you need isn't available inside the container.
One thing I realized is that, surprisingly, systemd is not so relevant for servers, mainly because abusing docker is better in many cases. Systemd shines with desktops, that needs to dynamically start/stop a lot of services.
Yes, I don't understand why systemd doesn't support it sudo-less. It's even designed to run units configured by unprivileged users, but those can't access sandboxing features at all.
reply