之前我写了一篇文章，点评了容器生态系统，顺带嘲弄了下Docker、Google、CoreOS和一系列其他技术。许多Docker爱好者非常喜欢结尾那个玩笑，但是也有很多人喜欢那句“我告诉你们它们都是渣渣”。

不难理解为什么人们会认为容器生态系统是“渣渣”，尤其是从我上篇的角度来看。毕竟，匆忙的一瞥很难弄清楚Docker到底是什么。容器化有点像虚拟化，但是并不完全一样。它有一个类似Chef的Dockerfile，但是是和一个和分层相关的文件系统结合的。它和AWS 、Heroku 、 VMware 和Vagrant一样解决类似的问题，但是又有些不同。它有27个彼此有竞争关系的工具，很难说上来它们具体干嘛用，名字也都非常有意思——比如machine、 swarm 、 flannel 、 weave 、 etcd 、 rkt 、 kubernetes 、 compose 和 flocker等等。它一定程度上和新兴的微服务有关联，但是要去考虑如何让单一服务首先跑起来又显得很蠢。

如果仔细看过了Docker和容器，仍然认为它是渣渣，那么也可以理解——除非它不是。

好吧，它确实不是，它是我们搭建应用的未来。

许多看了《一份Docker的反方辩论——我还是用Heroku好了》的人觉得文章写的非常准确，并没有讽刺和夸张，然后质疑了容器这个事物，为什么呢？

Docker和其容器生态系统（之后简称“Docker”）正在改变应用开发世界的一些基础，比如虚拟化、面向服务的架构和操作系统，然后把它们以不同的目标和优势重新交付。但同时，也触怒了开发者社区的一些人——守旧而讨厌新事物的顽固派。

软件行业可能与想象中不同，其实充满了抵制进步的人们——就如同当米开朗琪罗完成了他的创作，那群走进西斯廷教堂的人们却开始声称他们已经有了很好的上帝画作，他们更喜欢天花板是纯白的，米开朗琪罗的壁画一点都不美好。

同时，大部分的软件行业像高中学生一样做着决策：他们着迷地搜索着他们小团体内更酷的东西，看看Instagram和 Facebook上都有什么，然后盲目地追随着他们的引导者。这些技术形成了各自的派系，精心雕琢着各自的技术——甚至会在笔记本上贴上属于他们的标志和颜色，并且排斥和抱怨他们陌生或者不同的技术。

而进入的那个世界的Docker——几乎所有的工作方式都是新的。它抛弃了各种旧规则——包括操作系统、部署、运维、 封装、防火墙、PaaS等等。一些开发者立刻爱上了它，有时候是因为它有效解决了一些问题，有时候是因为它是闪亮的玩具——让他们在其他孩子玩到它之前显得很酷。另一些开发者则讨厌它，讨厌它大肆的宣传和炒作，认为它就和其他之前新出的技术一样，并没有什么不同，却被人人谈论着。

因此，很多人对于Docker的感受并不是源于技术本身。许多Docker的反感者并不是厌恶Docker在重要和复杂问题上的解决能力。如果他们没有花足够的时间去了解大规模系统的扩缩，绝大多数问题他们是没法理解的。如果不是直观且深入地了解过，那么关于Docker的很多选项和相关的工具都会看起来很奇怪很吓人。

Docker出现在两个学科的结合点上——Web应用和分布式系统。对于过去的十年，我们在web社区很多时候都在假装只要知道如何编程就可以搭建web应用。我们写一些HTML、 JavaScript 、 Rails，然后我们就有了一个网页。我们加一些窗口、处理程序和一个API，然后我们就完成了它。之后发布产品，就能够吸引用户，获得收入，就改变这个世界了！

而同时，过去的二十年间，分布式系统的家伙一直在做一些相当无聊的东西。他们使用CORBA和SOAP这样复杂的协议进行试验，学会了如何处理像CAP定理这样的问题，了解了时钟同步是何等重要，认识到Two Generals Problem等主要理论。这些问题和解决方案对于只是想简单地编程和交付应用的人来说，相当的乏味无聊。

但是之后有趣的事情发生了。Web应用变得非常大，开始变得规模化。很多人进入互联网，web应用不能只在单一VPS上，或者只是垂直方向扩展。我们开始扩大它的规模，然后我们看到了应用中的各种bug，它们的名字很有趣：像“raceconditions”，“networkpartitions”，“ deadlock”和“Byzantine failures”等。这些问题是分布式系统的那些家伙搞了很久的问题，很多问题的解决方案不只是困难，理论上甚至是不可解的。

在扩展危机的早期，Heroku出来了。Heroku可以使我们很容易地在基础设施水平层面上进行扩展，让我们再一次假装只做简单web应用。于是那五年，我们花钱买的是自欺欺人的假装。

我们现在走到了自欺欺人的边界上，轻轻一脚迈了出来，我们在试图建立早期的扩展性，重构破碎的事物，了解了单体应用架构的缺点以及为什么单一数据库不能持续为我们工作。我们提出了一些概念，像不可变架构，“宠物还是放养”，微服务，以及一整套最佳和最差实践来尝试让问题简单化。

