7 ms·

systemd nspawn

pkulak 7y ago
Wow, I'd never heard of that. I've been using LXD for a while now and love it. From a quick glance at the docs, I'm not sure what benefits this has, apart from not requiring Snap. :D
- newnewpdro 7y ago
  If you're on a systemd distro, one advantage is you already have systemd-nspawn. Although, on debian boxes, it's split out into the systemd-container package. Another advantage is it's somewhat integrated into the rest of systemd, having hooks into systemd-machined and the machinectl tooling, and an out-of-box instance unit file for systemd-nspawn@ where the instance name maps to the machine name. Meaning you can trivially start a container w/`systemctl start systemd-nspawn@that-contained-webservice` having nothing more than something useful in /var/lib/machines/that-contained-webservice/, or enable it to start at boot like any other systemd service i.e. `systemctl enable systemd-nspawn@that-contained-webservice`. BTW, rkt was basically just a wrapper around systemd-nspawn, though the pluggable stages supported alternative containment mechanisms. The nspawn stage1 is what was originally shipped from the beginning.
  - gigatexal 7y ago
    Won’t be long until we do systemd ls... I jest but systemd really is taking over a lot of functionality
    - newnewpdro 7y ago
      It's less worrying if you view systemd as a mono-repo containing a collection of related projects maintained in one place, one of which is PID 1 - which really should have been renamed to systemd-initd. The fact that Debian is able to isolate the nspawn-related bits into systemd-container without breaking everything speaks to the modular arrangement. Though the project may be a mono-repo under the systemd umbrella, it's not a monolithic beast antithetical to unix tradition as many like to claim. It's odd how *bsd people don't get all up in arms about their core system pieces being in one repo, but the linux world loses their minds when sprawling messes get a little more consolidated even though it's for the better.
      - dane-pgp 7y ago
        You say that the mono-repo contains a collection of "related" projects, but how many of those projects is it possible to install and use without installing and using at least one other project from the same repo? It's possible to have a system with "ls" and without "grep", and vice versa, at least in principle. More importantly, it's possible to replace "ls" with a competing implementation, without having to change "grep". The systemd ecosystem is not structured in a way that lets alternatives be explored.
        cycloptic 7y ago
        >but how many of those projects is it possible to install and use without installing and using at least one other project from the same repo? Nearly all of them. Have you actually tried to do this? The only thing I can think of off the top of my head that won't really work separately is journald.
        marcan_42 7y ago
        People actually doing this (i.e. trying to use systemd components on a non-systemd system) end up forking the critical bits and pieces, because trying to build and use them directly from upstream doesn't work well. See: https://github.com/elogind/elogind https://github.com/elogind/elogind https://github.com/gentoo/eudev https://github.com/gentoo/eudev So yes, systemd is a mono-repo containing a bunch of loosely-coupled projects, but they are still coupled too tightly to sanely distribute and use separately without a fork.
        newnewpdro 7y ago
        > but they are still coupled too tightly to sanely distribute and use separately without a fork. That's not true, forking becomes necessary when what you actually want is a different implementation fulfilling the same dbus interface. If you just wanted intact systemd-logind and none of the rest, you could fairly trivially build systemd from source and package just logind and libsystemd and get on with your life. Maybe you'd have to carry some patches to inhibit some things like cgroups meddling in the systemd way, but that's no different than what say Debian does for practically every upstream tarball it packages. Those projects have in a very real sense forked the components for the purposes of modifying their implementations in ways too substantial for some small packaging-time patches to cover. I'd argue that it actually speaks to the modularity and organization of systemd's code that forking was a more attractive option for these folks than starting over with just the dbus interface in hand.
    - cycloptic 7y ago
      Systemd didn't take this over, nspawn is a pretty small wrapper around functionality that already existed. It turns out containers are not really that special compared to services, and most of the plumbing was already there in the service manager anyway.
      - newnewpdro 7y ago
        > nspawn is a pretty small wrapper around functionality that already existed. It turns out containers are not really that special compared to services, and most of the plumbing was already there in the service manager anyway. That's more than a little misleading. It's not like nspawn just calls into the service manager to get things done on its behalf via dbus or something like that. If that were the case, rkt would only have worked on systemd hosts, since it used nspawn to setup its containers. While it's true nspawn shares a bunch of code in common with the service manager, being in the same repository, it's a substantial program on its own and can function entirely independent of the service manager. There was a time when nspawn actively required running on a systemd-booted host, but it was completely unnecessary and that check was removed while rkt was being developed. [0] It's not some thin little ergonomic wrapper around existing service manager facilities. [0] https://github.com/systemd/systemd/commit/4f923a1984476de3441922ee5bf7102ebdd250ef https://github.com/systemd/systemd/commit/4f923a1984476de344...
        cycloptic 7y ago
        >It's not like nspawn just calls into the service manager to get things done on its behalf via dbus or something like that. Yes, it literally does? https://github.com/systemd/systemd/blob/master/src/nspawn/nspawn-register.c https://github.com/systemd/systemd/blob/master/src/nspawn/ns... Additionally there is a lot of shared functionality in libsystemd. Take a look at the rest of the code in nspawn and see how little it actually accomplishes.
        newnewpdro 7y ago
        > Yes, it literally does? https://github.com/systemd/systemd/blob/master/src/nspawn/nspawn-register.c https://github.com/systemd/systemd/blob/master/src/nspawn/ns... No, it literally doesn't. That's just registration with the service manager, and it's optional. Basically it's to make the service manager aware of nspawn's actions, when it's on a systemd host. I already pointed out they share a lot of code. The service manager process doesn't do squat on behalf of nspawn.
    - CameronNemo 7y ago
      systemd is a container runtime even without nspawn... you can control all of the namespaces and control groups via regular service units. Not sure if you can pivot_root too, but I would not be surprised.
    - nickik 7y ago
      This 'joke' has been repeated so many after every single release or even mention of systemd that it utterly baffles me how somebody could actually type it again.
