My thoughts on Cntr: Lightweight OS Containers

Today’s paper first appeared in USENIX ATC ’18. I came across this paper as I’ve recently been working on a tool for understanding the effects of network topology on distributed applications by using virtual network interfaces and containers. As this effort has required a lot of debugging in containerized environments, the promise of tools that make working with containers faster and easier is alluring.

Overview

The aim of the paper is to describe a new lightweight container framework that allows combining multiple container images, or combining the host and the container, by leveraging FUSE. They refer to the split of the two images as the slim and fat image, where the slim image only contains the application and necessary environment, and the fat image may contain tools for debugging. The motivating usecase is having to use GDB on an application running in a container, and not wanting to install GDB in the container. While one could just find the PID of the running process in the host, GDB would then be unable to resolve debug symbols, or may not find the right system libraries. Without spending significant effort configuring GDB, or creating a strange new union’ed filesystem, there not a lot of ways to achieve this. cntr solves this problem by creating a new nested namespace inside the container’s namespace, but with the tools and PATH from the host. However, due to the usage of FUSE some IO applications may suffer some performance impacts when run in the cntr environment, but that might not matter for most usecases. The implementation is open source and available on github.

Thoughts

• This seems somewhat fragile. The paper provided no insight as to how tools like GDB may resolve system libraries.
• Alternatives and related works exist that weren’t mentioned. At the time of publication, snap was already introduced in ubuntu, and there was discussion of file deduplication in snap. While this is admittedly more or less the same as docker’s UnionFS, not mentioning/comparing against snap seemed odd. Additionally, docker already had the --volumes-from options which allows composing volumes from multiple containers together. While this doesn’t solve the problem of exposing host tools to the container, it does achieve a similar solution without requiring a new tool.
• At a glance, I feel like this tool may not compose well with modern environment management tools like conda, though at the time of publication, conda was not widely used (if it even existed at the time)

Fundamentally, I think containers don’t compose super well. Containers seem to occupy a model of the world where composition is impossible to achieve, and so the only solution is to compose at a higher level/horizontally scale, and rely on magic within the container to deduplicate files or share resources. Maybe the answer really is something like snap/flatpak where every application brings the environment it relies on with it, so that applications can easily be used across container boundaries. All this being said, cntr does seem to actively maintained/developed, and one of it’s key selling points now seems to be that it can interop with virtually any container frameworks as opposed to being docker specific - that definitely makes it more interesting. Overall though, I think most of us are better off just using “fatter” images and adding tools as we need them. Storage space is cheap, and sharing a fat base layer is completely free.