1.概述
Docker能简化业务流程，降低沟通成本。
下面用一个部署的过程来说明问题。
2.传统应用部署（不使用Docker）
一般来说，把应用部署到生产环境通常需要下面这几步：
- 应用开发者请求运维工程师提供资源。
- 运维工程师配置好资源以后，把资源交给开发者。
- 开发者编写用于部署的脚本和工具。
- 运维工程师和开发者一起反复调整部署工具。
- 开发者发现应用需要使用额外的依赖。
- 运维工程师安装额外的依赖。
- 多次重复第5步和第6步。
- 应用部署好了。
由上图，根据开发的经验，把全新的应用部署到复杂的系统可能需要四五天的时间。这样的过程效率太低，就算开发运维人员不断练习，努力降低部署的难度，通常也需要投入很多精力，而且多个团队的人员之间要时常沟通。从专业角度看，这样的过程通常具有挑战性，而且浪费精力。更糟的是，这样的过程会降低开发团队日后的创新能力。如果部署软件很难、浪费时间、需要其他团队提供资源，开发者通常会吧所有东西都塞到现有的应用中，以此避免下次部署带来的痛苦。
3.提一下Heroku
Heroku这样的推送部署系统向开发者展示了，如果应用和大多数依赖都在自己的掌握之下，世界将变得多么美好。这对于开发者比较友好。但是对于运维工程师，部署到Heroku比起部署到自己的系统慢。
4.Docker式部署流程
Docker的目标不是变成Heroku这样的推送部署系统，不过Docker严格区分了各个团队的职责，能把依赖封装起来，这一样能提升效率。
Docker让开发者掌控一切，与Heroku相比，控制的粒度更细，连运行应用的操作系统发行版都能自行选择。
Docker公司推崇的是“功能内置但可换”的理念。也就是说，Docker公司希望推出的工具带有大多数人完成工作所需的各种功能，不过可以根据具体需求轻易更换各个功能模块。
Docker使用映像仓库作为中转站，把构建应用映像的职责与部署和操作容器的职责区分开了。
在实践中，这种处理方式意味着，开发团队可以连同应用的所有依赖一起构建应用，在开发环境和测试环境中运行以后，再把完全一样的应用和依赖构建包上传到生产环境。因为从外部看，所有构建包都一样，所以运维团队可以构建或安装标准的工具，用于部署和运行应用。
于是，上面的流程变成了这样：
- 开发者构建Docker映像，然后将其上传到注册处。
- 运维工程师提供配置容器的详细信息，配置资源。
- 开发者部署应用。
这样的部署流程是可行的，因为使用Docker后所有的依赖问题都能在开发和测试的过程中发现。应用做好初次部署的准备之后，上述流程就完成了。而且，在这样的流程中不需要开发团队和运维团队多次交接工作。因此，使用这种流程部署更加简单，能节省很多时间。更好的一点是，在发布之前测试部署环境能让软件能强健。