360 的容器化之路

【编者的话】容器化技术作为“搅局者”,势必面临适配公司已有架构的挑战,本文将为大家介绍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会变吗? 答:需要重新绑,可做成自动化脚本。


Linux 下的 TCPing 美团点评业务之技术解密,日均请求数十亿次的容器平台 - infoq