21–30 of 59 posts
> Unfortunately, though, most developers don’t even know that there are options outside of Docker, or that they’re not as “convenient”. > Hopefully, this article has disabused some of that notion. If that was the goal, it seems terribly complicated when compared with podman.
On an unrelated note, is there a way to share some negative feedback on systemd projects without incurring significant hit to karma?
I used nspawn to get a system running in the most ridiculous way. A debian aarch64 vm on kvm starting a systemd-nspawn for an unpacked raspberry pi 3 iso. It works way too well judging by how ridiculous it was. Still saved me a few days instead of setting things up myself. I actually liked how easy it is to spin up nspawn as a systemd service [Unit] Description=Raspberry Image Machine After=multi-user.target [Service…
hmm this is very interesting. I am wondering though? Is there something like systemd-nspawn that doesn't require root?
The way it integrates with systemd, both inside and outside the container makes it a no-brainer for app-isolation when the app in question is a bit too complex for just being a service-unit in itself, and you don't want to lose observability by hiding everything behind some obscure docker wall.
The way everything integrates into systemctl and you can get aggregated stats for your entire machine and all its sub-containers... Amazingly nice.
I just can't imagine any better way of managing containers on a Linux system than this.
Only thing I would complain about is the name. They really could have come up with something a bit more catchy or self-descriptive. This is probably the only systemd type service which does not immediately shout out what its about, so most people are probably not even aware that systemd can manage containers for you.
> Unfortunately, though, most developers don’t even know that there are options outside of Docker, or that they’re not as “convenient”. > Hopefully, this article has disabused some of that notion. If that was the goal, it seems terribly complicated when compared with podman.
I was thinking similarly. All of those steps to circumvent the OCI image infrastructure just to use systemd…
Most of my containers are not like that. Well, actually none are.
systemd-nspawn is for running your own containers, with a VM-like usage pattern (ie not immutable), deployed as part of your overall systemd based infrastructure for when the thing you need to manage is "too big" to be deployed as its own systemd-service unit, but you still want to be able "to systemd" it.
This fits my use-case perfectly.
This is very interesting! I only heard about systemd-nspawn last night.
systemd-nspawn is probably the only project without such a name, so most people don't know about it, nor what it does, and therefore never looks any more into it.
And that's a shame really, because it's fantastic technology.
Does breaking out of the container give you root?
You can run unprivileged containers, and in that case, no.
> Unfortunately, though, most developers don’t even know that there are options outside of Docker, or that they’re not as “convenient”. > Hopefully, this article has disabused some of that notion. If that was the goal, it seems terribly complicated when compared with podman.
Author should consider running it inside Docker for more convenient setup.