容器化技术作为“搅局者”，势必面临适配公司已有架构的挑战，本文将为大家介绍360如何让Docker落地。主要包括三方面内容：一，结合公司业务特点，如何使Docker适配现有技术架构 ，完成线上环境快速部署扩容；二，“让产品失败的更廉价”，使用Docker构建PaaS环境加速中小业务快速孵化上线；三，使用Docker技术，在构建持续集成环境方面的一些积累。

容器化技术作为“搅局者”，势必面临适配公司已有架构的挑战，本文将为大家介绍360如何让Docker落地。主要包括三方面内容：一，结合公司业务特点，如何使Docker适配现有技术架构 ，完成线上环境快速部署扩容；二，“让产品失败的更廉价”，使用Docker构建PaaS环境加速中小业务快速孵化上线；三，使用Docker技术，在构建持续集成环境方面的一些积累。

以Docker为主的容器化技术现在可谓风生水起，大家都觉得它可能会颠覆整个IT格局。我们刚开始接触到Docker的时候也觉得它非常好，有很多优点吸引我们。因为它的颠覆性我们称它为“搅局者”。

改造“搅局者”Docker

我们先来看看这位搅局者的优点：

1. Namespace、CGroups虚拟化， 相比传统虚拟化会有更好性能，反映在生产环境中就是能更大程度的利用资源。
2. 启动速度快，虚拟机最快也得30秒-1分钟，它的启动创建都是秒级。
3. 镜像分层技术，解决了快速变更环境的问题。

这些优点很吸引我们，我们非常希望把它用在生产环境中，但是我们发现理想很美好，现实很残酷。我们之前基础架构都是使用传统虚拟机化技术就是虚拟机。我们要使用Docker就会面临这几个问题 ：

1. 不能SSH，紧急问题怎么排查？
2. 怎么监控？
3. 基础服务如何对接？
4. 最重要的问题： 这东西稳定么，线上业务当然不能出问题。

所以，在应用Docker的时候，我们犯了犹豫，因为按照它推荐的方式，我们无法直接立马就在线上业务使用。因为Docker本身也对业务的架构设计有一定要求，比如我们常说的容器无状态，容器中不要留中间数据。我们发现公司的业务架构改造起来困难很大，涉及到方方面面，所以我们决定要 Docker去适应公司的架构。

接下来我们就是要解决Docker技术”落地”的问题。

我们对Docker改造点主要有：

1. 容器内部绑定独立IP。
2. 容器内部开启多进程服务。
3. 自动添加监控。
4. CPU配额硬限制。
5. 容器绑定独立IP这样外部可直接SSH了。

我们考虑在容器内部运行多个进程服务，因为默认容器只开启一个进程，这无法满足我们要求，所以我们大胆进行了改造。我们甚至在镜像里实现了chkconfig让以前的RPM包原生可用。

自动添加监控让创建的容器自动添加到Zabbix中。CPU配额硬限制 Docker 1.7版本已经支持了，我们在这之前自己实现了一套。

改造Docker支持这些功能后，我们又开发了一套调度系统，负责管理调度在集群上如何创建容器，我们也调研了一些开源的调度系统，发现都不满足需求，所以自己开发了一套。

通过这些手段我们就可以让Docker技术“落地”了，而带来的好处是，之前的体系我们要上线新的业务大约需要40分钟，使用Docker缩短到了5分钟。

这是分享的第一部分因为“搅局者”Docker使用遇到了困境，所以我们对它进行了一些改造，更好适配公司场景，让技术“落地”。

基于Docker做一个内部PaaS平台

紧接着我们基于Docker做了一个内部PaaS平台。公司每天会上线很多业务，这些业务有些是体量很大的重要业务，有些是带有试错性质的小业务。

传统业务上线的步骤会非常得严谨，流程会比较长，这些流程其实也对业务稳定性会有保障。有些试错性质的小业务，使用同样的流程变得不太合适，所以我们就想加速小业务上线流程，让他们可以快速上线，验证自己得价值。基于这种考虑，而且Docker天生的特点就特别适合干这个。

这是界面的一个截图，主要是前端Web UI去访问一个调度层 ，调度层通过调用Docker API来创建容器。目前PaaS平台支持PHP、Node.js、Python、Java等语言。

除了创建容器，我们还需要，创建Git仓库、配置访问代理等，总之研发一键就可以让业务进入待上线状态，只要他传完代码就可以上线了。

