去哪儿网利用Mesos和Docker构建dev—beta环境

《去哪儿网利用Mesos和Docker构建dev—beta环境》要点：
本文介绍了去哪儿网利用Mesos和Docker构建dev—beta环境，希望对您有用。如果有疑问，可以联系我们。

大家好,我是去哪儿网的张宁,之前是做配置管理,2015年6月份转到去哪网做运维开发,现在主要从事的工作是基于Mesos和Docker快速构建dev和beta环境,基础架构是Mesos Marathon.

最初我们是想做一个内部的PaaS平台,但是因为底层的架构也刚开始尝试Docker,所以说基层架构现在不是特别完善.包括我们内部在开发的一些系统,现在基本完成的是发布这个环节,在这里主要跟大家分享一下发布这一块,以及在使用Docker和Marathon过程中遇到的一些问题.

本次演讲主要分五部分：

背景

首先是业务线的一些期望,因为我们之前有一个发布系统,最早的时候是单模块发布,但是我们业务上线的时候基本上需要多模块一起上线才能组成一个完整的服务,所以大家在发布的时候就会比较头疼,需要手工把所有的项目给发布上线.尤其是dev和开发环境,大家在准备起来的时候经常会遇到很多问题,环境比较乱,所以开发和QA在部署环境时是比较头疼的,他们希望可以一键部署整套环境,包括MySQL、Redis、ZooKeeper、Memcached这些基础模块,同时也希望能够快速部署环境,可以得到快速的反馈.

其次就是环境隔离,使用传统部署方式时,大家因为部署环境特别麻烦,就经常使用公用环境,导致环境里面经常会有一些脏数据,所以他们希望每个人能有自己的环境,不受其他人的影响.

最后一点就是学习和维护成本尽量要低,希望可以让新来的同学点一个按纽就可以发布,也不用过多地去了解里面的一些概念.总结下来要解决他们的各种环境问题.

我们为什么选择Docker Mesos架构?

从我们要做这个发布系统的初衷来说：

• 轻量级、快；
• Mesos Marathon架构符合现在的功能需求.

其实最早我们也调研过Kubernetes,但是因为在我们的使用场景中都是单容器,不需要两个容器里边的应用共享网络或者资源的情况,用不到Kubernetes中pod的一些优势,所以我们就直接用了Mesos Marathon,全都是单独的Docker容器.另外一个就是因为我们更多的是多项目之间有关联的这种情况,其实像Swarm的Compose文件可能支持编排,但是这种编排也只是顺序启动,中间没有什么校验的环节.还有像Kubernetes其实也可以做这种编排,但是也是缺少这种更具个性化校验的功能,所以我们在系统之间依赖这一层做的东西全都是发布系统里面需做的一些check.现在公司的日志系统是基于Mesos和Marathon的,已经在上线使用,如果我们用这个架构的话就可以借鉴之前的一些经验,也可以避免一些之前遇到的坑.

如何落地?

虽然上面我们选型基本定了,但是在落地的时候其实还是有一些细节是需要考虑的.

第一是是否每次都要build镜像.每一个使用Docker做发布系统的团队都会考虑的这个问题,我们是使用固定的镜像,每次是把编译的代码上传到一个共享存储,然后是使用公共的镜像启动之后直接去拉取代码,没有每次去build镜像,因为在我们的dev和beta环境,这两个环境可能大家的代码变化频率是很大的,并没有达到Docker最原始的初衷,就是一个Container搬到哪都能用.但是如果我们要给它打成一个镜像的话,其实镜像里面代码是经常变的,这个Container并不是dev环境用完,beta就能用,所以我们就想了一个更灵活的方式,就是每次编译完代码上传到一个对象存储,然后在Docker容器启动后去拉代码,这样任何时候启动都可以拿到最新的一个版本,任何版本都可以通过相应的参数来指定.

第二是是否使用Jenkins-Mesos.其实Mesos有基于Jenkins原生的CI解决方案,我们这边也没有用,我也建议大家如果硬件能满足条件的情况下还是用固定的机器会比较好.我们的编译就统一使用的是SSD硬盘然后加大内存,这样可以保证编译速度.如果要是在Mesos Marathon的集群里面去完成这件事的,不可能把整个集群都做成SSD硬盘的这种硬件设施.另外一方面就是我们这边项目比较多,如果有一个?Maven的local repo,就会加快编译速度,如果是每次在生成的新容器里边编译可能也会慢.

第三是如何加快dev和beta环境构建.我们目前做的是所有模块是并行编译,然后分批部署,没有做并行部署的原因是因为我们有一些依赖,所以我们会在开始部署之前根据依赖关系计算一个部署顺序,然后再去分批部署.现在大概是40多个模块的一个环境,可以在20分钟以内完成全部编译和部署.

第四是使用方式如何能够平滑过渡.我们现在做的这个发布系统是基于我们公司最早的一套发布系统做的,之前的架构包括分支策略都已经确定了,我觉得之前的方案也是很好的,我们基本上是延续之前的那个发布系统来做的,只是再把Deploy里边的很多操作给转移到Docker里面去做,但是编译阶段是延续之前的,所以我们保留了之前发布系统里面的一些必要参数,然后简化了一些部署阶段的参数,这样用户学习和接受起来比较容易.

第五是如何建立容器发布的流程标准.每个公司开发的流程是不一样的,运维体系也是不一样的,所以说这个只是根据我们现在的一个运维体系以及开发的流程重新做了一个系统,下面会有具体的介绍.

第六是运维能否支撑.因为我们现在日志平台已经在线上使用了,所以说我们就直接借鉴了他们的一些经验,目前看来基于这个架构来做还是比较顺畅的.

第七是资源利用率是否真的提高了.这个也是大家比较关心的,我们公司原来是OpenStack上面有KVM,一般大家会申请4G内存的机器,可以部署三个应用.然后我这边做 Docker 的话,大概是一个Docker里面一个应用,默认是1G内存,所以说有可能少部分的主项目它占用的内存比较多,大概需要2G或者3G,但是80%的项目都1G就够用了,我觉得大概资源利用率至少可以提高20%左右.我现在还没有做资源的压缩,现在系统还在试用阶段,等系统稳定以后,还要把现在有富裕的一些再进行压缩一下,资源利用率还会再细化.

技术架构

（编辑：ASP站长网）