一文读懂如何选取 Linux 容器镜像

一份如何选取 Linux 容器镜像的 对比报告 阐述了镜像选取中的一些最佳实践。报告中涉及了架构、安全和性能等因素，此外，商业用户还需要考虑厂商的支持情况。
　　Linux 容器提供了对内核空间和用户空间组件的独立管理，这是是通过使用 cgroups 和 命名空间 （Namespace）等资源及进程隔离机制实现的。虽然 Solaris 和 BSD 也提供了与 Linux 容器威廉希尔官方网站 类似的 抽象机制 ，但此份对比报告只聚焦于 Linux 容器威廉希尔官方网站 。运行容器的主机提供了运行容器所需的操作系统内核和一系列工具。另一方面，容器镜像提供了运行分布在容器间的应用所需的软件库、解释器和应用代码。所有这些都依赖于底层系统库。对于解释性语言也同样适用，因为解释器本身也是使用底层语言编写的。
　　第一个原则是容器镜像的大小。各容器镜像在磁盘上的大小不等，从 Fedora 这样的 230MB 大小，到 Alpine Linux 这样的 4MB 大小。但是在选取一个镜像发布版时，镜像的大小并非 唯一应该考虑的问题 。镜像的主要分组包括 Debian/Ubuntu、RHEL、Centos、Fedora 和 Alpine。
　　第二个原则是容器中的安全漏洞问题。该问题已成为 很多报告 的主题。根据 一份最新的研究 ，Docker Hub 上的公开 Debian 容器镜像所具有的漏洞最少，而 Ubuntu 镜像的漏洞最多。该研究仅涉及了哪些公开的 Docker 镜像。一些工具也提供了不同程度的防护和功能，例如 Clair 和 vuls 这样的开源工具，以及 Twistlock 等这类商业工具。很多软件厂商已实现对发布版及 Web 服务器和数据库这样的通用软件中的未知漏洞的 自动测试 。一些开源 工作 也致力于减缓或最小化容器漏洞，两者都会对主机和容器间的相互通信产生影响（参见该 幻灯片 的第 7-9 页）。
　　第三个原则是镜像中的软件包情况。glibc 等核心库和软件包格式会对容器的安全和性能产生影响。一些成熟的软件库，例如 glibc 和 gcc，具有很大规模的用户社区，并已经被稳健地使用多年。这也是容器镜像使用这些软件库的首要原因。但是 Alpine 等一些发布版坚持另辟蹊径，这 已经导致 了一些 问题 。
　　除了上述三个原则，企业用户还需要考虑镜像的生命周期和产品支持因素。RHEL 和 Ubuntu 给出了一些商业支持选项，它们通过论坛对各种用户提供社区支持。Ubuntu 和 RHEL 引领了生命周期范围的管理，即一个发布版本得到支持的时间范围，在此期间将提供软件缺陷修复、补丁与特性的向后移植（Backporting）及支持。
　　报告给出的结论是，容器镜像的选择类似于选择 Linux 发布版。为此，Google 的“ Distroless ”镜像给出了一种非常有意思的拆分方式。Distroless 仅是一个提供各种应用及其运行时依赖的镜像，并不包含哪些在任一 Linux 发布版中通常都会包含的程序，例如 Shell 和软件包管理等。