- CameronNemo 7y ago
  Void Linux, Gentoo, and Arch Linux package LXD without Snap. Perhaps other distros too.

systemd nspawn

Wow, I'd never heard of that. I've been using LXD for a while now and love it. From a quick glance at the docs, I'm not sure what benefits this has, apart from not requiring Snap. :D

newnewpdro 7y ago
If you're on a systemd distro, one advantage is you already have systemd-nspawn. Although, on debian boxes, it's split out into the systemd-container package. Another advantage is it's somewhat integrated into the rest of systemd, having hooks into systemd-machined and the machinectl tooling, and an out-of-box instance unit file for systemd-nspawn@ where the instance name maps to the machine name. Meaning you can trivially start a container w/`systemctl start systemd-nspawn@that-contained-webservice` having nothing more than something useful in /var/lib/machines/that-contained-webservice/, or enable it to start at boot like any other systemd service i.e. `systemctl enable systemd-nspawn@that-contained-webservice`. BTW, rkt was basically just a wrapper around systemd-nspawn, though the pluggable stages supported alternative containment mechanisms. The nspawn stage1 is what was originally shipped from the beginning.
- gigatexal 7y ago
  Won’t be long until we do systemd ls... I jest but systemd really is taking over a lot of functionality
  - newnewpdro 7y ago
    It's less worrying if you view systemd as a mono-repo containing a collection of related projects maintained in one place, one of which is PID 1 - which really should have been renamed to systemd-initd. The fact that Debian is able to isolate the nspawn-related bits into systemd-container without breaking everything speaks to the modular arrangement. Though the project may be a mono-repo under the systemd umbrella, it's not a monolithic beast antithetical to unix tradition as many like to claim. It's odd how *bsd people don't get all up in arms about their core system pieces being in one repo, but the linux world loses their minds when sprawling messes get a little more consolidated even though it's for the better.
    - dane-pgp 7y ago
      You say that the mono-repo contains a collection of "related" projects, but how many of those projects is it possible to install and use without installing and using at least one other project from the same repo? It's possible to have a system with "ls" and without "grep", and vice versa, at least in principle. More importantly, it's possible to replace "ls" with a competing implementation, without having to change "grep". The systemd ecosystem is not structured in a way that lets alternatives be explored.
      - cycloptic 7y ago
        >but how many of those projects is it possible to install and use without installing and using at least one other project from the same repo? Nearly all of them. Have you actually tried to do this? The only thing I can think of off the top of my head that won't really work separately is journald.
        marcan_42 7y ago
        People actually doing this (i.e. trying to use systemd components on a non-systemd system) end up forking the critical bits and pieces, because trying to build and use them directly from upstream doesn't work well. See: https://github.com/elogind/elogind https://github.com/elogind/elogind https://github.com/gentoo/eudev https://github.com/gentoo/eudev So yes, systemd is a mono-repo containing a bunch of loosely-coupled projects, but they are still coupled too tightly to sanely distribute and use separately without a fork.
        newnewpdro 7y ago
        > but they are still coupled too tightly to sanely distribute and use separately without a fork. That's not true, forking becomes necessary when what you actually want is a different implementation fulfilling the same dbus interface. If you just wanted intact systemd-logind and none of the rest, you could fairly trivially build systemd from source and package just logind and libsystemd and get on with your life. Maybe you'd have to carry some patches to inhibit some things like cgroups meddling in the systemd way, but that's no different than what say Debian does for practically every upstream tarball it packages. Those projects have in a very real sense forked the components for the purposes of modifying their implementations in ways too substantial for some small packaging-time patches to cover. I'd argue that it actually speaks to the modularity and organization of systemd's code that forking was a more attractive option for these folks than starting over with just the dbus interface in hand.
  - cycloptic 7y ago
    Systemd didn't take this over, nspawn is a pretty small wrapper around functionality that already existed. It turns out containers are not really that special compared to services, and most of the plumbing was already there in the service manager anyway.
    - newnewpdro 7y ago
      > nspawn is a pretty small wrapper around functionality that already existed. It turns out containers are not really that special compared to services, and most of the plumbing was already there in the service manager anyway. That's more than a little misleading. It's not like nspawn just calls into the service manager to get things done on its behalf via dbus or something like that. If that were the case, rkt would only have worked on systemd hosts, since it used nspawn to setup its containers. While it's true nspawn shares a bunch of code in common with the service manager, being in the same repository, it's a substantial program on its own and can function entirely independent of the service manager. There was a time when nspawn actively required running on a systemd-booted host, but it was completely unnecessary and that check was removed while rkt was being developed. [0] It's not some thin little ergonomic wrapper around existing service manager facilities. [0] https://github.com/systemd/systemd/commit/4f923a1984476de3441922ee5bf7102ebdd250ef https://github.com/systemd/systemd/commit/4f923a1984476de344...
      - cycloptic 7y ago
        >It's not like nspawn just calls into the service manager to get things done on its behalf via dbus or something like that. Yes, it literally does? https://github.com/systemd/systemd/blob/master/src/nspawn/nspawn-register.c https://github.com/systemd/systemd/blob/master/src/nspawn/ns... Additionally there is a lot of shared functionality in libsystemd. Take a look at the rest of the code in nspawn and see how little it actually accomplishes.
        newnewpdro 7y ago
        > Yes, it literally does? https://github.com/systemd/systemd/blob/master/src/nspawn/nspawn-register.c https://github.com/systemd/systemd/blob/master/src/nspawn/ns... No, it literally doesn't. That's just registration with the service manager, and it's optional. Basically it's to make the service manager aware of nspawn's actions, when it's on a systemd host. I already pointed out they share a lot of code. The service manager process doesn't do squat on behalf of nspawn.
  - CameronNemo 7y ago
    systemd is a container runtime even without nspawn... you can control all of the namespaces and control groups via regular service units. Not sure if you can pivot_root too, but I would not be surprised.
  - nickik 7y ago
    This 'joke' has been repeated so many after every single release or even mention of systemd that it utterly baffles me how somebody could actually type it again.
CameronNemo 7y ago
Void Linux, Gentoo, and Arch Linux package LXD without Snap. Perhaps other distros too.