[HN Gopher] On Running systemd-nspawn Containers (2022)
___________________________________________________________________
On Running systemd-nspawn Containers (2022)
Author : cautious-fly
Score : 99 points
Date : 2025-02-21 08:00 UTC (15 hours ago)
(HTM) web link (benjamintoll.com)
(TXT) w3m dump (benjamintoll.com)
| nesarkvechnep wrote:
| systemd-nspawn is great! It's well integrated with the init
| system, works as expected.
| letters90 wrote:
| 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]
| Type=simple User=root
| ExecStart=/usr/bin/systemd-nspawn -D /mnt/ /sbin/init
| [Install] WantedBy=multi-user.target
| Imustaskforhelp wrote:
| hmm this is very interesting.
|
| I am wondering though? Is there something like systemd-nspawn
| that doesn't require root?
| derobert wrote:
| 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.
| Imustaskforhelp wrote:
| Podman requires one time root for installation though.
|
| I am on a completely rootless client at one of my servers.
| 1oooqooq wrote:
| all containers require root.
|
| 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.
| Imustaskforhelp wrote:
| you can theoretically run a virtual machine like libriscv5
| which doesn't require root. or qemu doesn't require root as
| well. But qemu is blocked for my usecase. There is flatpak
| theoretically as well
|
| There is podman but it requires one time root.
| yjftsjthsd-h wrote:
| 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
| vlowrian wrote:
| If file system level isolation is enough for you, take a loot
| at schroot (https://linux.die.net/man/1/schroot) which allows
| root-less chroot. You can use something like debootstrap to
| get a complete userland into a user controlled directory and
| use schroot to chroot into it without root level access.
| Imustaskforhelp wrote:
| this is crazy , trying this out right now.
|
| But is there a way to also run OCI compatible directly on
| this as well?
| mst wrote:
| You could use docker export to sluro the container
| contents (see article for example)
| Imustaskforhelp wrote:
| EDIT: it seems that for creating a chroot you still require
| root.
|
| 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
| ttyprintk wrote:
| Fakeroot is good for the debootstrap step, and then
| schroot runs unprivileged.
| igor47 wrote:
| fakeroot has nothing to do with qemu -- it simply uses LD
| preload to make commands think they're uid 0
| i_v wrote:
| I used to use qemu-user-static to run ARM Linux distros like
| Buildroot, Yocto, and Raspbian on x88_64. It worked
| surprisingly well! Outside of some minor bugs here and there,
| it was perfect for local development, emulating an embedded
| system I was working on.
| vaylian wrote:
| You might want to look into .nspawn files instead. Then you can
| also manage your nspawn-containers with the machinectl command.
|
| See 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.
| egorfine wrote:
| On an unrelated note, is there a way to share some negative
| feedback on systemd projects without incurring significant hit to
| karma?
| abenga wrote:
| 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.
| liveoneggs wrote:
| systemd still hungry:
| https://www.youtube.com/watch?v=bdmv2FQRHWg
|
| it's still eating..
| trurl42 wrote:
| > 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.
| throwaway894345 wrote:
| I was thinking similarly. All of those steps to circumvent the
| OCI image infrastructure just to use systemd...
| josteink wrote:
| 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" 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.
| fburnaby wrote:
| 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.
| moondev wrote:
| Author should consider running it inside Docker for more
| convenient setup.
| exceptione wrote:
| Never. If he wanted to go the containers route, Podman is
| there. There is no reason to use Docker anymore. (Only a
| satellite tool like docker-compose is not 1-1 compatible with
| podman-compose, but podman has other ways to orchestrate with
| systemd as part of podman vision for orchestrating.)
| proxysna wrote:
| Used nomad in my homelab to run nspawn containers with nspawn
| driver[1]
|
| Surprisingly simple and low footprint solution and genuinely
| pleasant to work with, since it is very similiar to managing a
| Systemd service.
|
| [1]https://github.com/JanMa/nomad-driver-nspawn
| JanMa wrote:
| Happy to hear you like the project :-)
| houzi wrote:
| Does breaking out of the container give you root?
| kennysoona wrote:
| I would think so, that would seem in line with systemd's
| architectural design decisions.
| 1oooqooq wrote:
| that means terminating the process, so good luck with that.
| josteink wrote:
| > Does breaking out of the container give you root?
|
| You can run unprivileged containers, and in that case, no.
| romaniitedomum wrote:
| Redhat's Leapp, for upgrading between major releases of RHEL,
| uses systemd-nspawn to create a container where it can test
| installing the packages without interfering with the running OS.
| kragen wrote:
| This is very interesting! I only heard about systemd-nspawn last
| night.
| josteink wrote:
| 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.
| baggy_trough wrote:
| I love nspawn; it's the best.
| josteink wrote:
| I've used lots of different container-types over the years to
| replace VMs with lightweight containers, but right now I'm
| running systemd-nspawn, and I really, really like it.
|
| 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.
| zoobab wrote:
| I discovered a similar project to run Docker containers as user
| without being root:
|
| https://github.com/mtseet/proot-docker
| orbisvicis wrote:
| I use nspawn but many of the helpers featured here are new, so I
| appreciate this article. I've only ever booted from directories
| rather than images, and wasn't aware that an image could mount
| its own partitions, even swap!
|
| 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?
| arminiusreturns wrote:
| It's really one of those little gems not very many people know
| about or use, but it seems from the responses that is changing.
|
| As Brendan Gregg said: "Containers are just processes, cgroups,
| and namespaces."
| robertlagrant wrote:
| Dockerfiles are just a really nice, standard way of specifying
| them, along with ports, networks and persistent storage.
| exabrial wrote:
| There 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"
___________________________________________________________________
(page generated 2025-02-21 23:02 UTC)