容器是帐篷

最近我读了很多文章，似乎建议容器有点吮吸。而且，肯定。它们不一定使代码更快，或更安全，或更容易调试。它们需要复杂的Orchestration系统，您甚至无法使用它们来在不同的操作系统上测试代码。福音学家的日子已经过去了，容器如何答案到所有生活中的答案;现在认为碎片有类似的标题，“为什么你不需要docker，”和“我做了这个奇怪的伎俩，仍然达到kubernetes的缩放限制。”

但这种品牌的集装箱疲劳主要是我们如何使用它们的产品。我经常看到容器称为“轻量级VMS”，但这对容器的专注于作为虚拟化的形式，导致很多焦虑。是的，有相似之处和重叠点，但是当我们将它们视为解决相关的工具时，容器最有用，但是解决相关，但不同的问题。事实上，它们是非常有帮助的 - 只要您没有尝试使用它们来模仿整个操作系统。

这样想：如果VM就像房子，那么容器就像一个帐篷。您可以尝试适合您内心的所有家具，但鉴于物质和时空的约束，您只能尝试适应所需的东西。帐篷很轻，快速地伸出并拉下来 - 但你可能会觉得风摇晃着帐篷杆。雨不会进去，但帐篷不会留出冷像砖墙和屋顶。并且有足够的努力，即使帐篷翻盖被扣紧，你就可以抓住你的出路。

如果你试图用两卧室联排别墅的东西填写一个衣柜，那么也许你真正需要的是一栋两卧室的联排别墅，有一个附着的车库。就像我们可以编译代码以静态链接到一个二进制文件中的所有依赖项，容器提供了一种方法来静态链接代码可能拥有的所有运行时依赖性。就像你不希望你的编译器包含整个操作系统，容器图像不应该用您的应用程序代码包装OS副本。

容器图像中的二进制文件和文件越多，尤其是为内核提供接口的一体化，通过该帐篷墙壁爪的机会越多，逃脱容器。在同一主机或VM上运行许多容器时，这尤其相关。毕竟，帐篷不是一个特别安全的地方来存储贵重物品。然而，你的客厅里的帐篷里有贵重物品？非常安全。你的客厅里的帐篷里你的贵重物品在别人的帐篷里？好吧，它真的取决于谁（或者）在那个帐篷里面等着你弹出午餐。

从安全角度来看，容器是有用的，因为它们提供了一个非常有限的攻击表面（即可以利用的较少数量的二进制文件），除了代码本身。如果填充容器图像，则会失去这种好处，并最终以更少的安全，更慢的操作系统逼近。就像你最有可能选择在一个帐篷里住在一个两卧室的联排别墅一样，如果你需要的是轻量级操作系统，容器不是你最好的选择。

最后，有整个资源隔离业务。虽然CGroups作为孤立机制非常整洁，但它们并不是对嘈杂邻居的硬件级别。因为CGroups是后来的内核之后，但并不总是可以确保他们在制定系统范围的资源管理决策时考虑到。底线：如果你不能容忍噪音，也许不要邀请人们在起居室里露营。

没有人会争辩说帐篷与砂浆房屋的既同用途相同的目的 - 也不应该是他们应该！ 容器制作可怕的VM。 （并且是公平的，VMS对容器的替代品同样差。）如果我们坚持判断帐篷作为房屋，或者容器作为VM，那么它总是会缩短。 我想提出我们重新制定他们的实用程序：而不是轻量级的虚拟机，让我们将它们想象为重量级过程包装。 通过从操作系统中删除进程，将其包装在名称空间和权限中，并将其与其运行时依赖关系捆绑在一起，容器提供强大的执行原语。 只要我们不期待到基岩的基础，容器可以是令人难以置信的宝贵工具。 与任何技术一样，诀窍是知道何时使用它们。