Is there an eli5 or similar on the differences between podman / docker / rancher / others?
Feels unexplained (at least for me), how do I know which to choose when and what are the trade offs?
I recently went deeper on Rancher Desktop and it’s use of containerd vs dockerd backends and it is totally not obvious what you lose if not using dockerd and how you might fill the gaps. Feels like because docker established the space and put a bunch of related components together (cli, image building, image storing and container running) and other projects make difference choices it can be quite confusing to compare them.
Podman is for running containers on a single host. It's exactly like docker with a few additional features (like the ability to run rootless containers and run containers in something like a Kubernetes pod). Podman was developed by Red Hat to replace docker, the cli, because Docker, the company, didn't play very nice with the open source community.
Rancher is a Kubernetes implementation that can run containers across multiple hosts. Rancher is more comparable to something like Red Hat OpenShift or Hashicorp Nomad than docker.
Why should they? I work for Red Hat, help and contribute to podman but they like to remain as 'independent' as possible. We collaborate but the preference is that Podman is an upstream/community project first.
Pretty sure they will once it's a bit more stable. They have presented at most of the kubecons for several years but it's always cautioned they will potentially break stuff.
Kubernetes requires a tool which implements the Container Runtime Interface (CRI), a standardized API for starting & managing containers. This is from 2015-2016[1]. The CRI interface is defined by & owned by Kubernetes, and there's a lot of implementations: runc, crun, youki, dockershim and likely more.
For a while Kubernetes has included something called the "dockershim", it's own implementation of a CRI interface that, under the hood, calls Docker or Podman, so Kubernetes "pods" run in Docker/Podman. There's also tools like Kind[3] ("kubernetes in docker") that go further- not just hosting Kubernetes worker containers in Docker, but hosting the main kubernetes daemons also in Docker.
Kubernetes deprecated Dockershim, formally in December 2020, but is just throwing the switch now in the upcoming 1.24, expected mid-April[4]. A company Mirantis has pledged to take over support of Dockershim[5], and is calling the new effort "cri-dockerd"[6]. This should allow Kubernetes workers to continue to run via Docker or Podman.
Kind is unaffected, since it runs the main Kubernetes controllers in Docker, which then launch their own opencontainerd (one off the main CRI implementations) inside that Docker container, nested like, so no dockership/cri-dockerd is needed).
Worth re-noting that Podman includes tools to try to run Kubernetes pods directly, without running the rest of Kubernetes.
From a security perspective, a daemon is a nightmare. It makes so much more sense to inherit the permissions from the process it’s launched from, and as such I’m a big proponent of podman (or rkt in a distant past).
It depends on what you’re looking for. Most people use containerd as their backend to Kubernetes. Docker itself uses it. Podman uses a different engine. That may matter to some folks.
There are also a bunch of tools that talk directly to the docker socket.
I think the most surprising coming from docker was that containerd can’t build images, just run them, thus nerdctl and things plus other userspace ways of building images too.. so many options..
Totally makes sense when you understand more but initial is surprising.
1. It can form up k8s-style pods for deploying tightly-coupled containers.
2. It can understand k8s YAML for deployment (although obviously it doesn't support everything k8s does), which makes it easier to do deployment config that will work locally with podman and then in a k8s deployment.
Docker the CLI tool is made of a bunch of opensource components that Docker the company put under an opensource organization called moby: https://mobyproject.org/projects/
Poke around the different moby components like runc, containerd, buildkit, etc. and you'll start to see how they all form part of docker the CLI tool. For example runc runs a container image, and containerd is a service that can run and manage multiple containers at once (each using runc to run). Buildkit is a tool for building container images. All of these tools assume you're on a linux host, but there are tools like linuxkit, hyperkit to make linux VMs for mac and windows hosts that can then run all the other tools.
Tools like podman, rancher desktop, docker, etc. all more or less use those components and compose them in different ways or with different tweaks to support their view of a container workflow.
A bit part of it are the companies behind it. Docker is the original from the Docker company. Podman is an open source clone pushed by RH that has the advantage of not needing root access, but some apps that expect genuine Docker fail. Rancher is a simple Kubernetes implementation. LXC for a similar but different world.
Feels unexplained (at least for me), how do I know which to choose when and what are the trade offs?
I recently went deeper on Rancher Desktop and it’s use of containerd vs dockerd backends and it is totally not obvious what you lose if not using dockerd and how you might fill the gaps. Feels like because docker established the space and put a bunch of related components together (cli, image building, image storing and container running) and other projects make difference choices it can be quite confusing to compare them.