毫无疑问，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么?
似曾相识的历史
如果说在这之前，还有哪项技术获得了类似的业界的广泛支持，我想是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对自身业务的影响。
Docker的架构
从上图，我们可以看到，容器由于省去了操作系统，整个层级更简化，可以在单台服务器上运行更多的应用，而这正是IaaS所需要的，可能5G右的空间，对你来说不是什么大事，但是如果你需要对外提供成千上万的主机，那就是不得了。
普通虚拟机将整个操作系统运行在虚拟的硬件平台上,进而提供完整的运行环境供应用程序运行,而Docker则直接在宿主平台上加载运行应用程序.本质上他在底层使用LXC启动一个Linux Container,通过cgroup等机制对不同的container内运行的应用程序进行隔离,权限管理和quota分配等每个container拥有自己独立的各种命名空间(亦即资源)包括:PID进程, MNT文件系统, NET网络, IPC, UTS主机名等。
传统虚拟化
若干年前，当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是非常适合部署在混合云中，并能够更好的发挥混合云的能力。
相比于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的生态系统产生重要影响，甚至很有可能从根本上改变开发、运维的协作方式，并对市场上已有的持续集成，持续部署的解决方案造成重大影响。
这段时间Docker实在是如日中天，到处都是它的信息，它是什么？你认为它解决了什么问题？有哪些应用场景？
我们先来了解一下传统上的程序开发流程，这样有助于更清晰地了解Docker.
而对于Docker，简单的说Docker是一个构建在LXC之上的,基于进程容器(Processcontainer)的轻量级VM解决方案拿现实世界中货物的运输作类比,为了解决各种型号规格尺寸的货物在各种运输工具上进行运输的问题,我们发明了集装箱。
Docker的初衷也就是将各种应用程序和他们所依赖的运行环境打包成标准的container/image,进而发布到不同的平台上运行。
从理论上说这一Dockercontainer概念并不新鲜,各种虚拟机Image也起着类似的作用。Docker container和普通的虚拟机Image相比,最大的区别是它并不包含操作系统内核。
Docker到底做了什么，这个问题显然没有标准答案，面试官只是想看看你是否有自己的想法，是否对新技术保持敏感，如果你的观点跟面试官不谋而合，绝对加分）。
关于docker解决的问题，下面都是笔者个人看法：
1、程序在我这跑得好好的，在你那怎么就不行呢？！
这是一个典型的应用场景，Docker image中包含了程序需要的所有的运行时依赖，比如java的程序，肯定要在image中包含jdk；比如Python的程序，肯定要在image中包含对应版本的Python解释器。程序在我这跑得好好的，去你那就不行了，显然是环境问题。Docker把整个运行时环境打包放到image中，所以搞定了环境依赖问题！
这点很重要么？真的很重要！如果你做过部署或发布系统将会对此感触颇深。
我们知道，一个程序要跑起来，需要这么几部分：代码 + 运行环境 + 配置 + 依赖的服务。代码当然就是同一份代码，不同的环境都一样，通常不会有问题，Docker image中包含了运行环境+配置，这对部署相当友好。如果你没有做过这种系统（其实大部分人都没有做过啦），但是你肯定装过软件，装一些复杂的软件的时候有没有因为版本依赖或者编译参数等让你抓狂？用了Docker再也没有这种问题了：
- docker pull xxx;
- docker run xxx;
- done:)
所以总结起来就是：Docker解决了运行环境和配置问题，方便发布，也就方便做持续集成。
2、系统好卡，肯定是又有哪个哥们的程序在作孽了
现在的服务器都牛的很，动不动128G内存，24个CPU，Linux本身就是个多租户的操作系统，可以多人共用，但是如果某个程序狂吃内存和CPU，占用了太多系统资源，这就会影响其他程序的运行。
一个公司的几个同事共用一台机器出现这种问题可以通过内部协调沟通解决。但是云主机提供商呢？不同的用户之间不认识，共用一台强大的计算机，结果某个程序耗尽了资源，用户肯定不乐意了。
所以虚拟机出现了，良好了做了资源隔离，不同用户之间彼此老死不相往来，不会相互影响，世界一下子清静了。但是，虚拟机有缺点：创建速度慢，迁移起来麻烦，因为中间加了一层guest os，有了性能损耗，一个牛逼的机器也就创建十几个虚拟机，太浪费了……
相对虚拟机的重量级虚拟化方案，Linux内核级的一些隔离方案让人们看到了希望，cgroups、namespace、tc、quota、chroot、lxc，终于，Docker出现了，Docker利用这些成熟的技术，让虚拟化变得轻量了起来，创建一个container瞬间完成，秒级！cpu指令集不再被翻译执行，性能损耗非常少，虽说隔离性没有虚拟机那么彻底，安全性上稍差一些，但也基本可以用，不用太担心：）
所以总结起来就是：更轻量的虚拟化，节省了虚拟机的性能损耗
上面两点是Docker解决的问题，那它有哪些应用场景呢？
其实从上面的描述中也基本可以窥其一二了
1、程序分发，gitlab的安装很恶心吧，所以有人做了gitlab的image
2、部署发布，这点对运维的同学很有帮助
3、PaaS，tsuru、flynn都是基于Docker的，CloudFoundry也要从warden迁移到Docker，不解释
写在后面的话
Docker正在面临Java之前所面临过的类似的挑战。鉴于Docker很可能打乱甚至颠覆现有市场，目前很多公司正在密切关注并且评估Docker对自身业务的影响，如果需要，我们相信这些公司会以不同方式向Docker公司施加影响。Docker公司在未来也许会变得更加谨慎。
但我们更愿意从另外一个角度来看，我们相信，以Docker为代表的这一类容器虚拟化技术已经取得长足进步，无论Docker公司本身未来如何，容器虚拟化技术的进步以及推广，必将带来深刻的产业影响。
参考文章：http://cloud.51cto.com/art/201409/452592.htm
http://www.raincent.com/content-10-3631-1.html
转自: https://blog.csdn.net/zhushuai1221/article/details/52486684
毫无疑问，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么?
似曾相识的历史
如果说在这之前，还有哪项技术获得了类似的业界的广泛支持，我想是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对自身业务的影响。
Docker的架构
从上图，我们可以看到，容器由于省去了操作系统，整个层级更简化，可以在单台服务器上运行更多的应用，而这正是IaaS所需要的，可能5G右的空间，对你来说不是什么大事，但是如果你需要对外提供成千上万的主机，那就是不得了。
普通虚拟机将整个操作系统运行在虚拟的硬件平台上,进而提供完整的运行环境供应用程序运行,而Docker则直接在宿主平台上加载运行应用程序.本质上他在底层使用LXC启动一个Linux Container,通过cgroup等机制对不同的container内运行的应用程序进行隔离,权限管理和quota分配等每个container拥有自己独立的各种命名空间(亦即资源)包括:PID进程, MNT文件系统, NET网络, IPC, UTS主机名等。
传统虚拟化
若干年前，当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是非常适合部署在混合云中，并能够更好的发挥混合云的能力。
相比于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的生态系统产生重要影响，甚至很有可能从根本上改变开发、运维的协作方式，并对市场上已有的持续集成，持续部署的解决方案造成重大影响。
这段时间Docker实在是如日中天，到处都是它的信息，它是什么？你认为它解决了什么问题？有哪些应用场景？
我们先来了解一下传统上的程序开发流程，这样有助于更清晰地了解Docker.
而对于Docker，简单的说Docker是一个构建在LXC之上的,基于进程容器(Processcontainer)的轻量级VM解决方案拿现实世界中货物的运输作类比,为了解决各种型号规格尺寸的货物在各种运输工具上进行运输的问题,我们发明了集装箱。
Docker的初衷也就是将各种应用程序和他们所依赖的运行环境打包成标准的container/image,进而发布到不同的平台上运行。
从理论上说这一Dockercontainer概念并不新鲜,各种虚拟机Image也起着类似的作用。Docker container和普通的虚拟机Image相比,最大的区别是它并不包含操作系统内核。
Docker到底做了什么，这个问题显然没有标准答案，面试官只是想看看你是否有自己的想法，是否对新技术保持敏感，如果你的观点跟面试官不谋而合，绝对加分）。
关于docker解决的问题，下面都是笔者个人看法：
1、程序在我这跑得好好的，在你那怎么就不行呢？！
这是一个典型的应用场景，Docker image中包含了程序需要的所有的运行时依赖，比如java的程序，肯定要在image中包含jdk；比如Python的程序，肯定要在image中包含对应版本的Python解释器。程序在我这跑得好好的，去你那就不行了，显然是环境问题。Docker把整个运行时环境打包放到image中，所以搞定了环境依赖问题！
这点很重要么？真的很重要！如果你做过部署或发布系统将会对此感触颇深。
我们知道，一个程序要跑起来，需要这么几部分：代码 + 运行环境 + 配置 + 依赖的服务。代码当然就是同一份代码，不同的环境都一样，通常不会有问题，Docker image中包含了运行环境+配置，这对部署相当友好。如果你没有做过这种系统（其实大部分人都没有做过啦），但是你肯定装过软件，装一些复杂的软件的时候有没有因为版本依赖或者编译参数等让你抓狂？用了Docker再也没有这种问题了：
- docker pull xxx;
- docker run xxx;
- done:)
所以总结起来就是：Docker解决了运行环境和配置问题，方便发布，也就方便做持续集成。
2、系统好卡，肯定是又有哪个哥们的程序在作孽了
现在的服务器都牛的很，动不动128G内存，24个CPU，Linux本身就是个多租户的操作系统，可以多人共用，但是如果某个程序狂吃内存和CPU，占用了太多系统资源，这就会影响其他程序的运行。
一个公司的几个同事共用一台机器出现这种问题可以通过内部协调沟通解决。但是云主机提供商呢？不同的用户之间不认识，共用一台强大的计算机，结果某个程序耗尽了资源，用户肯定不乐意了。
所以虚拟机出现了，良好了做了资源隔离，不同用户之间彼此老死不相往来，不会相互影响，世界一下子清静了。但是，虚拟机有缺点：创建速度慢，迁移起来麻烦，因为中间加了一层guest os，有了性能损耗，一个牛逼的机器也就创建十几个虚拟机，太浪费了……
相对虚拟机的重量级虚拟化方案，Linux内核级的一些隔离方案让人们看到了希望，cgroups、namespace、tc、quota、chroot、lxc，终于，Docker出现了，Docker利用这些成熟的技术，让虚拟化变得轻量了起来，创建一个container瞬间完成，秒级！cpu指令集不再被翻译执行，性能损耗非常少，虽说隔离性没有虚拟机那么彻底，安全性上稍差一些，但也基本可以用，不用太担心：）
所以总结起来就是：更轻量的虚拟化，节省了虚拟机的性能损耗
上面两点是Docker解决的问题，那它有哪些应用场景呢？
其实从上面的描述中也基本可以窥其一二了
1、程序分发，gitlab的安装很恶心吧，所以有人做了gitlab的image
2、部署发布，这点对运维的同学很有帮助
3、PaaS，tsuru、flynn都是基于Docker的，CloudFoundry也要从warden迁移到Docker，不解释
写在后面的话
Docker正在面临Java之前所面临过的类似的挑战。鉴于Docker很可能打乱甚至颠覆现有市场，目前很多公司正在密切关注并且评估Docker对自身业务的影响，如果需要，我们相信这些公司会以不同方式向Docker公司施加影响。Docker公司在未来也许会变得更加谨慎。
但我们更愿意从另外一个角度来看，我们相信，以Docker为代表的这一类容器虚拟化技术已经取得长足进步，无论Docker公司本身未来如何，容器虚拟化技术的进步以及推广，必将带来深刻的产业影响。
参考文章：http://cloud.51cto.com/art/201409/452592.htm
http://www.raincent.com/content-10-3631-1.html