A comparison of Linux container images talks about the best-practices in choosing an image. Architecture, security and performance are among the factors, while commercial users would also look for support options.
A Linux container allows separate management of kernel space and user space components by utilizing cgroups and namespaces, which are resource and process isolation mechanisms. Solaris and BSD also have abstractions similar to Linux containers but the article's focus is on the latter only. The host running the container has the operating system kernel and a set of libraries and tools required to run containers. The container image, on the other hand, has the libraries, interpreters and application code required to run the application that is being distributed in the container. These depend on underlying system libraries. This is true for interpreted languages too as the interpreters themselves are written in low level languages.
The size on disk of various container images varies from 230 MB for Fedora to 4 MB for Alpine Linux. Size, however, is not the only consideration that should be given while choosing a distribution. The major groups are Debian/Ubuntu, RHEL, Centos, Fedora and Alpine.
Security vulnerabilities in containers have been a subject of many reports. Public Debian container images on Docker hub have the least amount of vulnerabilities, according to a recent study, while Ubuntu images have the highest. The sample space of this study was limited to public Docker images. Open source tools like Clair and vuls and commercial ones like Twistlock offer varying degrees of protection and features. Most vendors have automated tests for known vulnerabilities in the distribution as well as for common software like webservers and databases. There are open source efforts on mitigating and minimizing container vulnerabilities, both (slides 7-9) ones that impact host to container communication, and also the other way round.
Core libraries like glibc and package formats impact security and performance. Mature libraries like glibc and gcc have become robust over many years of usage and a big user community, which is the primary reason that container images use them. Some distributions like Alpine have, however, remained with alternatives which led to problems.
Apart from these three criteria, enterprise customers would also look for lifecycle and support options. RHEL and Ubuntu have commercial support options with community support via forums available for all flavors. Ubuntu and RHEL lead in terms of lifecycle span - the period of time for which a version is supported in terms of providing bug fixes, backporting fixes and features and providing support.
The conclusion is that choosing a container image is similar to choosing a Linux distribution. "Distroless" images offer an interesting spin-off on this topic. Distroless images are images of just the application and its runtime dependencies. They don’t contain any programs like shells and package managers usually found in a Linux distribution.
