[bithavoc]

Nomad is good at running all sort of workloads, not just container workloads. Also there is a plugin[0] to run containers without docker so Nomad is headed in the right direction for scenarios where you only need a scheduler.

[0] https://github.com/Roblox/nomad-driver-containerd

[3np]

Nomad already has a first-party driver for podman, doesn't that do it?

[shishirm]

Author (https://github.com/Roblox/nomad-driver-containerd) here.

Not really, Podman and containerd are two different technologies, although both allow you to move away from Docker for various reasons (smaller CPU, memory footprint, better security etc). If you are invested into Red Hat container stack, podman makes more sense. However containerd is more universal.

K8s is already moving away from docker, and directly into containerd. Most recently they deprecated dockershim, and users now need to switch to containerd (since docker also uses containerd under the hood, and it doesn't make sense for the orchestration system to run a monolithic service like docker where it just need to launch the workloads)

Some reference links of k8s or PaaS build on top of k8s moving to containerd

- https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-...

- AWS Fargate: https://aws.amazon.com/blogs/containers/under-the-hood-farga...

- Azure kubernetes service (AKS): https://docs.microsoft.com/en-us/azure/aks/cluster-configura...

This driver is similar to what CRI-containerd is doing in kubernetes (if you are coming from the k8s world)

[3np]

Appreciate the thoughtful reply. So it does address the immediate issue of being able to run OCI containers without the intrusive docker daemon, but not in the same way (and as you say, less standardized/universal).

[shishirm]

yes, that's correct. With both the drivers (podman, containerd) you can run OCI containers without the need to run docker daemon.

IMO, or atleast when we were making that decision, a key factor that we considered: Since docker has been more ubiquitous as a technology and millions of users have already been running docker in their infrastructure (and containerd under the hood without even knowing that it exists), containerd has seen the test of time a lot more than e.g. podman.

Also to add, containerd as a system is very pluggable and flexible. You can swap out an entire subsystem and write (plug) your own with containerd. e.g. you can write your own custom snapshotter and use that if you don't want to go with the default. e.g. The firecracker-containerd project (https://github.com/firecracker-microvm/firecracker-container...) wrote their own devicemapper snapshotter. From my limited understanding of podman, I believe it's geared more towards security and making containers rootless, which was a pain point in docker initially, since everyone ran containers with root.

[shishirm]

One area, where containerd didn't had a first class support was CLI. the default containerd CLI "ctr" has a very naive implementation. The reason for that I believe is, containerd as a system was never meant to be consumed by humans, and was designed to be consumed by higher layers e.g. orchestration systems like nomad or k8s. However, with the deprecation of dockershim in k8s, and users moving to containerd, a new docker compatible CLI came out:

https://github.com/AkihiroSuda/nerdctl

If you just have containerd running on your system (with no docker daemon running), you can just install nerdctl and add

alias docker="nerdctl"

to your ~/.bashrc file.

Then you can just run any docker commands the way you used to with docker, and it will run those commands against the containerd API giving you the same CLI experience that you used to have with docker.

[3np]

That's really neat, thanks for the link :)