5 ms·

But Podman is not the same thing at all. Oh well. I always liked rkt, mostly as a sane alternative to Docker’s client/server and security model. What’s the bes

But Podman is not the same thing at all. Oh well. I always liked rkt, mostly as a sane alternative to Docker’s client/server and security model. What’s the best alternative nowadays ?

plapetomain 7y ago
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.
  - CameronNemo 7y ago
    Void Linux, Gentoo, and Arch Linux package LXD without Snap. Perhaps other distros too.
deleted 7y ago
[deleted]
zapita 7y ago
The most robust alternatives are containerd and lxd. - containerd was pun out of the Docker engine to address community criticism. Pretty much every reason for creating rkt in the first place, has been addressed by containerd. - lxd is very similar to containerd, but evolved out of the lxc userland tool. There is also Podman and Cri-o, but I would not recommend those. Unlike containerd and lxd, they were not created to solve an actual user problem, but to advance the interests of some vendors to the detriment of others.
- pepemon 7y ago
  > Unlike containerd and lxd, they were not created to solve an actual user problem, but to advance the interests of some vendors to the detriment of others. Where can I read more about that?
  - bdutta 7y ago
    'Between the lines'

But Podman is not the same thing at all. Oh well. I always liked rkt, mostly as a sane alternative to Docker’s client/server and security model. What’s the best alternative nowadays ?

plapetomain 7y ago

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.
- CameronNemo 7y ago
  Void Linux, Gentoo, and Arch Linux package LXD without Snap. Perhaps other distros too.

deleted 7y ago

[deleted]

zapita 7y ago

The most robust alternatives are containerd and lxd. - containerd was pun out of the Docker engine to address community criticism. Pretty much every reason for creating rkt in the first place, has been addressed by containerd. - lxd is very similar to containerd, but evolved out of the lxc userland tool. There is also Podman and Cri-o, but I would not recommend those. Unlike containerd and lxd, they were not created to solve an actual user problem, but to advance the interests of some vendors to the detriment of others.

pepemon 7y ago
> Unlike containerd and lxd, they were not created to solve an actual user problem, but to advance the interests of some vendors to the detriment of others. Where can I read more about that?
- bdutta 7y ago
  'Between the lines'