在这个转变中，Docker入局，尝试解决很多问题。但是与Heroku那样告诉我们可以假装扩展问题不存在、可以继续按照过去的方式来行事不同，Docker告诉我们分布式系统是我们一直在做的基础，我们需要接受它并在这个模型下工作。不再像过去的web框架、数据库和操作系统那样只处理简单问题，我们现在使用Swarm、Weave、Kubernetes和etcd等工具，不再假装一切都很简单。实际上，我们不再是单纯解决问题，而是深入了解我们正在解决的问题。

我们终于有能力构建可伸缩的架构而不是假装它只是抽象事物了。现在我们需要了解什么是网络分区并且如何处理它，如何在AP和CP系统中做出选择，如何构建在现有网络和机器的约束下仍然可以扩展的架构——有时在弗吉尼亚州发生一场风暴，有时会发生火灾，有时鲨鱼会咬断海底电缆，有时会是一个延迟、一个交付失败、机器死机或者抽象层有了裂缝，意外总是不时发生，不是吗？

一切都渴望更有弹性、更可靠，作为开发应用的一部分这些都是需要考虑的。并不是因为它是闪亮的新事物、或者它是一些虚构的最佳实践，而是因为像亚马逊、Netflix或者Google已经在这上面投入了15年的心血，他们告诉了我们如何构建真正有规模的系统。

所以，Docker到底为我们解决了什么问题？我们为搭建web应用而做的每件事都是脆弱而混乱的，Docker正在让它变得清晰而条理：

截止目前，我们已经部署机器（DevOps中的运维部分）和应用（开发部分）分离，甚至我们有两个不同的团队来管理这部分应用的堆栈。然而这很可笑，因为应用像依赖代码一样依赖着机器和OS，考虑把它们分开没有意义。容器在开发者工具的帮助下可以统一管理OS和应用。

截止目前，我们一直在AWS上运行我们的面向服务的体系架构、Heroku、其他PaaS和IaaS，缺乏真正的工具来管理面向服务的架构，而Kubernetes和Swarm管理和编排了这些服务。

截止目前，我们已经使用整个操作系统来部署我们的应用。容器允许我们公开一个非常小的应用程序，只需要一些端口——小到一个静态二进制。

截止目前，机器上线后我们一直通过使用“配置管理”工具或者在同一台机器上重新部署应用来摆弄它们。由于容器是通过编排框架来实现规模扩缩，只需不变的镜像来启动，跑的机器不会被重复使用，消除了潜在的故障点。

截止目前，很大程度上我们一直在使用单个机器为单体应用设计的语言和框架。在这之前，Rail为面向服务架构设计的路线没有真正存在过。现在Kubernetes和Compose允许我们在服务之上指定拓扑结构。

截止目前，我们已经部署了由亚马逊等提供的重量级虚拟化服务器。然而我们不能说“我想要0.1个CPU，和200MB的内存”。我们已经浪费了很多虚拟化的开销和超出应用所需的资源。而容器可以更少需求地进行部署，并且更好地进行共享。

截止目前，我们已经在多用户操作系统上部署了应用和服务。多个用户可以同时跑在Unix上，共享文件、数据库、文件系统和服务。当我们搭建web服务时，它会与我们的工作完全不匹配。而容器可以保存简单文件而不是整个操作系统，让我们减少对于应用和服务的考虑。

我们的行业发展如此迅速，对于新技术狂热崇拜并且不会等技术真正落地成熟。Docker正在以不可思议的速度发展着，这也意味着它还没有接近稳定和成熟。对于容器运行时、镜像格式、编排工具和主机OS，我们有很多选择，每一个都有不同的使用水准、范围、吸引力和社区的支持。

环顾我们的行业，在事物变得又老又无聊之前，它是不会稳定。举个例子，在我们有REST之前，有多少协议不得不消亡。我们踩在SOAP和CORBA的尸体之上通过经验和教训建立了REST 、AJAX和JSON。这是过去十年最主要的两个技术转折点。然而我们基于API的REST工具还没有达到十年前我们为SOAP所做的水平，特别是SOAP尚未完全死亡。

我们都知道Docker还没有成熟，在尝试它的时候仍有许多边界情况和缺陷。问题的浮沉之间，我们一次又一次思考解决的办法，不断尝试不断失败，直到探索出最佳实践的方法。可能几年以后我们再回顾这段经历，会发现很多决策上的错误或者失败，但是这就是探索的意义，进步的代价。

或许会花费很多年的时间，了解了它全部的特性，Docker才会真正稳定下来。但是这并不意味着容器是无稽之谈。我们总是面对着选择，是选择我们已经深刻了解的技术还是尝试一些新的事物？答案很清楚，只有不断地学习和适应技术的迭代，才能带来我们行业的进步和提升。

如果你在寻找我，那么向前看，我就在未来。

原文来自：

本文地址：q13zd.cn/docker-coming.html编辑员：倪家兴，审核员：逄增宝

本文原创地址：//q13zd.cn/docker-coming.html编辑：倪家兴，审核员：暂无