Docker——它是真正的未来

本文从产业技术发展的角度论述了容器目前存在的问题和为什么它是技术的未来。

Docker目前虽然从技术上来讲还不成熟，但是它从真正意义上解决了过去若干年在软件行业存在的诸多问题。

文章鼓励大家去尝试容器这个新的技术，在实践中获得经验和教训进而迭代式的前进来改善和提升我们的产业。


这真的是未来
上周我写了一篇文章讽刺容器生态系统的文章《It’s the Future》（https://circleci.com/blog/its-the-future/）轻微的嘲笑了一下Docker、谷歌、CoreOS和其它一些容器技术。众多的Docker拥趸把这当成了笑柄，但也有很多人喜欢并分享说“我早就告诉你这一切都是垃圾”。


非常容易理解为什么人们会认为容器的生态系统是垃圾，就像我在文章里讽刺的那样，但当我们第一眼看到Docker是什么的时候并不能很明显看到这一点。容器化有点像虚拟化但又不完全一样。Dockerfile有点像Chef但是它里面包含了一个诡异的分层文件系统。它解决了AWS、Heroku、VMware和Vagrant类似的问题，但是又以一种难于捉摸的方式跟其中的每一个有细微的差别。它有27个竞争的工具而且你从它们的名字完全不能理解它们是干什么的，例如Machine、Swarm、Flannel、Weave、etcd、rkt、Kubernetes、Compose 和Flocker。 它们都或多或少的跟闪亮的微服务有关联，但是使得运行一个简单的微服务变得如此复杂不得不说这是一个伟大的傻点子。不仅如此，这还使得众多的初创公司和大公司都在竞争“开发人员青睐”，这在古老的年月里看上去是跟钱相关的，而且还有大量的人在追随着一切。


在你仔细观察Docker和容器之后得出结论说着一切都是垃圾并非不合理。但是也有例外，这是我们未来构建应用的方式。


为什么要仇视呢？
很多人对It’s the Future的反应是认为这是100%精确的，根本不是讽刺，也有人在怀疑围绕容器的大肆宣传。为什么呢？


Docker和容器生态系统（后文简称为“Docker”）借用了应用开发者世界的多个概念，例如虚拟化、SOA和操作系统；然后以不同的目的和好处进行了包装。然而它这么做也带来了开发者社区的大部分问题：坏脾气的人痛恨一切。


在软件行业，跟你期望的不同，里面充满了痛恨进展的人。这些人会在米开朗基罗做完了（译者注：创世纪）之后走进西斯廷教堂声明自己早就有了一副完美的上帝的画像,他们期望天花板是白色的，那些壁画本来也不好。（译者注：指这些人看不起别人的成果。）


同时，绝大部分的软件行业的决定看上去也像一个高中生一样：他们在自己的圈子里过分看重那些看上去很酷的技术，或许根据从Instagram和Facebook上获得的信息而盲从。在这些技术当中他们组成小的团体,他们甚至在自己的笔记本上贴上他们团体的标志，而痛恨那些看上去陌生或者不同的技术。


回到Docker的世界：一种几乎可以做任何事情的新的方式。 可以抛弃关于操作系统、部署、运维、打包、防火墙、平台即服务和其它一切东西的规则。有一些开发者立刻爱上了它，有时是因为一些有效的原因例如它真的解决了他的问题，而有时仅仅是因为这是一个闪亮的工具可以使他们看上去很酷，其他人还没有接触到。另外一些开发者则痛恨它 – 这仅仅是过度宣传，它跟以前的技术并没有区别，不知道为什么所有人都在关注它，仅仅是因为一些并不合理的理由。


因为对Docker的反应不仅仅是基于技术本身的。大部分的反对者不是在反对Docker处理重要和复杂问题的方案。大部分情况下是因为他们并没有碰到诸如扩展大的系统的问题。如果你们没有直观和深入的理解“cattle not pets”的含义以及这为什么重要，那么Docker及其相关的工具所做的选择对你来讲会看上去很奇怪和可怕。




合并的世界
Docker处在两个学科的交汇点：Web应用和分布式系统。在过去的十年，我们所在的Web社区使得我们相信只要我们懂得如何编写代码就可以实现Web应用。我们通过写一些HTML、JavaScript和Rails的代码就可以实现一个网站。我们添加了一些表单以及处理程序或者一个API就完成了：这足以发布一个产品、获得关注和客户、赢得利润并改变世界！


同时，在过去的20年间，分布式计算的同仁们也在做类似的无聊的事情。他们实验了一些复杂的协议例如CORBA和SOAP，并学者处理一些诸如大数定律、时钟同步的问题，这些问题对大多数人来讲是太过理论了。这些问题及其方案对任何人来讲都是无趣的，人们只是想着如何利用他们的知识去写代码来实现Web应用。


但是接下来有趣的事情发生了。Web应用已经大到不得不横向扩展，来自Internet的大量访问使得Web应用无法在一个单独的机器上运行，即使通过纵向扩展也无法实现。当我们开始横向扩展的时候，我们开始碰到那些分布式系统中的问题例如“竞争条件”、“网络分裂”、“死锁”以及“拜占庭将军问题”。分布式系统的同仁们已经致力于处理这些问题很长时间了，但是这些问题的解决方案是非常复杂的，甚至在理论上都是不可能实现的。


在早期，Heroku碰到了这个横向扩展的危机。Heroku通过一种极其简单的方式实现了基础设施的横向扩展，这使得我们再次假装这只是在运行一个简单的Web应用。而这种情形使得整个业界被欺骗了至少5年的时间。


