On Running systemd-nspawn Containers (2022)(benjamintoll.com) |
On Running systemd-nspawn Containers (2022)(benjamintoll.com) |
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]
Type=simple
User=root
ExecStart=/usr/bin/systemd-nspawn -D /mnt/ /sbin/init
[Install]
WantedBy=multi-user.targetSee man 5 systemd.nspawn
And many command like systemctl and journalctl accept the -M parameter, which allows you to query systemd units inside your nspawn-containers from the host.
edit: The article actually explains all of these things in more detail.
I am wondering though? Is there something like systemd-nspawn that doesn't require root?
Until then, I'm not sure if there is anything lightweight. If you don't need lightweight, there is Podman.
docker and the rootless nonsense is just root daemons and suid.
...would never have believed marketing lies would reach linux tools if anyone told me this before 2018.
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.
> Hopefully, this article has disabused some of that notion.
If that was the goal, it seems terribly complicated when compared with podman.
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.
Surprisingly simple and low footprint solution and genuinely pleasant to work with, since it is very similiar to managing a Systemd service.
Also I'm a little unclear on the security implications of "--private-users=id". Yes the user IDs are the same, but it is technically running in a separate user namespace. In terms of security is this mode equivalent to privileged containers, or is it safer?
As Brendan Gregg said: "Containers are just processes, cgroups, and namespaces."
it's still eating..
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.
Add sd-tmpfiles to the list IMO. While it still create and manages temporary files its more managing almost any type of system file. From creating them to managing their permissions or making symlinks when needed.
I am a strong advocator of renaming it systemd-sysfiles to match the systemd-sysusers which is somewhat related (e.g. tmpfiles using users created from sysusers). But it probably won't happen for a while if at all due to backwards compat.
You can run unprivileged containers, and in that case, no.
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.
I am on a completely rootless client at one of my servers.
https://0pointer.net/blog/running-an-container-off-the-host-...
I'm not sure how easy that is to customize in Podman.
> 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.
But is there a way to also run OCI compatible directly on this as well?
I don't have root on that system and so I can't create a chroot , there is fakeroot but it doesn't work since it uses qemu on that locked system.
Are there any other alternatives
You actually don't as long as you have user namespaces.
One thing I am working on I use chroot (rather unshare --root=) to minimally sandbox a subprocess. At the beginning of the script I have this little snippet:
if [ "$(id --user)" -ne 0 ]; then
exec unshare --map-root-user --mount -- "$0" "$@"
fi
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
yeah you can do some smaller fakechroot and maybe some bind mounts... if you call that a "container" good for you.
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?
There is podman but it requires one time root.