许斯亮 分布式实验室
容器化技术作为“搅局者”，势必面临适配公司已有架构的挑战，本文将为大家介绍360如何让Docker落地。主要包括三方面内容：一，结合公司业务特点，如何使Docker适配现有技术架构 ，完成线上环境快速部署扩容；二，“让产品失败的更廉价”，使用Docker构建PaaS环境加速中小业务快速孵化上线；三，使用Docker技术，在构建持续集成环境方面的一些积累。
以Docker为主的容器化技术现在可谓风生水起，大家都觉得它可能会颠覆整个IT格局。我们刚开始接触到Docker的时候也觉得它非常好，有很多优点吸引我们。因为它的颠覆性我们称它为“搅局者”。
我们先来看看这位搅局者的优点：
Namespace、CGroups虚拟化， 相比传统虚拟化会有更好性能，反映在生产环境中就是能更大程度的利用资源。
启动速度快，虚拟机最快也得30秒-1分钟，它的启动创建都是秒级。
这些优点很吸引我们，我们非常希望把它用在生产环境中，但是我们发现理想很美好，现实很残酷。我们之前基础架构都是使用传统虚拟机化技术就是虚拟机。我们要使用Docker就会面临这几个问题 ：
不能SSH，紧急问题怎么排查？
怎么监控？
基础服务如何对接？
最重要的问题： 这东西稳定么，线上业务当然不能出问题。
所以，在应用Docker的时候，我们犯了犹豫，因为按照它推荐的方式，我们无法直接立马就在线上业务使用。因为Docker本身也对业务的架构设计有一定要求，比如我们常说的容器无状态，容器中不要留中间数据。我们发现公司的业务架构改造起来困难很大，涉及到方方面面，所以我们决定要Docker去适应公司的架构。
接下来我们就是要解决Docker技术”落地”的问题。
我们对Docker改造点主要有：
我们考虑在容器内部运行多个进程服务，因为默认容器只开启一个进程，这无法满足我们要求，所以我们大胆进行了改造。我们甚至在镜像里实现了chkconfig让以前的RPM包原生可用。
自动添加监控让创建的容器自动添加到Zabbix中。cpu配额硬限制 Docker 1.7版本已经支持了，我们在这之前自己实现了一套。
改造Docker支持这些功能后，我们又开发了一套调度系统，负责管理调度在集群上如何创建容器，我们也调研了一些开源的调度系统，发现都不满足需求，所以自己开发了一套。
通过这些手段我们就可以让Docker技术“落地”了，而带来的好处是，之前的体系我们要上线新的业务大约需要40分钟，使用Docker缩短到了5分钟。
这是分享的第一部分因为“搅局者”Docker使用遇到了困境，所以我们对它进行了一些改造，更好适配公司场景，让技术“落地”。
紧接着我们基于Docker做了一个内部PaaS平台。公司每天会上线很多业务，这些业务有些是体量很大的重要业务，有些是带有试错性质的小业务。
传统业务上线的步骤会非常得严谨，流程会比较长，这些流程其实也对业务稳定性会有保障。有些试错性质的小业务，使用同样的流程变得不太合适，所以我们就想加速小业务上线流程，让他们可以快速上线，验证自己得价值。基于这种考虑，而且Docker天生的特点就特别适合干这个。
这是界面的一个截图，主要是前端Web UI去访问一个调度层 ，调度层通过调用Docker API来创建容器。目前PaaS平台支持PHP、Node.js、Python、Java等语言。
目前这个平台跑了300+业务，让很多研发只要有一个idea，就可以快速实施上线，很受他们欢迎。
这也是我们应用Docker的第二部分，通过私有PaaS平台，加速业务孵化。
第三部分是关于持续集成。
持续集成当然是Docker最纯粹的玩法了，通过『Dockerfile-构建镜像-创建新容器』来完成环境的变更。
这块比较复杂，我们大致分了9个模块，比如调度模块、监控模块、存储模块等。
首先我们做了一个配置转换模块来转换Dockerfile，这样即可以统一镜像构建标准，同时也降低了编写Dockerfile的学习成本。
调度模块就直接用的Mesos和Marathon，镜像Registry直接使用了 Registry V2因为它性能更好对高并发支持也很好，最后是镜像构建模块，使用的是Jenkins CI。
但是我们发现一个问题：镜像构建在高并发下其实并不快。 比如装一个RPM包，SSH肯定会比重新build快得多。所以我们做了很多优化在镜像构建这一块，现在结果是100个任务同时构建我们也能达到和传统集群管理如Puppet一样的效率。