我们现在已经走出了这个欺骗的情形，我们发现不得不试着进行横向扩展，需要去重新架构那些不能工作的软件使得它可以横向扩展，我们也逐渐了解了单体架构的问题，理解了为什么单个的数据库无法解决这种问题。这造就了一些新的概念例如“不可变基础设施”、“ Pets vs Cattle（译者注：指基础设施在架构中扮演的不同角色，宠物意指小心呵护不能碰触的基础设施，牲畜指Design for fail的基础设施）”、微服务以及一整套最好和最坏的实践方法试着让这些问题变得简单。


在当前变化的形势下，Docker来了并试着解决所有问题。它没有告诉我们继续假装横向扩展的问题根本不存在我们可以继续使用已有的方式处理，跟Heroku所做的类似， Docker告诉我们分布式系统从根本上讲是我们一直以来都在处理的，因此我们需要接受它并开始使用分布式的模式。它没有继续处理一些简单的事情例如富贵吧Web框架、数据库和操作系统，我们现在有了很多的工具例如Swarm，Weave，Kubernetes和etcd等，这些工具不在继续假装一切都很简单，而是要求我们不但去解决问题，而需要试着深入了解我们正在解决的问题。


这样做的好处是我们获得了去构建横向扩展架构的能力而不是假装我们可以抽象它。我们需要知道网络分裂是什么以及要怎样处理它，如何选择AP还是CP系统，如何构建可以在真正的网络和服务器上进行横向扩展的系统。有时在弗吉尼亚会有电子风暴、有时会着火、有时鲨鱼会咬断海底电缆、有时会有延迟、有时机器会死掉等等。（译者注：指我们需要处理这些异常）

所有的东西都需要更加有弹性、更可靠，我们需要承认这些是我们在开发程序是需要考虑的问题。我们要做不是因为这很酷，或者因为它是虚构的最佳实践，而是因为像亚马逊、Netflix和谷歌已经花了15年的时间来告诉我们如何构建真正能横向扩展的系统。


真正的问题被解决了
因此Docker真正为我们解决的问题是什么？我们在构建Web应用时所做的一切都是脆弱的，Docker强迫我们保持清醒和理智：

到目前为止我们还在将部署机器（DevOps中的运维部分）和部署应用（DevOps中的开发部分）分开来做，甚至是由不同的团队维护的。 这非常滑稽因为应用依赖于机器、操作系统和代码，分开来考虑这些问题完全没有道理。容器在开发者的工具箱层面将OS和应用进行了统一。

到目前为止，我们在AWS、Heroku和其它的IaaS以及PaaS平台上运行我们的SOA架构时缺少管理这些SOA服务的工具。Kubernetes和Swarm 管理和编排了这些服务。

到目前为止，我们在使用这个操作系统去运行我们的应用，暴露了所有的安全问题而不是使用尽量少的资源和暴露尽量少的安全漏洞。容器允许你仅仅暴露你需要的端口，应用可以小到一个单一的静态二进制程序。

到目前为止，我们都是在机器安装完成后使用“配置管理”工具或者多次向同一个机器上部署应用. 因为容器可以通过编排工具实现弹性伸缩，只有不变的镜像被启动，运行的机器从不被重用，因此可以去除潜在的单点故障。

到目前为止，我们都在使用被设计为在单个机器上运行的单个应用程序。Rails的SOA等价物以前并不存在，现在Kubernetes和Compose允许你定义跨服务的拓扑。

到目前为止，我们都在AWS提供的特定尺寸的基础上部署虚拟机。我们不能说“我需要0.1CPU和200MB内存”。我们在浪费虚拟的开销和使用更多的资源。容器需要的资源更少，也能更好的进行资源共享。

到目前为止，我们都在多用户环境的操作系统中部署应用。Unix被设计为有大量用户共享操作系统上的二进制程序、数据库、文件系统和服务。这完全不符合我们构建Web服务的需求。再次，容器可以保留简单的二进制程序而不是整个操作系统，结果就是程序和服务不需要考虑更多的问题。

唯一不变的就是改变
我们的业界迅速的发展，人们在新技术真正成熟之前就迫不及待的追随和使用。Docker正以惊人的速度发展，这也就意味着它还完全没有稳定和成熟。容器运行时、镜像格式、编排工具和宿主机操作系统都有多种选项，每种选项都有自己的实用性、范围、推动力和社区支持。


反观其它产业，事物往往是在老旧和无聊之后才会真正的变得稳定。举个例子，在我们得到REST标准之前有多少协议被废弃？我们踩在SOAP和CORBA的尸体上构建了REST、AJAX和JSON，利用了曾经的经验教训构建了这些新的事物。这是过去十年两个重要的技术转换，但是我们到目前为止REST API还是没有十年前的SOAP那样有众多的工具，而SOAP现在还没有真正意义上的消亡。


在前端开发领域也存在同样的现象，很多人拿我的Docker生态系统文章跟shit-show that’s going on in frontend development（https://medium.com/@boopathi/it-s-the-future-7a4207e028c2）做对比。 在编程语言方面也存在类似的情形，在10年前出现了Java之后，开发人员一直在发明新的方案去解决新的问题。容器生态系统也有很多问题需要解决。


因此我们可以预期Docker现在还不成熟，在你尝试Docker的时候还会碰到很多的边界问题和奇怪的事情，而其中的某些决定在未来几年再往回看的时候是完全的错误。最佳实践就是一个反复试错的过程知道它变得正确。


这个过程会需要几年直到我们解决了所有这些问题。但是这并不意味着容器是垃圾，或者我们可以忽略它。我们会面临一个选择，是坚持使用已有的技术，或者尝试新的技术获取经验教训后迭代前进来改善和提升我们的产业。