25 ms·

It is? The GitHub project page does not indicate that: https://github.com/rkt/rkt/ https://github.com/rkt/rkt/

by c0restraint 7y ago

wmf 7y ago
It's really dead. rkt never got much adoption and now Red Hat is promoting Podman instead.
- stingraycharles 7y ago
  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.
        7y ago
      - 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'
- pepemon 7y ago
  Podman is just a "control panel" for CRI-O.
kitotik 7y ago
Seems it’s at least trending towards dead. Hashicorp Nomad recently deprecated the rkt driver for lack of adoption.
- schmichael 7y ago
  As noted elsewhere in the thread: indeed rkt is dead. https://github.com/pascomnet/nomad-driver-podman https://github.com/pascomnet/nomad-driver-podman is a WIP Podman driver. We're discussing creating our own containerd-based driver, but there's no plans yet.
chipsa 7y ago
Last release was 2 years ago. It's either dead or feature complete and bug free.
thebeardisred 7y ago
It was donated to the CNCF years ago. As of today, it's the only "Archived" CNCF project: https://www.cncf.io/archived-projects/ https://www.cncf.io/archived-projects/ (https://web.archive.org/web/20200205190817/https://www.cncf.io/archived-projects/ https://web.archive.org/web/20200205190817/https://www.cncf....)
fcantournet 7y ago
It is 100% we're finishing our migration away from it right now. Never getting kubernetes support killed it.
blixtra 7y ago
A former rkt dev here. rkt was archived by the CNCF with our blessings. Was just speaking to other rkt folks at FOSDEM about archiving the project on GH as well, which should happen shortly. We will also announce deprecation of rkt in Flatcar Container Linux very soon. rkt really changed the container runtime landscape for the best and we're happy to see that other projects improved because if it and that the space was able to consolidate a bit.
- deleted 7y ago
  [deleted]

It is? The GitHub project page does not indicate that: https://github.com/rkt/rkt/ https://github.com/rkt/rkt/

wmf 7y ago

It's really dead. rkt never got much adoption and now Red Hat is promoting Podman instead.

stingraycharles 7y ago
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.
        7y ago
    - 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'
pepemon 7y ago
Podman is just a "control panel" for CRI-O.

kitotik 7y ago

Seems it’s at least trending towards dead. Hashicorp Nomad recently deprecated the rkt driver for lack of adoption.

schmichael 7y ago
As noted elsewhere in the thread: indeed rkt is dead. https://github.com/pascomnet/nomad-driver-podman https://github.com/pascomnet/nomad-driver-podman is a WIP Podman driver. We're discussing creating our own containerd-based driver, but there's no plans yet.

chipsa 7y ago

Last release was 2 years ago. It's either dead or feature complete and bug free.

thebeardisred 7y ago

It was donated to the CNCF years ago. As of today, it's the only "Archived" CNCF project: https://www.cncf.io/archived-projects/ https://www.cncf.io/archived-projects/ (https://web.archive.org/web/20200205190817/https://www.cncf.io/archived-projects/ https://web.archive.org/web/20200205190817/https://www.cncf....)

fcantournet 7y ago

It is 100% we're finishing our migration away from it right now. Never getting kubernetes support killed it.

blixtra 7y ago

A former rkt dev here. rkt was archived by the CNCF with our blessings. Was just speaking to other rkt folks at FOSDEM about archiving the project on GH as well, which should happen shortly. We will also announce deprecation of rkt in Flatcar Container Linux very soon. rkt really changed the container runtime landscape for the best and we're happy to see that other projects improved because if it and that the space was able to consolidate a bit.

deleted 7y ago
[deleted]