Docker技术引发开发流程再造
举个简单的应用场景的例子。
假设用户试图基于最常见的LAMP（Linux + Apache + MySQL + PHP）组合来运维一个网站。按照传统的做法，首先，需要安装Apache、MySQL 和PHP以及它们各自运行所依赖的环境；之后分别对它们进行配置（包括创建合适的用户、配置参数等）；经过大量的操作后，还需要进行功能测试，看是否工作正常；如果不正常，则意味着更多的时间代价和不可控的风险。可以想象，如果再加上更多的应用，事情会变得更加难以处理。 更为可怕的是，一旦需要服务器迁移（例如从阿里云迁移到腾讯云），往往需要重新部署和调试。这些琐碎而无趣的“体力活”，极大地降低了工作效率。
而Docker提供了一种更为聪明的方式，通过容器来打包应用，意味着迁移只需要在新的服务器上启动需要的容器就可以了。这无疑将节约大量的宝贵时间，并降低部署过程出现问题的风险。
Docker在开发和运维中的优势
对开发和运维（DevOps）人员来说，可能最梦寐以求的就是一次性地创建或配置，可以在任意环境、任意时间让应用正常地运行。而Docker恰恰是可以实现这一终极目标的瑞士军刀。
具体说来，Docker在开发和运维过程中，具有如下几个方面的优势。
更快速的交付和部署。使用Docker，开发人员可以使用镜像来快速构建一套标准的开发环境；开发完成之后，测试和运维人员可以直接使用相同环境来部署代码。Docker可以快速创建和删除容器，实现快速迭代，大量节约开发、测试、部署的时间。并且，各个步骤都有明确的配置和操作，整个过程全程可见，使团队更容易理解应用的创建和工作过程。
更高效的资源利用。Docker容器的运行不需要额外的虚拟化管理程序（Virtual Machine Manager，VMM，以及Hypervisor）支持，它是内核级的虚拟化，可以实现更高的性能，同时对资源的额外需求很低。
更轻松的迁移和扩展。Docker容器几乎可以在任意的平台上运行，包括物理机、虚拟机、公有云、私有云、个人电脑、服务器等。 这种兼容性让用户可以在不同平台之间轻松地迁移应用。
更简单的更新管理。使用Dockerfile，只需要小小的配置修改，就可以替代以往大量的更新工作。并且所有修改都以增量的方式进行分发和更新，从而实现自动化并且高效的容器管理。
Docker技术方案的发展势头简直如同一场燎原烈火。这项新型Linux容器技术在不可阻挡的前进道路上引燃了一切事物，而其进展速度之快令很多从业人员根本无法跟上其迅猛的脚步。Docker不仅是有史以来人气最高的开源项目之一，同时也已经给人们构建应用程序的方式带来了根本性变革。
基于Docker的应用程序背后所暗含的很多解决思路从严格意义上讲已经与最初有所不同，但Docker确实给这些陈旧的的观念带来了新鲜活力。借助大量云部署实践机制，Docker鼓励技术人员采用像12-Factor应用那样的最初实践手段——这是一套专门用于构建基于PaaS应用程序的方案，目前也已经适用于基于Docker应用的开发工作。
微服务架构的崛起
大规模整体性云应用程序开发已经步入绝路。如今它开始被微服务架构所取代，其特色在于将大型应用程序——及其全部内置功能——拆分成更小的、目的驱动型服务，并通过通用REST API实现彼此之间的通信。
早在上世纪九十年代就曾经出现过名为基于接口/组件架构的类似概念。时至今日，SOA（即面向服务架构）似乎已经获得了相当良好的发展势头。目前微服务概念已经在Docker社区当中成为标准性模因，其主流趋势在于将应用程序拆分成解耦、极简且专门针对容器机制的设计方案，且只专注于实现一项任务。
完全密闭的Docker容器机制能够为微服务应用程序创建出高效的分布式模型，从而顺利实现微服务概念的现实转化。这彻底改变了长久以来的云开发实践思路，能够将像Facebook及Twitter那样的超大规模架构加以拆分并提供给规模更小的多个开发团队。
让开发（Dev）与运营（Ops）联系得更为紧密
尽管Puppet、Chef、Salt以及其它先行者已经在DevOps的探索中作出了相当的贡献，但这些工具的主要活动舞台仍然集中在运营团队而非开发者群体当中。
Docker是第一款能够在开发人员群体中获得与运营工程师同等认可效果的DevOps工具。为什么会这样？因为开发人员可以在容器机制内部工作，而运营工程师则能够在容器外部以并行方向处理自己的任务。
当开发团队采纳Docker的同时，他们相当于在软件开发生命周期当中添加了新的敏捷性层。容器技术最大的突破就在于其一致性。基于Docker的应用程序能够在笔记本电脑与生产环境下获得同样的运行效果。由于Docker将与应用程序相关的所有状态都封闭了起来，因此大家根本用不着担心底层操作系统的架构差异会给应用程序的运行依赖性带来影响、或是产生新的漏洞。
保障持续集成的一致性
持续集成机制能够自动对代码进行测试，并借此成为尽可能降低最终产品中漏洞数量的一大理想途径。不过持续集成仍然存在着两大弊端。
首先，持续集成机制很难将所有依赖性加以封装。以Jenkins以及Travis为代表的传统持续集成/持续交付技术通过建立源代码库的方式分段实现应用程序开发。虽然这种处理方式对于很多应用程序来说并不是问题，但二进制依赖性或者操作系统层面的变化仍然难以避免，这就使得代码在生产环境中的实际运行效果同开发/测试/质量保证阶段有所不同。相比之下，Docker由于可以将应用程序的整体状态加以封装，因此能够保证代码在生产环境中拥有与开发/测试/质量保证阶段相一致的实际效果。
第二，持续集成并非专为微服务架构所构建。持续集成的设计思路其实是假设将一款应用程序锁定在单一代码库当中。然而Docker最佳实践能够提供大量彼此间松散耦合的Docker容器，而这对于微服务架构来说可谓最佳拍档。由此也衍生出了一系列新一代持续集成/持续交付工具，以Drone与Shippable为代表的这些新型解决方案都在开发之初就将Docker容器机制作为其立足根基。具体而言，这些工具允许大家对涉及多套代码库的多容器应用程序加以测试。
让各类最佳容器机制实现协作
Docker并不主张大家将自己的服务容器按照Hadoop、Nginx或者MongoDB这样的现有方案进行调整，而是鼓励我们通过开源社区实现协作、并凭借Docker Hub这套公共库进行容器改进，从而让每个人都能用到最出色的容器设计成果。由于Docker容器能够将应用状态封装于其中，因此大家完全能够以更灵活的方式对软件加以配置、保证其拥有最佳运行效果。
有鉴于此，Docker凭借着这种允许每个人利用现成最佳实践方案根据具体需求任意组合及对接的能力彻底改变了传统云开发机制。这有点像是将云组件当成乐高积木，并最长按照一定的标准将它们组合起来。
云计算领域的乐高积木
每一项新技术的出现都可能会对现有局面带来颠覆性的影响。就目前而言，云一直由按需供应、API驱动虚拟机以及围绕虚拟机建立服务等要素所支撑。由此带来的弊端在于，所有针对现有机制打造的工具都会受到虚拟机局限性的严重束缚。
Docker正在迅速改变云计算领域的运作规则，并彻底颠覆云技术的发展前景。从持续集成/持续交付到微服务、开源协作乃至DevOps，Docker一路走来已经给应用程序开发生命周期以及云工程技术实践带来了巨大变革。每一天都有成千上万名新的开发者兴高采烈地参与到原有应用重构或者全新Docker应用开发的相关工作中来。而了解Docker之火能够快速呈现燎原之势的理由，正是在这个不断变化的技术世界中保持竞争优势的关键所在。