Container Managers and ContainerD

Container Managers

I will call Podman a container manager - in a same way, that Docker is a container manager. Let’s define what container manager is.

In short, container manager is a complete solution to run containers, including the network management for these containers, support for persistent volumes, some observability tools as well as any other features for the full lifecycle of the container.

It’s hard to build a fixed list of what container manager is supposed to do, because there is no official definition. We will have to derive the approximate list based on our expectations and experience of using the existing tools. Let’s give it a try:

Create, run, stop, delete containers;

Manage network for containers, including shared network for multiple containers;

Manage persistence for containers, creating volumes that survive container restarts;

Providing logs and metrics for containers, as well as tools to inspect those logs and metrics;

Having some extra declarative way to define complete multi-container environment (think docker compose);

This list should probably cover day to day usage of a container management tool. The most popular container manager is, of course, Docker. We will look at the two alternative options: first, we will take a look at the Podman, as a container manager for local development, and then, we will examine cri-o - a container manager specifically for Kubernetes.

ContainerD

It would not be fair to omit containerd from the discussion about containers.

Containerd is not a container manager - in most of the situations, you never use it directly, as its hidden below some of the container managers. If you look at the Docker, for example, it’s using containerd between itself and runc. Another example is AWS ECS, which removed the Docker from it’s platform and instead uses containerd directly.

Confusingly, ContainerD website names it a container runtime, but the real container runtime there is runc. I would rather name ContainerD a container engine, but at this point container vocabularly becomes really messy.

Unlike runc, which is always used as a CLI, ContainerD is supposed to be used inside the source code of higher level tools - there is an SDK to connect to ContainerD daemon.

There is also a nerdctl tool, that you can use to talk to containerd directly to play around with the different features of it.

ContainerD is perfect if you plan to implement your own container manager, but it’s not entirely useful for the end user. It is important to be aware of its existence, especially if you hit a tricky bug and try to go through all the layers involved in running the container. You also should keep in mind that the majority of Docker features in regard to running containers are actually coming from ContainerD and not from Docker - as it’s always happened in our industry, we have higher level tools on top of lower level tools, on top of even lower level tools. Docker happens to be on the highest level

Now, finally, let’s try some container managers.