Docker的几个实战经验分享

云栈科技是一家提供容器解决方案（csphere）的创业公司，其创始人王利俊是之前新浪SAE PaaS平台的负责人，在3月29日的QClub Docker大会上，王利俊分享了题为《Docker在生产环境的挑战以及应对》的演讲，本文根据其演讲内容整理而成。

未来的趋势是PaaS还是CaaS

PaaS从2008年万众瞩目到2012年遭受质疑，再到现在很多PaaS企业业务发展都不尽如人意（甚至有的已经关闭），留下的也是在苦苦支撑。究其本质原因，是由于PaaS在满足客户需求方面存在很多障碍。没有规范，不成PaaS。PaaS的关键是约束和规范，但是规范是一把双刃剑，它一方面使得应用开发更加整齐，应用管理和维护更加简单；但是另一方面客户的需求千变万化，我们很难用一套规范去满足所有的业务需求。因此通用的PaaS平台就处于两难的境地。未来PaaS的趋势一定是垂直化，比如面向游戏的PaaS、面向某类智能硬件的PaaS。

随着以Docker为代表的容器技术的成熟，CaaS（容器即服务）的概念也逐渐被接受。未来的趋势是PaaS还是CaaS，这取决于未来市场是对PaaS还是对容器更加接受。现在的市场对Linux非常认可，使用率也很高，如果容器可以像Linux一样流行，那肯定是CaaS更有市场。反之，则是PaaS更加流行。

镜像管理

镜像是Docker管理最基础的部分，同时也是Docker最大的亮点。镜像管理涉及到镜像的制作、更新、存储、分发、权限等多个方面。

镜像制作方面，应该坚持三个原则，第一是坚持镜像总是从Dockerfile生成。这样做最大的好处是可以通过Dockerfile“阅读”镜像，在后续的协作、升级维护等方面会带来巨大的便利。第二是镜像之间应该避免依赖过深，建议为三层，这三层分别是基础的操作系统镜像、中间件镜像和应用镜像。第三是坚持所有镜像都应该有对应的Git仓库，以方便后续的更新。

镜像的更新需要一个自动化的流程，这可以通过SCM和CI系统自动触发实现。具体的流程如下图所示。开发者首先将代码和Dockerfile提交到Git仓库，然后Git通过webhook方式触发Jenkins的主动获取代码和Dockerfile文件，Jenkins再通过Docker相关的插件生成镜像并推送镜像到私有的Registry。这样，在服务器上就可以通过拉取新的镜像部署容器。

关于Registry，可能会涉及三方面的问题，一个是单点问题，对应的解决方案可以考虑DRBD、分布式存储以及云存储。二是Regitry的性能问题，目前可用的解决方案是通过HTTP反向代理缓存来加速Layer的下载。三是Registry用户权限，Nginx LUA可以提供一个简单快速的实现方案。

发布管理

和传统的发布流程相比，Docker最大的好处是不需要考虑外部依赖，利用容器的自包含的特点，我们可以将发布回滚流程标准化和产品化。而传统的发布和回滚，需要casebycase去针对不同应用做升级回滚的方案。要做到基于Docker的发布，镜像的生成必须坚持自动化，否则会发现升级比传统的方法更麻烦。因此在现实中我们也发现很多企业将代码目录放到主机目录映射到容器内，这样做破坏了Docker的自包含特性，解决的办法是坚持应用镜像更新自动化。

日志管理

由于容器是无状态的，所以存储在容器内的日志会随着容器的销毁而消失。stdout/stderr类型的日志，可通过logspout转发到syslog中心来收集。打印到文件的支持，比如accesslog，需要将日志存储到外部的Volume，并在Docker主机上使用logstash收集转发。

配置管理

容器里没有CM agent，无法接收CM指令。CM运行到Host上也无法管理容器中的文件，如果手工修改容器内的配置，那新创建的容器仍然是旧的。配置大体上分为两种类型，一种是服务之间的连接信息，这种配置建议考虑使用服务发现系统，也可以使用一些更加传统的方法，比如通过环境变量来协调作开发和生产环境的配置差异。一种是一般的配置文件参数，配置文件和Dockerfile应该一起存储到一个Git仓库，修改后自动build更新镜像。

网络管理

目前Docker支持的网络包括Host网络、NAT网络、物理网桥和网络虚拟化。Host网络中容器和主机共享网络命名空间，不同容器需要做好端口规划，防止端口冲突。Nat网络是基于四层代理以及NAT技术，依赖portmap，进出都需要转发，性能低，主机上需要做好端口规划，容易搞混。物理网桥方案，和传统虚拟机的网桥没有区别，适合容器数量有限且相对静止的场景。网络虚拟化是基于隧道的overlay网络，目前开源方案有SocketPlane、Weave、Flannel，适合数量大，动态创建销毁容器的场景。