Why Containers With No Daemons?

Believe it or not, I had to check this whole story when I failed to find any trivial way to stop my crawlers from eating all of my CPU cycles. I had the intuition to containerize them, then let the container runtime make these uncontrollable gremlins behave: I would run the crawlers as containers, setting system usage limits for them upon creation.

But I was held back by the way Docker relied on heavy daemons to work back then. Remember, my crawlers are supposed to be tiny un-noticeable anti-virus like programs - this is why we were bothering with this CPU story in the first place - so having Docker tooling and daemons as prerequisites was not an option.

I then explored "docker-less" or "daemon-less" solutions, so I stumbled upon alternatives like podman which is a lib that runs your containers with no running servers, or buildah that can build your Dockerfiles under the same conditions - no daemons running. The prospect of these solutions was promising, but they could only run on Linux, and as we were writing desktop software, it had to run on Windows at least, so I ended up writing my own CPU limiting code.

But these {docker,daemon}-less solutions are essential nonetheless: You'll be most probably facing more places where you need to leave docker comfort and work with alternative container runtimes (I am looking to you Kubernetes administrators). So how easy is it to switch?

The Benefits of Standardization and Libpod

Docker, as a company, has made a great job making the Container what it is now, at the center of nearly every software engineering breakthrough we've seen in the last couple of years.

But they have contributed to an even more significant effort: the standardization of the Container landscape, through the Open Container Initiative - the OCI, along with other industry players.

Thanks to this standardization effort, it is possible for podman to rely on an OCI compliant Container Runtime to run and manage Containers on a Linux operating system. They're doing so under the form of a self-contained package libpod, thus providing us with a lightweight tool, with no servers to install at all, to run, monitor, stop, pull and tag our containers, just like you'd do with Docker. On their website, they say:

Podman specializes in all of the commands and functions that help you to maintain and modify OCI container images, such as pulling and tagging. It allows you to create, run, and maintain those containers and container images in a production environment.

Podman in action

You begin by installing podman. This will result in a binary that you'll use to create your Containers (on Linux. For Mac and Windows, it's another story). The installation instructions are here.

To run a Container, you just use the podman command to create one with a Docker (or any OCI Compliant) image:

podman run #... your classical options as you'd do in Docker

As in Docker, you can list the running Containers:

podman ps

Conclusion

Using podman, on a Linux machine, you can easily express your scripts in terms of Containers. There will be no unnecessary daemons haunting your space. libpod, along with other OCI Compliant Runtime engines, are becoming more commonplace in the Kubernetes landscape. So Kubernetes admins might want to skill up in these runtimes and understand the trade-offs they are making when choosing one runtime over another in terms of functionality, security, and performance.

Further Reding

This post is heavily inspired by the following excellent piece: Dockerless, part 1: Which tools to replace Docker with and why

You might also want to check these following canonical references:

• podman documentation
• libpod Github Repository
• Open Container Initiative
• A Practical Introduction to Container Terminology
• Building containerized applications

A mirror problem for daemonless Container Running is the daemonless container building. For this, you might want to check Buildah