容器功能强大，易于提供应用程序或服务。虽然容器的目的是为了减少可变因素，从而简化和提高效率，但有许多复杂因素要考虑。在企业界，考虑这六个因素很重要：

1. 性能

开发人员通常不从性能的角度考虑潜在问题，但就因为你使用Web浏览器访问应用程序并不意味着它可处理大量并发事务。真正测试后，你才知道其处理能力。

Kubernetes可扩展规模，但也会占用大量资源。容器可帮助解决架构问题，并确保所有必需的依赖项都到位，但它在推出后并不自动确保性能。

底层语言运行时环境、Web服务器和openssl等库的质量都会对性能产生影响。确保你的Linux发行版有一批积极主动的性能工程师进行回归测试，更重要的是优化整个架构的性能。

2. 兼容性

在Linux界，不同的程序在内核上运行。大多数程序使用与内核对接的API：syscall层。如果你坚持使用Linux中的syscall层，向前兼容性就很重要。

Linux之父Linus Torvalds有条严格的规定：内核不应破坏向后兼容性。容器始终向前兼容，因为syscall层尽量不破坏该功能。

在旧的内核上运行新的容器映像会发生什么?或者你从syscall层进入到ioctl、/dev、/proc之类的API会发生什么?

兼容性存在时间和空间方面的限制，良好的设计和测试有所帮助。面向容器映像和主机的Linux发行版要深入考虑这些问题，否则用户会陷入糟糕状态。在内核层、编译器层(gcc)和库层(glibc)以及syscall接口之外的API都是如此。

另一个问题是，如果只使用与C库有关的syscall函数，你可能没问题。但应用程序更有可能调入一款不是应用程序一部分的辅助软件，比如故障排查或监控组件，它们使用ioctl /proc或/dev之类的其他内核API，这可能会导致问题。

如果升级容器主机，它可能再无法运行容器。在虚拟机领域，你通常不必担心(然而就算使用虚拟化，一些架构或芯片组可能会导致问题)，但在物理服务器领域，一些架构或芯片组可能导致问题。

3. 与现有基础设施整合

受支持的软硬件生态系统对应于底层的Linux发行版。如果你需要ARM支持，它必须要有。考虑可支持性――这适用于面向硬件的容器主机和面向软件的容器映像。

选择容器映像和容器主机时，这个“购买标准”常被遗忘。但记住，Linux发行版的生态系统(硬件和软件)是可供容器主机(硬件)和容器映像(软件)使用的生态系统。如果你的Linux发行版支持某个特定的硬件或云提供商，那么你的容器主机就能够顺畅运行。

如果你的应用程序是为特定的Linux发行版设计和构建的，将那些应用程序放入基于该Linux发行版的容器映像中会容易得多。

4. 安全

一旦容器映像部署到生产环境，它将使你的应用程序及其所有依赖项暴露在危险重重的互联网面前。这包括拒绝服务攻击、数据泄露、特洛伊木马图片和黑客攻击。为容器环境选择容器映像和容器主机时要考虑所有这些方面。

可能你不是从Red Hat容器目录下载该容器映像，而是选择从某个可疑网站下载。这是个坏主意。如果不从已知好的容器入手，有人会注入恶意代码，而你浑然不知。

从安全角度来看，了解组件的质量至关重要;始终使用信得过的来源。记住：容器在你下载那天可能是好的，但几年后可能变坏了。

5. 大小

容器执行大量构建操作，每当重建容器都会重新编译应用程序。

现在，开发人员负责映像中的一切。一年后，如果某个库中的代码破坏向后兼容性，容器出故障，谁来修复?他要有开发人员的技能，而不只是执行“yum update”之类的操作。可能需要重新编译应用程序。

另一种方法是构建基本映像，它有程序包，比如用openssl动态编译的Web服务器软件，性能问题可通过yum update来修复以获取新的程序包。这比更改代码容易得多，不过最终映像更庞大。

一旦添加软件，基本映像的大小无关紧要，现在它是400 Mb或500 Mb。

正在开发两种主要的容器化应用程序。一种是基于Linux基本映像构建的，另一种是从头开始构建的。

在这两种应用程序中，用户常常对容器映像的大小敏感，因为它会影响将容器映像提取到容器主机所需的时间。如果从头开始构建，并部署静态编译的二进制文件，选择小巧的基本映像或从头开始构建很重要。

为用于企业内部的软件构建整个生态系统时，考虑整条供应链的大小(所有RPM程序包及依赖项)更重要，因为基础层常常可以共享和缓存。减小攻击面的关键是减少库和语言运行时环境的重复副本，从而减小在整个环境中的占用空间。

6. 支持

支持主要有两种：生命周期支持和白手套支持。

生命周期决定了支持时间以及为容器映像中的任何特定程序(RPM或Debs)发布哪些补丁。

白手套支持让你可以提交工单、获得热修补程序以及主张上游更改。

两者都非常重要，具体取决于你支持容器化应用程序的时间。

生命周期支持的上下文很重要，因为应用程序的运行时间比你所想的要长。可能三五年，或者更久。应用程序/系统有众多实例，运行了多年。你要考虑支持该基本映像多长时间来运行yum update。然后你要回到第一个模式来更改代码、实现不同版本的库，并将其放回到开发人员的手中，这可能代价高昂。

问问自己：我的容器映像是否有更新?要是出了问题，可以打电话给某人，获得修复程序吗?如果我有独特的问题，可以要求开发补丁吗?能够提交工单、要求补丁与仅仅运行yum update是不一样的支持级别。

原文标题：6 critical factors to consider when deploying containers，作者：Scott Matteson