Confused Debugging

Even if you can exclusively rely on Podman, Docker, or Snap, you will quickly realize in everyday life that containers make many things more complicated. For example, if you want a service running in the container to start automatically at system startup time, you need a systemd init file. However, this file needs to interact with the container management software instead of simply starting the respective service directly.

Speaking of container management, tales of admins desperately trying to find their output on the stdout of their running containers almost sound like urban legends. In Ceph, for example, the OSDs and MONs write their own logfiles, which you will find in /var/lib/ceph/osd/ on the host systems. However, they do not contain the messages directly from the services. If you need these, you can instead tap into the running container with docker logs -f (Figure 4).

Figure 4: If you want to see the error messages generated by containerized Ceph services on stdout, you need to dock directly with the container, instead of accessing a normal logfile.

In defense of containers, I have to admit, many of these difficulties can be configured, but in view of all these factors, the claim that containers work better, faster, more reliably, and more securely than packages out of the box is something I very much doubt.

If you also look at the way services running in containers are connected to the local network, more doubts raise their ugly heads. Because containers are designed out of the box not to be bound to the IP addresses of the host system, Docker and others use port forwarding as a ploy. The containers then open a virtual network on the host, to which the kernel forwards packets for the target IP. Conversely, then, debugging with tools like tcpdump is more complicated than in conventional environments.

Interim Conclusions

No matter how you spin it, containers do have their advantages, but they require the administrator to navigate a huge learning curve, while not solving certain problems as elegantly as can a combination of classic automation and package management. If you have a clear idea of the services you want to run, and on what systems, you will fare better and enjoy more stability from a combination of Ansible, configuration templates, and classic packages from the providers. Most importantly, you will have less complexity than Docker, Podman, and the other container solutions.

Kubernetes: Yes, but …

In the second and significantly shorter part of this article, I really need to mention Kubernetes, the software that has undoubtedly given the container hype triggered by Docker a massive boost. Admins love modern technology, and once a solution becomes popular, it attracts admins like moths to the flame, as was the case with Kubernetes. For years, it has been the talk of the town. That said, many Kubernetes-based solutions presented today completely lose sight of what the software is all about and what problem it looks to solve: Kubernetes comes from the world of cloud computing and makes great sense, especially against this background.

A few years ago, Docker had just made containers on Linux respectable after solutions like OpenVZ had failed to do so for decades. The primary reason Docker was successful is that it offered not only the runtime environment for containers on Linux but also created a suitable ecosystem, which undoubtedly included the aforementioned Docker Hub.

At the time, however, cloud computing had long been seen as the means of choice for companies that wanted to move from being IT heroes to major platform providers and at least play in a league similar to Amazon. Containers promised huge dividends because both orchestration and automation combined with prepackaged applications are effectively the highway to platform-as-a-service (PaaS) and software-as-a-service (SaaS) offerings. What was still missing was a solution that could manage and control containers across any number of physical hosts in a completely automated way. Kubernetes quickly established itself as a solution for precisely this task, if only because the product, as an in-house development at Google (up to that point), was explicitly designed for that purpose.