目前这个平台跑了300+业务，让很多研发只要有一个idea，就可以快速实施上线，很受他们欢迎。

这也是我们应用Docker的第二部分，通过私有PaaS平台，加速业务孵化。

关于持续集成

第三部分是关于持续集成。

持续集成当然是Docker最纯粹的玩法了，通过『Dockerfile-构建镜像-创建新容器』来完成环境的变更。

这块比较复杂，我们大致分了9个模块，比如调度模块、监控模块、存储模块等。

首先我们做了一个配置转换模块来转换Dockerfile，这样即可以统一镜像构建标准，同时也降低了编写Dockerfile的学习成本。

调度模块就直接用的Mesos和Marathon，镜像Registry直接使用了 Registry V2因为它性能更好对高并发支持也很好，最后是镜像构建模块，使用的是Jenkins CI。

但是我们发现一个问题：镜像构建在高并发下其实并不快。 比如装一个RPM包，SSH肯定会比重新build快得多。所以我们做了很多优化在镜像构建这一块，现在结果是100个任务同时构建我们也能达到和传统集群管理如Puppet一样的效率。

Q&A

问：开发自己的调度系统大概花了多久，有遇到特别的技术难点吗？
答：大约2个工程师一个月样子，没有太多得困难。因为调度逻辑比较简单。

问：您刚才说，通过绑定独立的IP就可以直接使用SSH了。
答：通过绑定独立的IP就可以直接使用SSH了，官方关于network那篇文档有介绍实现方案。

问：一般Docker的服务封装是no daemon的，这时如果重启服务，容器也会退出的，如何debug？
答：可使用supvirsod或者monit等将no daemon封装一下。

问：你们服务的注册发现用的是什么？
答：我们基础架构组开发了一个，名字叫QConf，已经开源在GitHub上。

问：你说Zabbix做的一个容器监控，那有没有一个基于宿主机的监控方式？因为据我所知你这样的话每个容器都要运行一个代理吧。
答：我们就是使用宿主机里安装Zabbix代理，通过Zabbix自发现来动态获取容器列表，再基于自定义的监控脚本获得每个容器的监控数值。

问：你们的那些业务跑在Docker里了？
答：目前360的很多Web2.0业务已经跑在了上面，像影视、新闻、免费WIFI等。

问：Docker建议无状态，那么是否意味着不建议存放数据？比如MySQL，还是说通过-v来解决？
答： 这其实是数据存储问题，你可以使用分布式存储来存储数据，只要数据和逻辑分离容器就无状态了。

问：Docker建议无状态，那么是否意味着不建议存放数据？比如MySQL，还是说通过-v来解决？
答：我理解就是容器无状态就是基于镜像创建的马上就能线上使用。

问：线上Docker的稳定性如何？
答：目前运行都很稳定，没有出现容器异常崩溃等情况。

问：Container中跑多个进程，那么PID为1的进程你们是由什么控制的，直接由对应的应用程序还是其他什么？
答：之前用了supervisord 现在使用S6。

问：Registry面对大量的并发，有测试出大致的性能占比吗，整个registry是mirror还是其他架构？
答：Registry目前我们更新到了V2，我们测试V2在高并发pull和push上性能非常好，镜像存储使用共享存储，这样Registry也可以横向扩展。

问：如果容器配置用户可以直接访问的IP，在宿主虚拟机中是否可以基于Open vSwitch实现，否则会太依赖虚拟机网络？
答：这个可以的，实际上我们也测试过没问题，当时基于稳定性考虑没有使用。

问：奇虎的CPU配额管理是如何实现的？
答：这个Docker 1.7已经实现了，我们和官方的实现思路是一致的。

问：关于容器中数据存储是怎么做的，如果是共享存储如何进行对应？
答： 可以试试GlusterFS或者Ceph。

问：容器绑IP，容器重启后IP要重新绑吧，IP会变吗？
答：需要重新绑，可做成自动化脚本。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上内容根据2015年8月18日晚微信群分享内容整理。分享人许斯亮（微信siliang5625633），2011年加入奇虎360，从事业务一线运维工作，在线上业务运维和架构设计上有丰富的经验。参与了Hulk私有云平台架构设计和实施，主导内部PaaS平台的设计和开发。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesx，进群参与，您有想听的话题可以给我们留言。

来自：http://dockone.io/article/600