聚焦PWorld2015议题 平安健康架构师谈Docker

做为容器技术的代表，Docker已经逐渐获得了企业的认可。之前就有报道称，国内的新浪微博、雪球网等互联网公司都在生产环境中成功使用了Docker。而对于一些传统公司，他们的IT设施薄弱、应用架构复杂，在拥抱Docker时，可能遇到的问题相对较多。应该如何理解Docker的性质和特点？应用Docker能够解决哪些问题，在实践应用中还需要注意哪些问题？今年5月26日和6月11日，普元与InfoQ共同主办的2015年PWorld 软件架构&平台创新大会上，汇聚在北京和上海的业内技术大牛们将一起共同深度探讨这些问题的答案。

日前，我们带着这些问题前期采访了将在6月11日的PWorld软件架构&平台创新大会（上海站）上分享题为《基于Docker的开发、运维一体化实践》主题演讲的平安健康互联网技术平台资深架构师王延炯，请他介绍自己的Docker应用与实践经验。

问：您认为Docker最大的优势是什么？当时公司为什么决定使用Docker？

王延炯：Docker优势有几点，首先是轻量级，其次是面向管理透明，最后是生态环境正在逐步建立、社区活跃。轻量级的容器这点，是大家都公认的优势，我不做过多解释。而面向管理透明主要是指Dockerfile与AUFS的结合，使得软件的运行环境面向开发、测试、运维团队变得透明。而Registry是平台软件云化的特征之一。另外，Docker的迅速发展，与其生态环境的蓬勃发展是相辅相成的，例如有Jenkins、Ansible等一系列面向CI以及运维友好的工具平台迅速支撑。

我们公司面向技术平台的选型，还是比较开放的，各个团队可以选择适合自己的平台，可以尝试新技术，但目的只有一个，提高公司整体的运营效率。选择Docker，一方面因为是以上提到的几个优势点，另外它也是虚拟化（如Xen/KVM）技术、容器技术两者并行发展过程中，沉淀出一套适合于公司特点本身，需要取长补短、逐步形成一套最佳实践的必经之路。

Docker技术本身还是在不断的发展之中，作为一个新技术，它的出现改变了很多原有软件研发的流程。将其应用到生产环境，第一，对大公司而言是需要公司整体进行调整，不仅仅是技术本身，还有配套的组织结构、管理制度与流程相结合；第二，Docker本身的网络、存储、监控等技术领域的关键问题还需要进一步的验证和实践，才能够将其应用到相应的生产环境。第三，生产环境的安全等级（包括稳定性要求），也是根据不同的业务等级会有不同的要求，一些低等级的生产环境，使用Docker是没有任何问题的。

问：那在应用Docker后，你们内部在组织结构、管理制度上做了怎么样的调整？

王延炯：在开发测试过程中，相关团队经常会找运维团队分配一些开发机、测试机。而分配主机只是第一步，相伴而来的还有一些配置工作，例如运行期所需要的域名等等。

当然，除了Docker之外，如果用KVM、Xen等虚拟化技术，也可以实现分配。但需要注意的是，使用虚拟化技术所分配出来的主机资源，基本上要比使用Docker技术分配出来的主机资源少一个数量级，甚至更多。最直观的感受就是，在相同物理宿主机条件下，可以分配更多的“主机”了。这样给软件交付所带来的好处（这也是Docker所倡导的）是一个容器内只运行一个进程。每个应用系统，纵向前后台分离、横向多实例负载聚合，运行期的每个实例都可以不受干扰的运行在一个独立的环境之中。

初看这只是一个量变的过程，但到一定程度就变成了质变，相同大小的运维团队所要维护的“主机”数，可能就多了一个数量级。所以使用Docker之后，在组织结构和管理制度上，运维团队只要在平台层面提供Docker资源池，由各个项目的开发，或者测试负责人，自行在资源池内分配主机资源。所有动作都在Web界面完成，并且有简单的工作流审批，减少资源滥用。

问：你们的Docker应用场景是怎么样的？能介绍下你们所使用的技术栈吗？

王延炯：关于Docker应用场景，目前各个技术团队都根据自身的特点进行应用，大体上主要将Docker应用于开发、测试环境，不同的场景使用的技术栈也有区别。

在开发测试环境会使用SaltStack等技术对容器进行集中化管理，其主要使用方式较为传统，主要为开发测试人员提供主机（操作系统）级服务，这与整个团体的软件研发过程息息相关。

在SCM/CI平台，有相当大一部分开源工具已经由社区实现了Docker化，能够方便的将代码与数据分离，使得平台能够进行快速升级、二次开发与定制。

