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

上图就是我们做的环境管理,这个环境管理其实调用的是Jenkins的一些接口,这边展示的信息会比那边更直观一些,可以看到它每一个app_code后面都只有自己的tag name,就是相当于只有它的分支,其他的比如说build_type是自己这定义的,它就会覆盖上面的,如果这边没有定义的话,就都只用上面公共的.

存在的问题及未来计划

下面说一下我们在使用过程中目前系统还存在的问题以及未来的计划,我们现在在用Marathon的时候,刚才有说现在主要用host模式,host模式它很灵活的一点就是,比较简单,而且都不需要我们管理,IP地址直接用的是宿主机的,但是存在的一个问题就是一旦有容器挂掉,或者说有宿主机有问题,还会在飘的时候再随机启动,这样如果通过固定IP或者端口号来通信的一些服务,有可能会有问题,找不到之前的服务,因为它里面可能记录的是之前的那个接点,所以我们现在也在尝试给 Mesos 分配固定 IP 这样一些网络解决方案,我们现在尝试的是Calico.

上图是一个网上截图,我就主要说一下我们这边的使用方式.发布系统根据app_code等信息自动生成一个主机名,到DNSDB里边bind一个IP地址,Marathon需要改成bridge模式,通过Marathon的配置文件把主机名和IP地址赋给新建的容器.但是我们并没有大规模使用这个的原因是,dev和beta环境可以这样用,因为它基本只有一个instance,每一个Marathon上面的APP只有一个instance,但是如果是真正的线上环境的话,肯定需要多个instance,在多实例的情况下,Marathon没有办法确定如何指定每一个instance具体的IP地址.当然Calico可以auto的方式去分,但是采用auto的方式,我们现在遇到一些问题,也可能是设置问题,就是它会把管理IP也分给容器,这样的话就有可能会导致整个网络有问题.

另外如果通过auto这种方式分给Docker容器的话,这个信息是不能返回给Marathon或者Mesos接口的,所以我们是没有办法再次拿到这个信息.因为我们拿到这个信息是要给下面的一些依赖以及服务用的,我们现在还没有做所有基于集群的宿主的一个Agent,所以我们拿不到这个信息,现在也没有真正在线上用.我们现在用Calico,只有给Nginx的这种容器使用Calico,这个就是方便大家可以本地配host去测试,可以不用每次总是改IP地址.

下一个问题就是集群里面的宿主问题,应用自动飘可能会启动失败,它如果有强依赖的话,一旦飘有可能找不到之前已经记录的端口.如果暂时没有办法通过Calico去解决的话,后面会在Entrypoint?里边去做检查,也会用上Marathon自己的一个Dependency功能,它其实自己有Dependency功能,但是这个Dependency功能默认是基于它的health check,如果加了health check之后启动成功了,然后才会起后面依赖的应用,但是如果在我们没有加health check的情况下,它只是判断上一个应用起来了,然后下一个应用才会去启动.这样在启动的时候,因为没有去检查上一个应用是不是真的在check url时能返回200,有可能启动失败,所以以后我们可能会自己做更多的一些检查.下面就是DBCI,这个也是我们之后要做的一个系统,DBA现在有一个系统是可以发布SQL语句上线,然后我们以后要跟DBA的系统做一个打通,那边脚本有上线的话,我们这边会自动同步到标准库以及基于这个标准库创建的各个Docker容器里面.

关于数据库使用标准库这块也有一个经验,之前我们用标准库是把标准库里面的数据给Dump出来,然后在Docker容器里面import,这样的话,如果一个标准库特别大的话像我们有一个标准库能达到四五十个库,占用的时间就会特别长,大概17分钟左右.后来我们做了一个改进,就是标准库的data目录也是打包直接上传到对象存储上面,MySQL的Docker容器会从它对应的标准库的地址,从Swift 上面去拉相应的tar包,然后解压,这样大概能缩短至1分半左右,所以说速度有很大的提升.其实关于数据库这块,我觉得从根本上解决问题的办法是数据库版本控制,但是因为我们现在业务线特别多,推起来也比较困难,所以我们现在是采用这种解决方案.

我们后面要接进来的是日志,还有ELK查询,然后还有监控和报警,监控是cAdvisor,主要是做Docker自身的监控,我们公司有做了一些二次开发.watcher是我们公司基于一个开源的监控系统做了一个二次开发,这个主要是做业务监控.

上图是Kabana上查看日志的一个简介,它可以定制一些面板,有各种搜索.

上图是我们监控的一些展示,有一些业务的流量,还可以定制各种监控指标.

这个是我们未来要做的,考虑应用自身的扩容,就是动态Slave?.针对我们底层的集群平台也会做一些动态的扩容,因为现在业务在慢慢往Docker上迁的时候,OpenStack的虚拟机会有一些空闲,可能以后会动态的去检查请OpenStack的虚拟机那边的空闲情况来做一些平衡(如果要是申请真正的实体机来作为我们的Docker集群的话,这个会要走一个采购流程).

（编辑：ASP站长网）