做为容器技术的代表，Docker已经逐渐获得了企业的认可。之前InfoQ就有报道过，国内的新浪微博、雪球网等互联网公司都在生产环境中成功使用了Docker。而对于一些传统公司，他们的IT设施薄弱、应用架构复杂，在拥抱Docker时，可能遇到的问题相对较多。为此，InfoQ采访了平安健康互联网技术平台资深架构师王延炯。另外，王延炯将在6月11日的PWorld 软件架构&平台创新大会上分享题为《基于Docker的开发、运维一体化实践》的主题演讲。
InfoQ：您认为Docker***的优势是什么？当时公司为什么决定使用Docker？
王延炯：Docker优势有几点，首先是轻量级，其次是面向管理透明，***是生态环境正在逐步建立、社区活跃。轻量级的容器这点，是大家都公认的优势，我不做过多解释。而面向管理透明主要是指Dockerfile与AUFS的结合，使得软件的运行环境面向开发、测试、运维团队变得透明。而Registry是平台软件云化的特征之一。另外，Docker的迅速发展，与其生态环境的蓬勃发展是相辅相成的，例如有Jenkins、Ansible等一系列面向CI以及运维友好的工具平台迅速支撑。
我们公司面向技术平台的选型，还是比较开放的，各个团队可以选择适合自己的平台，可以尝试新技术，但目的只有一个，提高公司整体的运营效率。选择Docker，一方面因为是以上提到的几个优势点，另外它也是虚拟化（如Xen/KVM）技术、容器技术两者并行发展过程中，沉淀出一套适合于公司特点本身，需要取长补短、逐步形成一套***实践的必经之路。
Docker技术本身还是在不断的发展之中，作为一个新技术，它的出现改变了很多原有软件研发的流程。将其应用到生产环境，***，对大公司而言是需要公司整体进行调整，不仅仅是技术本身，还有配套的组织结构、管理制度与流程相结合；第二，Docker本身的网络、存储、监控等技术领域的关键问题还需要进一步的验证和实践，才能够将其应用到相应的生产环境。第三，生产环境的安全等级（包括稳定性要求），也是根据不同的业务等级会有不同的要求，一些低等级的生产环境，使用Docker是没有任何问题的。
InfoQ：那在应用Docker后，你们内部在组织结构、管理制度上做了怎么样的调整？
王延炯：在开发测试过程中，相关团队经常会找运维团队分配一些开发机、测试机。而分配主机只是***步，相伴而来的还有一些配置工作，例如运行期所需要的域名等等。
当然，除了Docker之外，如果用KVM、Xen等虚拟化技术，也可以实现分配。但需要注意的是，使用虚拟化技术所分配出来的主机资源，基本上要比使用Docker技术分配出来的主机资源少一个数量级，甚至更多。最直观的感受就是，在相同物理宿主机条件下，可以分配更多的“主机”了。这样给软件交付所带来的好处（这也是Docker所倡导的）是一个容器内只运行一个进程。每个应用系统，纵向前后台分离、横向多实例负载聚合，运行期的每个实例都可以不受干扰的运行在一个独立的环境之中。
初看这只是一个量变的过程，但到一定程度就变成了质变，相同大小的运维团队所要维护的“主机”数，可能就多了一个数量级。所以使用Docker之后，在组织结构和管理制度上，运维团队只要在平台层面提供Docker资源池，由各个项目的开发，或者测试负责人，自行在资源池内分配主机资源。所有动作都在Web界面完成，并且有简单的工作流审批，减少资源滥用。
InfoQ：你们的Docker应用场景是怎么样的？能介绍下你们所使用的技术栈吗？
王延炯：关于Docker应用场景，目前各个技术团队都根据自身的特点进行应用，大体上主要将Docker应用于开发、测试环境，不同的场景使用的技术栈也有区别。
在开发测试环境会使用SaltStack等技术对容器进行集中化管理，其主要使用方式较为传统，主要为开发测试人员提供主机（操作系统）级服务，这与整个团体的软件研发过程息息相关。
在SCM/CI平台，有相当大一部分开源工具已经由社区实现了Docker化，能够方便的将代码与数据分离，使得平台能够进行快速升级、二次开发与定制。
在细节方面，诸如IP地主与主机名、IP地址（DHCP）与域名都进行了一定程度的二次开发与集成，目前可以实现Docker容器实例、主机名、域名绑定的Web端一键式自助分配与注册。
InfoQ：可否详细聊聊你们基于Docker的workflow吗？
王延炯：关于Docker的workflow，如之前提到的，有基于Web端的一键式主机（也就是Docker容器）分配平台，支持开发、测试环境的主机自动创建、IP分配、域名绑定，并包含与组织结构的审批流程。
另外，在我团队所使用的Docker环境中，会将Docker与Jenkins/GitLab等平台工具相结合，一方面将代码固化至Docker镜像中，一方面将配置文件作为数据分离到镜像之外。这样做的好处是，在一些无状态的业务逻辑服务中，往往只需要『代码+环境配置』，就可以部署到不同的运行环境中。例如同一份代码，与不同的开发、功能测试、性能测试环境配置相结合（docker -v参数），就能够快速部署相应的服务实例，并且可以与Docker自带的restful接口做集成，甚至是使用IntelliJ 14.1的Docker插件，能够做到从IDE到目标环境的一键式快速发布与部署。需要注意的是，这样做需要把程序的所有配置做尽可能地集中化处理，并且以Key-Value格式，降低错误几率。
InfoQ：Docker有很多的坑，你们的应用过程中是不是也遇到了？可以和大家分享下你印象深刻的几个坑吗？
王延炯：Docker的坑，在实际最多的还是集中于网络。大多数的使用场景，还是需要解决容器在不同的宿主机之间的可达性，这是决定Docker应用范围的***步。简单的使用端口映射，往往不能够解决运行期的端口动态监听和容器间互联。
另外，Docker的性能监控，也是决定Docker应用于什么样等级的业务系统的关键因素，这也是近期除了网络之外主要深耕的一个领域。目前还没有对Docker进行代码级的优化和hack，侧重点还是在团队的整体运行效率、软件过程效率、业务持续交付中。
InfoQ：Docker最适合微服务架构的应用，像传统非互联网公司的IT系统，应该很多应用都不是这样的架构。你们是如何过渡和应用的？有什么好的经验分享吗？
王延炯：首先，我们要回想一下到底什么是微服务或者叫微应用。我个人认为所谓微服务或者微应用，尤其在传统重业务的非互联网领域，其定位应当是一些非核心系统，或者是一些业务创新驱动的服务或应用，或者是一些架构于核心系统之上的组合、集成性质的轻应用。在技术层面，他们的特征是代码量小，随着业务快速变化可以迅速升级。而相对的，大平台不仅仅是指一个技术平台，广义上应当是一个以各种技术标准进行兼容和统一为基础，并提供多类型的业务平台，需要有效、高效支撑上层的微应用和微服务的繁衍。随着时间的推移和业务的发展，一些微服务、微应用，可以被吸收、沉淀至大平台中，发挥更大的作用。
其次，对于传统公司而言，我并不建议为了追求新鲜的技术而一定要向Docker之类的『时鲜平台』进行迁移，保障复杂业务的稳定性才是重中之重。像Docker之类的新技术，可以采取『农村包围城市』的策略，先在外部非核心系统试点，根据企业自身的开发、测试、运维的特点，积累和沉淀出一套适合自己的平台的方法经验论，当然其指导原则就是高效可靠。需要注意的是这个过程可能是漫长的，需要技术主导，也需要组织保障。
第三，我们可以发现，就Docker技术本身而言，它提供的是一个轻量级的容器，并没有集成每个企业所确立的容器基础设施基线。而企业的基础镜像一般只是一个操作系统级的容器（公有社区的Registry，不在此讨论范围之内），在此基础之上，我们可以在Dockerfile里面，透明的定义具体应用或者服务所需要的本地运行环境（例如JDK、Node.js、Python等等），加之以具体的服务、应用，在运行期形成一个服务或应用的实例。。
第四，从企业架构而言，一个服务或者应用往往需要其它中间件的支持（如数据库、缓存、分布式文件系统），也需要集群高可用的部署。这就牵扯到集群拓扑（有静态也有动态的），包括纵向的从上层应用到底层的硬件物理设施，横向的多实例负载均衡与备份。一个完备的企业级容器平台，还需要有实时的监控和管理手段来辅助。Docker本身，并不提供这些企业级运维工具或者来支撑，都需要基于开源工具进行集成和定制开发。
可以看到，把以上所有问题都解决了，对于传统企业，尤其是传统非互联网大型企业，Docker的大范围推广才具备可行性。Docker是否在企业里能够推广，用短板模型来衡量的话，这个短板应该是在运维团队，并不是在开发团队。
受访嘉宾介绍
王延炯博士，毕业于北京邮电大学网络与交换技术国家重点实验室。现任平安健康互联网技术平台资深架构师，关注企业互联网化过程中的软件平台技术路线。曾先后于西门子中国研究院、普元信息担任资深架构师，期间专注于内存计算、大数据实时分析平台的产品架构设计工作；参与并主持了十余项三大电信运营商、中国银联、中国登记上海公司等行业领军企业的平台软件架构设计。
