风险与回报（了解软件容器的指南） _Docker

本文概述

宠物放牧
奖励
风险
本文总结

【风险与回报（了解软件容器的指南）】我们这些年龄足够大的人可以记得有一天主要通过物理媒体交付软件。宽带互联网和智能手机的普及使我们进入了Web服务的时代。Web服务是托管在云中的软件, 可由用户客户端(例如浏览器和应用程序)访问。
不久之前, Web应用程序直接在私有数据中心的物理机上运行。为了便于管理, 这些应用程序通常是整体的-单个大型服务器将包含所有后端代码和数据库。现在, 像Amazon这样的虚拟主机服务以及虚拟机管理程序技术的普及已经改变了所有这一切。得益于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岁的孩子只需单击几下就可以启动一个复杂的软件系统的时代。我们应该记住, 不久前, 这是不可能的。就在几位美国总统之前, 物理媒体是标准, 只有大公司才能制造和分发软件。错误修复是一种奢侈。现在, 那个十二岁的孩子可以创建一个AWS账户, 并将其软件提供给全世界。如果存在错误, 则有人会在Slack上对他进行调试, 并在几分钟之内为所有用户推出了修复程序。
风险非常非常酷, 但并非没有价格-依赖像Amazon这样的云提供商就意味着依赖大公司和专有技术。如果理查德·斯托曼(Richard Stallman)和爱德华·斯诺登(Edward Snowden)没让你担心这样的事情, 那么最近与Facebook的倒台无疑应该有。
远离硬件的更多抽象也带来了透明度和控制性降低的风险。当运行数百个容器的系统发生故障时, 我们必须希望故障在我们可以检测到的地方冒出泡沫。如果问题出在主机操作系统或基础硬件上, 则可能很难确定。如果你使用的设备不正确, 使用VM在20分钟之内可以解决的中断可能需要数小时或数天才能解决。
当涉及到诸如Docker之类的事情时, 我们不仅需要担心的不仅仅是失败。还有安全性问题。无论我们使用什么容器平台, 我们都必须相信没有后门或未公开的安全漏洞。使用开源平台也不能保证安全。如果我们在系统的某些部分依赖第三方容器映像, 则可能会受到攻击。
本文总结出于多种原因, 牲畜范式具有吸引力, 但它也有其缺点。在急于将整个堆栈进行容器化之前, 技术团队需要考虑这是否是正确的选择, 并确保他们可以减轻负面影响。
就个人而言, 我喜欢使用容器。我很高兴看到随着新平台和范例的出现, 未来十年的发展趋势。但是, 作为一名前安全顾问, 我非常谨慎地知道所有事情都是有代价的。工程师必须保持警惕, 以确保我们不会放弃作为用户和开发人员的自主权。即使是世界上最简单的CD / CI工作流程也不值得花费。
相关：数学：使用Orchestrators自动扩展微服务应用程序