docker应用场景和开发方向（docker和虚拟机的区别）

过去的几年时间，科技发生了巨大变化，从物理服务器到虚拟服务器，再到拥有PaaS环境的云计算。不论是否采用了全新架构，Docker镜像都可以在当前环境中很容易地被使用。要使用Docker，并不需要立即从单体应用程序迁移到面向服务架构。有很多用例允许在不同层次上集成Docker。

Docker常用于以下场景。

使用以镜像为基础的部署方式取代类似Capistrano的代码部署系统。安全地在同一台服务器中运行遗留应用和新应用。使用一个工具链循序渐进地迁移到面向服务架构。管理云端或裸机上的水平扩展性和弹性。确保从开发环境到预演环境到生产环境跨环境的一致性。简化开发人员的机器设置和一致性。

将应用的后台程序迁移到Docker集群中，同时保持网页服务器和数据库服务器不变是开始使用Docker的常见示例。另一示例是将应用的部分REST API迁移到Docker中运行，前端使用Nginx代理在遗留服务和Docker集群之间路由通信。通过使用此类技术，团队可以渐进式地从单体应用无缝地迁移到面向服务架构。

如今的应用程序往往需要几十个第三方库，用于加速功能开发或连接第三方SaaS和数据库服务。每个库都可能产生bug，或是让用户陷入版本依赖的泥沼。再加上库的频繁更改，要在基础设施上完成工作代码的持续部署而不引起失败，压力巨大。

Docker可贵的镜像思想使得技术团队在部署工作代码时，不论是单体架构、面向服务或是二者的混合，由于代码及其依赖项捆绑在同一个镜像中，所使用的方式对每次部署都是可测试、可重复、文档化且一致的。一旦一个镜像构建完毕，就可以部署到任意多个运行着Docker守护进程的服务器上。

另外一个常见的Docker用例是跨环境部署一个单一容器，其典型的代码路径是从开发环境到预演环境再到生产环境。容器为整个代码路径提供了一个一致的、可测试的环境。

作为一个开发人员，Docker模型允许在其个人电脑上调试与生产环境完全一致的代码。开发人员可以很容易地下载、运行和调试有问题的生产环境镜像，且无需事先对本地开发环境进行修改。

在生产环境中运行Docker容器困难不小，但还是能实现的。每天都有越来越多公司开始在生产环境中运行Docker。如同所有的基础设施一样，我们建议以小规模入手，然后渐进式地完成迁移。

为什么在生产环境中运行Docker如此困难

Docker对生产环境有很多要求：安全可靠的部署、健康检查、最小或零停机时间、从失败中恢复的能力（回滚）、一个集中存储日志的方式、一种分析或调试应用的方式，以及一种聚合监控参数的方式。类似Docker这样的新技术虽然使用起来非常有趣，但还需要时间来完善。

Docker在可移植性、一致性以及打包具有众多依赖的服务方面非常有优势。多数团队会因为以下一个或多个痛点而坚持使用Docker。

一个应用的不同部分使用大量不同的依赖。支持使用旧依赖的遗留应用程序。开发团队与DevOps之间的工作流问题。

警示：切勿尝试在一个组织内让采用Docker这事一蹴而就。即便运维团队已经为采用Docker做好了充分的准备，也请记住，过渡到Docker通常意味着将管理依赖的重任推给了开发人员。虽然很多开发人员都渴求这种自主权，以便加快迭代，但并非每位开发人员都有能力或兴趣将其列入自己的责任范围。为了能有一个良好的Docker工作流，还是需要花些时间来转变企业文化。

本文节选自《Docker生产环境实践指南》

本书围绕“Docker该如何应用到生产环境”这一核心问题展开。在本书中，读者将接触到多个IT企业应用Docker到生产环境的成功案例，了解Docker实际投产时将会面临的问题，以及它与现有基础设施存在的矛盾与冲突，了解构建Docker生态系统所需的配套设施，包括安全、构建镜像、持续集成/持续交付、镜像存储、配置管理、网络实现、服务发现、持久化存储以及日志监控等模块的具体选型方案及利弊所在。本书编写时一些案例参考的Docker版本是Docker 1.6或Docker 1.7。

本书要求读者具备一定的容器管理和运维的基础知识，适合在生产环境中使用Docker的相关技术人员阅读，尤其适合具有中高级DevOps和运维背景的读者阅读。