风险与回报：理解软件容器的指南

我们这些年纪足够大的人会记得软件主要通过物理媒体交付的一天。 宽带互联网和智能手机的普及将我们带入了网络服务时代——托管在云中的软件，可由浏览器和应用程序等用户客户端访问。

不久前，Web 应用程序直接在私有数据中心的物理机上运行。 为了便于管理，这些应用程序通常是单片的——单个大型服务器将包含所有后端代码和数据库。 现在，像亚马逊这样的网络托管服务和管理程序技术的普及已经改变了这一切。 多亏了 Amazon Web Services (AWS) 和 VirtualBox 等工具，将整个操作系统打包到一个文件中变得很容易。

使用 EC2 之类的服务，打包机器映像和将多组虚拟服务器串在一起变得很容易。 随之而来的是微服务范式——一种软件架构方法，其中大型单体应用程序被分解成更小的专注于做一件事的服务。 一般来说，这种方法可以更轻松地进行扩展和功能开发，因为可以更快地找到瓶颈并且更容易隔离系统更改。

宠物到牲畜

在这种趋势的高峰期，我成为了一名基础设施工程师。 我记得使用一系列 bash 脚本在 Amazon 中构建了我的第一个生产环境。 服务器对我来说就像宠物。 我给他们每个人起了可爱的名字。 我仔细观察他们。 我迅速响应警报并保持它们健康。 我用爱和感情对待这些实例，因为试图替换它们是痛苦的——就像一只心爱的宠物。

随之而来的是 Chef，一个配置管理工具，我的生活几乎立刻变得轻松了。 使用 Chef 和 Puppet 等工具，您可以消除与管理云系统相关的大部分手动痛苦。 您可以使用它的“环境”构造来分离开发、登台和生产服务器。 您可以使用其“数据包”和“角色”来定义配置参数并推送更改集。 现在，我所有的“宠物”服务器都从服从学校毕业。

然后在 2013 年，Docker 出现了，一个新时代开始了：软件作为牲畜的时代（向观众中的任何素食主义者道歉）。 容器范式是一种编排，而不是配置管理。 Kubernetes、Docker Compose 和 Marathon 等工具专注于移动预定义的图像，而不是调整正在运行的实例上的配置值。 基础设施是不可变的； 当一个容器坏了时，我们不会试图修复它——我们会朝它的头部开枪并更换它。 我们更关心畜群的健康，而不是个体动物。 我们不再给我们的服务器起可爱的名字了。

奖励

容器使很多事情变得更容易。 他们让企业更专注于他们自己的特殊酱汁。 技术团队可以少担心基础设施和配置管理，而主要担心应用程序代码。 公司可以更进一步，将托管服务用于 MySQL、Cassandra、Kafka 或 Redis 之类的东西，这样根本就不必处理数据层。 有几家初创公司也提供“即插即用”机器学习服务，让公司无需担心基础设施就可以进行复杂的分析。 这些趋势在无服务器模型中达到了顶峰——一种软件架构方法，允许团队在不管理单个 VM 或容器的情况下发布软件。 S3、Lambda、Kinesis 和 Dynamo 等 AWS 服务使这成为可能。 因此，为了扩展类比，我们已经从宠物到牲畜，再到某种按需动物服务。

这一切都非常酷。 我们生活在这样一个时代，一个 12 岁的孩子只需点击几下就可以启动一个复杂的软件系统，这真是太疯狂了。 我们应该记住，不久前，这是不可能的。 就在几位美国总统之前，物理媒体还是标准，只有大公司才有能力制造和分发软件。 错误修复是一种奢侈。 现在，这个 12 岁的孩子可以创建一个 AWS 账户，并将他的软件提供给全世界。 如果有错误，有人会在 Slack 上给他找错误，几分钟后，所有用户都可以修复。

风险

非常非常酷，但并非没有代价——依赖亚马逊等云服务提供商意味着依赖大公司和专有技术。 如果理查德·斯托曼（Richard Stallman）和爱德华·斯诺登（Edward Snowden）没有让你担心这些事情，那么最近与 Facebook 的惨败当然应该有。

对硬件的更大抽象也带来了透明度和控制力降低的风险。 当运行数百个容器的系统出现故障时，我们必须希望故障会出现在我们可以检测到的地方。 如果问题出在主机操作系统或底层硬件上，则可能很难确定。 如果您没有正确的工具，使用 VM 可以在 20 分钟内解决的中断可能需要数小时或数天才能使用容器解决。

当涉及到像 Docker 这样的东西时，我们需要担心的不仅仅是失败。 还有安全问题。 无论我们使用什么容器平台，我们都必须相信没有后门或未公开的安全漏洞。 使用开源平台也不能保证安全。 如果我们在系统的某些部分依赖第三方容器镜像，我们可能会受到攻击。

包起来

由于多种原因，畜牧业范式具有吸引力，但并非没有缺点。 在急于将整个堆栈容器化之前，技术团队需要考虑这是否是正确的选择，并确保他们可以减轻负面影响。

就个人而言，我喜欢使用容器。 随着新平台和范式的出现，我很高兴看到未来十年的发展方向。 然而，作为一名前安全顾问，我足够谨慎，知道一切都是有代价的。 工程师有责任保持警惕，以确保我们不会放弃作为用户和开发人员的自主权。 即使是世界上最简单的 CD/CI 工作流程也不值得。