在细节方面，诸如IP地主与主机名、IP地址（DHCP）与域名都进行了一定程度的二次开发与集成，目前可以实现Docker容器实例、主机名、域名绑定的Web端一键式自助分配与注册。

问：可否详细聊聊你们基于Docker的workflow吗？

王延炯：关于Docker的workflow，如之前提到的，有基于Web端的一键式主机（也就是Docker容器）分配平台，支持开发、测试环境的主机自动创建、IP分配、域名绑定，并包含与组织结构的审批流程。

另外，在我团队所使用的Docker环境中，会将Docker与Jenkins/GitLab等平台工具相结合，一方面将代码固化至Docker镜像中，一方面将配置文件作为数据分离到镜像之外。这样做的好处是，在一些无状态的业务逻辑服务中，往往只需要『代码+环境配置』，就可以部署到不同的运行环境中。例如同一份代码，与不同的开发、功能测试、性能测试环境配置相结合（docker -v参数），就能够快速部署相应的服务实例，并且可以与Docker自带的restful接口做集成，甚至是使用IntelliJ 14.1的Docker插件，能够做到从IDE到目标环境的一键式快速发布与部署。需要注意的是，这样做需要把程序的所有配置做尽可能地集中化处理，并且以Key-Value格式，降低错误几率。

问：Docker有很多的坑，你们的应用过程中是不是也遇到了？可以和大家分享下你印象深刻的几个坑吗？

王延炯：Docker的坑，在实际最多的还是集中于网络。大多数的使用场景，还是需要解决容器在不同的宿主机之间的可达性，这是决定Docker应用范围的第一步。简单的使用端口映射，往往不能够解决运行期的端口动态监听和容器间互联。

另外，Docker的性能监控，也是决定Docker应用于什么样等级的业务系统的关键因素，这也是近期除了网络之外主要深耕的一个领域。目前还没有对Docker进行代码级的优化和hack，侧重点还是在团队的整体运行效率、软件过程效率、业务持续交付中。

问：Docker最适合微服务架构的应用，像传统非互联网公司的IT系统，应该很多应用都不是这样的架构。你们是如何过渡和应用的？有什么好的经验分享吗？

王延炯：首先，我们要回想一下到底什么是微服务或者叫微应用。我个人认为所谓微服务或者微应用，尤其在传统重业务的非互联网领域，其定位应当是一些非核心系统，或者是一些业务创新驱动的服务或应用，或者是一些架构于核心系统之上的组合、集成性质的轻应用。在技术层面，他们的特征是代码量小，随着业务快速变化可以迅速升级。而相对的，大平台不仅仅是指一个技术平台，广义上应当是一个以各种技术标准进行兼容和统一为基础，并提供多类型的业务平台，需要有效、高效支撑上层的微应用和微服务的繁衍。随着时间的推移和业务的发展，一些微服务、微应用，可以被吸收、沉淀至大平台中，发挥更大的作用。

其次，对于传统公司而言，我并不建议为了追求新鲜的技术而一定要向Docker之类的『时鲜平台』进行迁移，保障复杂业务的稳定性才是重中之重。像Docker之类的新技术，可以采取『农村包围城市』的策略，先在外部非核心系统试点，根据企业自身的开发、测试、运维的特点，积累和沉淀出一套适合自己的平台的方法经验论，当然其指导原则就是高效可靠。需要注意的是这个过程可能是漫长的，需要技术主导，也需要组织保障。

第三，我们可以发现，就Docker技术本身而言，它提供的是一个轻量级的容器，并没有集成每个企业所确立的容器基础设施基线。而企业的基础镜像一般只是一个操作系统级的容器（公有社区的Registry，不在此讨论范围之内），在此基础之上，我们可以在Dockerfile里面，透明的定义具体应用或者服务所需要的本地运行环境（例如JDK、Node.js、Python等等），加之以具体的服务、应用，在运行期形成一个服务或应用的实例。。

第四，从企业架构而言，一个服务或者应用往往需要其它中间件的支持（如数据库、缓存、分布式文件系统），也需要集群高可用的部署。这就牵扯到集群拓扑（有静态也有动态的），包括纵向的从上层应用到底层的硬件物理设施，横向的多实例负载均衡与备份。一个完备的企业级容器平台，还需要有实时的监控和管理手段来辅助。Docker本身，并不提供这些企业级运维工具或者来支撑，都需要基于开源工具进行集成和定制开发。

可以看到，把以上所有问题都解决了，对于传统企业，尤其是传统非互联网大型企业，Docker的大范围推广才具备可行性。Docker是否在企业里能够推广，用短板模型来衡量的话，这个短板应该是在运维团队，并不是在开发团队。