Hacker News new | ask | show | jobs
by c0restraint 2318 days ago
It is? The GitHub project page does not indicate that: https://github.com/rkt/rkt/
6 comments

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.
It's really dead. rkt never got much adoption and now Red Hat is promoting Podman instead.
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 ?

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.

> 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?

'Between the lines'
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
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.

Won’t be long until we do systemd ls...

I jest but systemd really is taking over a lot of functionality

Void Linux, Gentoo, and Arch Linux package LXD without Snap. Perhaps other distros too.
Podman is just a "control panel" for CRI-O.
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://web.archive.org/web/20200205190817/https://www.cncf....)

It is 100% we're finishing our migration away from it right now. Never getting kubernetes support killed it.
Last release was 2 years ago. It's either dead or feature complete and bug free.
Seems it’s at least trending towards dead. Hashicorp Nomad recently deprecated the rkt driver for lack of adoption.
As noted elsewhere in the thread: indeed rkt is dead.

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.