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

下面讲一下系统架构,上图是我们这个平台的主要架构,底层资源层是Mesos Marathon,上层封了一个OpenResty,主要是做一个泛域名,方便启在Marathon上面的所有应用可以通过一个统一的入口进行测试.因为可能大家用Marathon的情况大多数都是用host的模式,host的模式会随机分配主机和端口号,如果每次发布端口号都会变的话,用户在测试的时候是很难记住它的名字的,所以我们就封装了一个泛域名,只要这一套环境名不变、应用名不变,它访问的域名就是固定的.上一层是我们自己开发的一个用户入口,就是现在最基本的应用树,基于应用树可以录入基础的应用信息(后面都会有具体讲解),可以在应用树上面去做资源的管理,申请资源、环境管理.我们其实发布还是用的Jenkins,上面开发了一个插件,环境管理是直接调用的Jenkins的接口去进行config文件的同步,触发构建这样的操作.然后是数据库管理,因为发布的时候大家也需要数据库支持,我们现在使用的是一个比较粗暴的方式,是用一个标准库是定期去同步线上的表结构,但是这个操作现在大部分还是手动的,希望以后做成自动的(数据库管理系统来做这件事,下面也会有具体的讲解).通过发布可以调用Marathon的接口,然后创建Docker容器,有各种类型的一些服务,有Web的Container这种,然后上层是接的我们公司现有的一些监控平台,日志平台还有可以直接访问容器里面的客户端,我们内部叫“八爪鱼”,它有网页版,也有客户端版,其实这个主要就是封装的一个Docker的EXEC,然后可以直接登陆到里面去.

上图对系统架构图的一个细化,这个是底层资源层,像Mesos、Marathon有一些定时任务是用Chronos,上面应用层比如说业务有部署的Canal、MySQL以及Solr,然后基础服务比如说有Confd日志、Heka、cAdvisor做Docker自己本身的监控,Prism是我们自己内部的一个日志平台,Watcher是做业务监控.

QAECI这个架构主要是发布系统的那一个环节,是从Git或者SVN上下载代码,然后在编译机上进行统一的编译,编译完的以后上传到Swift上,一个共享存储,然后就调用Marathon的接口去创建Docker容器,启动Docker的时候去拉取代码,然后做一些配制替换,包括某些项目一些特殊的操作,可以通过service脚本去执行,这样就完成了部署.基础的操作做完了以后会启动服务,因为我们这边大部分都是Web服务,所以我们会有一个check url的工作去来检查这个服务是正常启动的.我刚才说像Compose还有YAML文件的编排没有办法直接来做,就是因为我们为了保证服务是正常的,需要做check url,虽然Marathon有health check的功能,但是我们并没有直接用,是因为想给用户保留一个现场.如果health check没有通过,Marathon会一直去重启,这样的话用户没有办法去发现它的环境到底出了什么问题,就是说我们是通过自己的脚本去做这个检查.

QAECI系统里面的一些关键点,简单跟大家介绍一下.

第一个是使用app_code作为应用的唯一标识.因为我们之前的发布系统是每新建一个job就要把一个应用所有的参数全部填写一遍,这样就需要分不同的环境需要建多个job.有一些基础信息需要变化的时候,每一个job都需要去修改,而且在系统之间做关联的时候也没有一个唯一的标识服务,比如说日志系统,然后还有应用中心那边,或者监控,可能大家都没有一个通信的ID,所以我们就统一了一个标识服务,只要它有一个唯一ID,在任何系统之间都是打通的,就是它的信息是可以带到任何系统里面去.

第二个是基础信息统一记录.基础信息不需要在每一次发布的时候再去维护,而是在一个地方统一去维护,然后发布的job上基本只需要勾选上自己要发的模块,以及要发的分支就可以简单的去进行发布了,没有太多额外的参数、维护成本特别低.

第三个是配制文件模板化.这个也是比较重要的一点,之前在建多个环境的时候,Maven的Procfile文件都需要有多套,就是因为有一些环境的信息比如说连接其他环境的一些接口的地址如MySQL的地址,这些全都是写成固定的,每一套环境里面都是不一样,我新建一套环境就要新加一套配制文件,但是现在为了可以简单的部署一套环境,我们把这个配制文件模板化了,这种环境相关的情况,只要按照我们提供的常量去改,然后我们在起环境的时候就可以自动进行替换,这样就可以保证每个人有自己的环境,而不需要再去维护那么多配套文件.

第四个是计算部署顺序.这个也是我们业务相关的,就是部署经常会有那种Web服务有依赖,所以我们要在发布的时候计算这个部署顺序,然后以保证它起来的环境是可用的.

第五个是泛域名.我们用OpenResty做的一个域名服务,这个是可以方便大家很容易的测试自己的服务的一个工具.

功能展示

上图就是我们在记录系统基础信息的一个截图,信息相对多一些.图中有一些Java的选项要填,然后可以看到其实它最基本的就只有scm_root,就是一个版本控制的地址,编译的结果、编译类型还有check url,下面比较重要的是一个部署依赖,这个就是会计算它部署顺序的,基本只需要这些信息.

这个是一个发布job的展示,我们做了自己的插件——Qunar Build.大家可以看到右边上面是一些基础信息,这个决定它的环境是什么,是dev、beta还是线上,我这里面没有展示,其实它勾选每一个,就是每一个有check box的都是一个app_code,然后它具体的信息是通过刚才这个平台的接口去获取的,所以说它下面每一个app_code都不需要再填自己的基础信息,只要填自己本次要部署的分支名称就可以了.

（编辑：ASP站长网）