Docker到底影响了什么？

Docker到底影响了什么？作为2014年最火热的技术，Docker获得了国内外各大厂商的支持。本文中，云栈科技VP石海旭从传统虚拟化，CaaS（容器即服务），IaaS，PaaS，CMP，传统ISV，DevOps这几个角度，分析了Docker所产生的影响。

【编者按】作为2014年最火热的技术，Docker获得了国内外各大厂商的支持。本文中，云栈科技VP石海旭从传统虚拟化，CaaS（容器即服务），IaaS，PaaS，CMP，传统ISV，DevOps这几个角度，分析了Docker所产生的影响，以下为原文：

Docker，14年最火的词汇之一，引起了万千关注。在2014年边上，抛开种种技术性的内容和环节，我们觉得从更宏观的角度和大家分享我们对Docker的一些认识， 相对也许是个更轻松，更适宜的话题。

我们不敢妄言创造未来是预测未来的最好的方法，我们只是习惯性的给出我们的观点。毕竟，没有观点，就没有行动。

无处不在的Docker

 

毫无疑问，DocKer成了近些年来最火热，甚至最具颠覆性的技术之一。国际上，所有泛云计算相关的公司，几乎都在某种程度上宣布支持并集成Docker。在2014年6月的DockerCon中，很多公司都分享了他们自己如何和Docker集成的故事。虽然每家公司用着各自不同方式实现着不同程度的同Docker的集成，但他们都一致认识到了Docker可能会为他们带来的潜在收益。Microsoft，Amazon，IBM，Google，Facebook，Twitter，Red Hat，Rackspace和Salesforce等诸多公司共聚一堂，共同支持某一技术的场面似乎也不是我们经常能看到的。同时，国内众多泛云计算公司，互联网公司，甚至相对传统的IT厂商也对Docker多有关注。

 

为什么像Microsoft或者Amazon这样的巨头会支持Docker？
为什么像之前的PaaS玩家，如Heroku和Google，也在Docker身后，摇旗呐喊？
Docker的出现，是不是为所有的这些厂家提供了一个新的领域，新的竞技场？
Docker真的能融合IaaS和PaaS么？
我们又真的能相信上面的提到的厂家会持续的无条件的支持Docker么？

 

这一系列的问题，在已经过去的2014年并没能给出答案，但在2015，相信一切会逐渐明朗。

似曾相识的历史

如果说在这之前，还有哪项技术获得了类似的业界的广泛支持，我想是Java。当Java在上世纪90年代发布的时候，每一家公司都表示了极大的兴趣，直到他们意识到Java实际上对他们自有的平台其实是一种巨大威胁。Java的愿景是“Write Once，Run Anywhere”， 而Docker提出了“Build once，Run anywhere，Configure once，Run anything”。很大程度上，二者都对某些公司形成了潜在的威胁。尽管我们目前还看不到具体的一些公司针对可能的威胁采取的应对措施，但未来是谁也无法保证类似Java或VMware的历史不会重演。

目前，实际上泛云计算领域一些重量级厂家，无论是IaaS厂家， VM厂家还是SaaS厂家，无论是国际公司，还是国内企业，都在持续密切关注Docker，并评估Docker对自身业务的影响。

传统虚拟化

若干年前，当VMwae刚刚开始提供工作站虚拟化服务的时候，也许很少有人能想到它现在能成为企业IT服务中的主要力量，能取得现在的成就。随后的几年内，VMware已经将虚拟化扩展到服务器，而现在更是已经扩展到云计算领域。对于Docker及其生态系统而言，借鉴传统虚拟化的经验，最终提供更安全，更健壮的生产环境的服务也应是Docker的目标之一。事实上，目前在裸机上直接运行Docker也成了传统VM之外的另一种选择。

坦率的讲，相较传统虚拟化而言，Docker的一系列的问题仍亟待解决，如缺乏成熟的管理工具，生态系统虽大但仍不完善。但我们仍然认为，Docker或者说容器虚拟化技术仍有很大机会能够解决这些问题，并最终取得相当的成功。

CaaS：容器即服务？

目前，已经有一些新兴公司，以有些类似IaaS的方式，提供容器服务（Containers as a Service）。长远来看，也许CaaS的这种模式的出现，会使跨IaaS平台的动态调度容器、移动容器成为可能。就像IaaS的客户不需要关心其虚拟机的实际品牌一样，CaaS的客户也不需要关心他的容器到底是运行在AWS还是阿里云上。客户将会自己选择期望的地理位置，以及他们想要的容器运行，然后CaaS服务商将提供自动化的程序帮助进行资源调配，帮助客户选择最便宜的或最合适的公有云平台。

尽管这种在IaaS之上提供Docker容器的商业模式仍待讨论和观察，但Docker已经取得了巨大的影响力，如果Docker今后能在更多的企业，特别是企业的实际生产环境中发挥作用，我们认为CaaS同样是可以期待的。

对IaaS厂家的影响

从创业公司到IT巨头，每一家公司都已经意识到或者逐渐意识到基于硬件的虚拟化的所为企业带来的益处。公有云厂商，如AWS、Azure所提供的IaaS服务更多越来越像水、电、煤等公共服务。而Docker的出现，则便于这些IaaS厂商提供更细粒度计算资源，进一步提高资源利用率，缩短资源开通时间，进而为进一步压缩公共云服务的成本提供了可能。对于如负载平衡、缓存和防火墙这些其他的IAAS的提供的服务而言，也可通过将其迁移到容器中，以提供更好的可移植性。

同时，对于混合云而言，VMware vCHS（vCloud Hybrid Service）和微软 Azure都在各种强调自身VM的可迁移性。而事实上，由于容器相比传统的VM更轻量，Docker容器可以动态地设置和迁移。从资源的利用率和可用性的而言，Docker是非常适合部署在混合云中，并能够更好的发挥混合云的能力。

