I recently ran into them and honestly they seem unnecessarily complicated compared to using Podman and OCI images.
On Running systemd-nspawn Containers (2022)
51–59 of 59 posts
Re: On Running systemd-nspawn Containers (2022)
#52Earlier quoted context omitted.
I was thinking similarly. All of those steps to circumvent the OCI image infrastructure just to use systemd…
OCI is for running prepackaged software in black boxes from the internet, where you have no interest or ownership of the container internals. 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"…
I think you’re conflating packaging and runtime. OCI images are a packaging format while systemd-nspawn is a runtime. Runtimes and package formats are orthogonal.
> systemd-nspawn is for running your own containers, with a VM-like usage pattern (ie not immutable)
Containers aren’t immutable (OCI or otherwise). Again, I think you’re conflating images (the package formats are orthogonal) with their runtime instantiation, the container. OCI images like VM images are immutable, but containers and VMs are mutable.
My main objection to systemd-nspawn (at least as described in the article) is that it lacks a complementary package manager (or rather, that there’s no remotely convenient way to run software packages with it) and so you have to create your containers with manual changes and dodgy bash scripts. Regardless of what runtime you use, that seems like a not-very-maintainable way to manage software.
Re: On Running systemd-nspawn Containers (2022)
#53Earlier quoted context omitted.
OCI is for running prepackaged software in black boxes from the internet, where you have no interest or ownership of the container internals. 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"…
This distinction is a more useful one that the article made. I love dockerfiles and immutability, but there are good cases for mutable containers, too.
Containers already are mutable on all popular runtimes. “Immutability” comes from destroying and recreating them from their image, but there’s nothing forcing you to delete/recreate them, and indeed that’s not even the default behavior.
Re: On Running systemd-nspawn Containers (2022)
#54Earlier quoted context omitted.
It looks like systemd-nspawn is gaining rootless support, see https://github.com/systemd/systemd/issues/30239 Until then, I'm not sure if there is anything lightweight. If you don't need lightweight, there is Podman.
Podman requires one time root for installation though. I am on a completely rootless client at one of my servers.
Nope, you can compile/download and run it completely from unprivileged userspace.
Re: On Running systemd-nspawn Containers (2022)
#55On an unrelated note, is there a way to share some negative feedback on systemd projects without incurring significant hit to karma?
Do novel issues get a negative reaction? Retreading old grievances is pointless, but I think if you have a reasonable new gripe (that's not dae hate systemd like me?)you would be just fine.
Thing is, old grievances keep recurring here and there in systemd projects without being resolved. But I agree, wining for ten years is futile.
Re: On Running systemd-nspawn Containers (2022)
#56Earlier quoted context omitted.
Most systemd-projects have a name which immediately shouts out what it does, so you can easily tell if it is relevant for your needs or not. 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.
How so? nspawn means spawn a process in a new namespace, which is... exactly what it does. The problem isn't with systemd-nspawn, the problem is with containers, because the vast majority of devs have no idea that containers are just scripts to set up Linux namespaces.
> because the vast majority of devs have no idea that containers are just scripts to set up Linux namespaces.
That’s IMO framing things a bit backwards.
That’s how containers are implemented… today. on Linux. On Windows it’s completely different. On MacOS it’s completely different again.
And what makes you think «namespaces» are a term unique to containers? It’s used throughout tech for a million other platforms too.
Containers however is a well defined concept, regardless of how they are implemented today, and on one platform only.
systemd would probably see more use of their container-platform if they put «container» in the name, that much seems obvious to me.
Re: On Running systemd-nspawn Containers (2022)
#57Nspawn would be perfect if it exposed the full suite of service file security and resource control features. Due to their absence, I've been exploding containers into directories and writing my own service units to manage the pseudocontainers.
Re: On Running systemd-nspawn Containers (2022)
#58There are lot of ridiculous things in systemd (I'll avoid mentioning specific things to avoid a flame war), but auto containerization of services is by far the most useful thing they've ever come out with. It's a far easier workflow than docker or anything else and is built in "for free"
I agree for the most part, but would love to see more of the security and resource control features from service units, as well as some better tooling around image management / importing from existing registries. Hopefully this will come in the not too distant future.
Re: On Running systemd-nspawn Containers (2022)
#59Earlier quoted context omitted.
Linux user namespaces can be used to create containers without having root access, see ex. https://unix.stackexchange.com/questions/66084/simulate-chro... There's also https://github.com/termux/proot-distro which may or may not count as containers depending on how you define the word but I think it does count
you can't detach your username from a process, nor the network ns... etc, etc, etc. yeah you can do some smaller fakechroot and maybe some bind mounts... if you call that a "container" good for you.
> you can't detach your username from a process, nor the network ns... etc, etc, etc.
Sure looks like it works?
$ unshare -i -n -p -u -T -r -f
# ls
# id
gid=0(root) groups=0(root),65534(nogroup)
# ip -br a
lo DOWN
Why are you being condescending about what constitutes a container?