对PaaS厂家的影响

相比于IaaS，PaaS实际上起步更早。PaaS的初衷最是为了帮助开发人员实现够资源的自动调整，而不必面对IT基础设施管理的问题。早些时候，人们曾经预计PaaS将超越 IaaS，成为云计算领域中增长最快的市场。但几年后，由于Amazon在IaaS领域的巨大成功，使得早期的PaaS玩家，如Microsoft和Google意识到，IaaS相比PaaS而言，壁垒较低，更容易取得市场的认可。所以现在Microsoft和Google除了在原有的PaaS领域外，在IaaS领域也和Amazon展开了激烈竞争。

就PaaS而言，PaaS厂商希望提供规范、一致的环境，而企业应用，无论是从开发、管理还是运维上都有各种个性化的需求。二者之间这种很难克服的冲突阻碍了市场的对PaaS的认可和接受。另外，每一PaaS厂商都在为应用提供各自的服务和API，这就造成了应用在PaaS厂商之间的移植是很困难的。一些组织在PaaS的迁移方面做了积极尝试，甚至希望能实现跨云服务提供商的迁移。但是由于没能得到类似Google App Engine和Microsoft Azure这样的厂家支持，目前这些工作还还很难成为事实上的行业标准。

Docker的出现使PaaS以更简洁的方式为开发者提供服务成为了可能，Cloud Foundry目前也开始支持并集成Docker容器。有了Docker，开发人员不再需要为处理各种开发、 测试、生产环境的差异而花费大量精力，他们可以将一个干净的开发环境直接迁移到生产环境，而不必担心各种依赖和配置问题。这有效的解决了开发者经常面临的“依赖陷阱”。开发者不再需要为了使应用能够在PaaS中运行而学习额外的编程方式，他们的应用不需任何调整就可运行在Docker容器中。同时，Docker出现之后，开发者越来越多的考虑以Micro Service（微服务）的方式来实现他们的应用。长远来看，Docker将会使PaaS更易管理，更快地提供服务。

总体上说，Docker已经对仍在不断变化、演进的PaaS市场产生了影响。但这种影响究竟会加速PaaS的演进，打乱PaaS的演进，还是兼而有之，目前言之尚早。尽管目前还不是非常成熟，但Docker通过容器级虚拟化的方式，仍为乐于尝试的企业提供了一个解决环境依赖和可移植性问题的方案。

跨云的管理工具

多云管理软件通常被称为云计算管理平台 （CMP）。CMP通过对底层云平台的抽象， 帮助客户来定义应用部署的拓扑结构。这种拓扑结构是独立于具体的云提供商或者云平台的。客户可以通过CMP来选择的具体的某一云平台来部署自己服务。通过CMP，客户永远不必处理具体某一云平台的特定的用户界面或API。这样，通过CPM，会把所有的云平台置于一个相同的公平竞争环境。

为避免被具体的云平台绑定，CMP一般只使用云平台提供的基础的计算单元，数据块存储，对象存储网络服务。一些CMP还将将自己的负载均衡、 数据库服务和应用服务部署到每个云平台。这样会进一步避免将应用绑定到具体某一云平台。举例来讲，当客户在AWS上进行灾难恢复的时候，通过CMP，他们也可以选择在自己的基于传统VM的私有云环境中运行他们的应用。

在很多方面，Docker提供了类似CMP的跨平台移植能力。客户可以通过Dockerfile声明一个Docker镜像和相关的拓扑结构，并把镜像build到具体的云平台中。与CMP类似，通过Docker，也可以将额外管理所需的网络、数据库等服务以容器的方式部署，进而满足各种具体的需要。

同时，一些新的基于Docker的管理工具也提供了多云平台的容器管理功能。事实上，这同CMP的功能有所重叠，而一些CMP厂家也正在评估Docker的影响。

像PaaS一样，我们不确认Docker到底会增加对CMP的需求，抑或反之？

同时，Docker的出现会不会让应用的故障追踪以及处理变得更复杂？而云计算管理平台会不会集成对Docker的管理？?

对传统ISV的影响

对于传统ISV而言，在整个SDLC（Systems Development Life Cycle）环节中引入Docker，可能会成为一种趋势。Docker的引入，除了在ISV内部的开发、测试中会极大的解决配置依赖等问题，进而提升整体效率。 我们认为，以容器为核心的持续集成和持续交付，最终将容器作为ISV向客户、向客户的云平台交付的实体，对于ISV及其客户而言，都会有很大的效率提升。

虽然目前，我们不清楚究竟是更多的ISV向其客户推荐了Docker，还是更多客户要求ISV基于Docker进行开发，还是两种可能都会有。但我们相信，Docker在企业应用市场，类似之前的VMware，会得到广泛应用。

对DevOps的影响

目前市场上虽然有很多各种各样的DevOps工具，希望帮助解决开发人员和运维人员之间的Gap。但Docker的出现，事实上提供了一种同Devops理念非常契合的框架。基于Docker：

 

开发人员可以更专注于他们的代码，而不用担心如何在生产环境中运行他们；
运维团队在部署的时候，可以视容器为一个独立的完整的模块；
Docker分层的文件系统，使环境配置易于管理、维护；
像Git工作流一样，通过Dockerfile，即便是复杂、异构的开发、测试环境，仍然可以高效的管理；
即便在同一个VM中，多个容器仍能运行多种不同的环境；
…..

 

我们认为Doker很有可能会对Devops的生态系统产生重要影响，甚至很有可能从根本上改变开发、运维的协作方式，并对市场上已有的持续集成，持续部署的解决方案造成重大影响。

事情总是会前进的，虽然并不一定以我们想象的方式