架构师实践日|携程DOCKER实践 

极客 作者:七牛云 2016-03-22 03:51:45
12
3月13日下午在上海举办的“架构师实践日“沙龙中,来自携程系统研发部的架构师李任向大家做了题为“携程Docker实践”的分享。携程系统研发部主要是负责携程系统云平台开发的任务。从去年底开始,携程开始计划把Docker引入到携程的云平台,这是系统研发部一部分的工作任务,李仁现在就在协同研发部从事Docker引入的工作。以下是对他的演讲内容的整理。
容器对携程的价值 为什么要在携程内部推容器?肯定是想获得容器带来的好处。公共的好处大家都会知道,但有一个可能是携程特有的痛点,因为携程有大量的应用是部署在Windows上,因此携程也很希望将来Windows的容器会给它们带来一些提高和帮助。 目前携程为容器在内部的推动制订了一些路线图。携程希望尽量以虚拟机的方式来运行容器,这主要是考虑到它带来的优点是对现有的应用和体系的影响小,携程希望尽量以平滑的方式过度到容器中。但是,目前在推广上会有一个困难,大家会在你推销它的时候质疑,因为改变很小意味着带来容器特殊的优势很少。而这个确实是它的缺点。另外目前在携程内部主要是通过 OpenStack来管理云架构的基础设施。 携程部署Docker的架构

13

图一

图一是携程目前第一阶段部署容器的架构,它选择了一个比较简单的切入点,通过Nova Docker Driver做一些改造来管理容器的生命周期。本身容器的调度、管理和在OpenStack上用管理虚拟机是一样的。图一最上面的Remedy是携程内部的流程管理系统,它会通过一些接口去访问OpenStack 的整个controller的API。 因为携程早期是Windows,所以有很多VMWare的虚拟机,它们有专门针对EXSi的nova compute节点,图一右边是KVM的计算节点。引入Docker实际上是在这个架构里面增加了一个新的节点类型,即专门跑容器的Docker的一个节点。

14 图二

除了容器本身生命周期之外,网络的架构复用了现在OpenStack管理网络的方式。前面是计算资源的架构,同时也用OpenStack对网络进行管理。基本上容器的网络使用方式和虚拟机在OpenStack里使用网络的方式是很一致的。 图二是一个容器的网络图,可以看到一个Docker容器有一对veth的设备。一个在它自己的namespace里面,一个加入到OVS bridge里面,如果这等同于虚拟机的话,下面就是虚拟机的tap设备,之后就和虚拟机网络的PaaS是一样的。通过这个bridge 连到internal 的bridge,右边是出口的 bridge ,中间会做vlanid转换,这样可以接到系统的二层网络里面去。这个是经典的VLAN模型。 Docker容器运行 携程Docker的容器的运行为了尽可能的讨好用户,更容易让他们接受,现在是以虚拟机的模式进行。在应用部署方面跟现在虚拟机部署一样,拿到一个容器之后通过现在的发布系统部署进去。因为是高度接近虚拟机的环境,所以对于应用的发布系统,用户基本上感知不到。 现在携程内部虚拟机的发行版,主要以CentOS6.4为主,但是他们也开始迁移到CentOS7.1,所以携程在Docker容器上支持这两个发行版。以前的虚拟机的方式会导致运维的人上去可能要做很多运维的工作,所以要考虑到权限问题。但有些权限很危险不能给他们,否则会造成很多问题。比如sys_boot,它在里面可以将宿主机重启,如果你把sys_boot给出去的话,这个是很可怕的。 镜像有很多种方式,而携程现在选的方式是有一定历史原因的。因为携程OPS有一套基础的环境规范。为了让ops原有的设施能继续工作,这个环境要尽可能演示。但悲剧的是,它没有一个很精确的代码能去描述环境是怎么样的,而只能用一个做好的自动安装的光环去抓取到环境。所以当时携程选择直接把自己的虚拟机的镜像拉过来,然后从虚拟机QCOW2的镜像去踩点至Docker的镜像。 携程以虚拟机的方式运行,它运行起来不是很正统的只有一个进程的容器的方式。携程在一个容器里面起了很多进程,而进程像虚拟机一样需要有个初始的守护进程,所以携程也需要这样的守护进程。守护进程很多,而守护进程该如何选择?如果大家看过相关文章的话,有很多的讨论。除了目前已有的守护进程外也涌现着很多新的守护进程。但是比较悲剧的一点,携程还有一个运用规范,运用规范规定了启动服务,在CentOS7.1下一下子很难撼动他们的地位,只能向他们靠拢。 另外,如果容器里面Cgroup这个文件系统是可读的,这也意味着在容器里面,分到的CPU内存资源可以随意改变,这个可能在公有云计算是不可接受的事情,但是私有云里面目前只能这样。 还有很重要的一点是网络。前面说到携程网络是和OpenStack的那套网络管理一样的方案,其实它有很多手段来实现这些。目前因为携程用novadocker,顺便说一下novadocker 常不靠谱,没法用。携程以前与京东交流,他们给携程出的建议第一句话就是不要用novadocker。novadocker采用的方式,其实和pipework是很类似的,也就是它把容器运行起来,然后进去,通过执行一些命令,再配上网络。但它有一个问题,其实容器在启动到配上虚拟的网卡,这个过程其实是有一段时间的。 携程用systemd,而它启动是很快的,这就意味着,有一些服务起来的时候,后面需要配套网络,如果你的应用对于这个是有依赖的就会问题。另外,这个网络的配置信息Docker是不可见的,这意味着Docker不知道这段网络配置。如果Docker daemon把容器重启的话,它是没办法恢复网络配置的,这个是很严重的一个问题。比如到了1.9之后,支持libnetwork做网络的配置。这样就不会有前面丢失网络信息的问题。携程现在还是用novadocker 的方式,本来打算用libnetwork,但是很悲摧的是,上线之前,携程一直使用Ubuntu,后来临上线,到生产的时候,运维说,他们希望统一宿主机版本全部用CentOS。最后没办法,只能把Netron agent这些东西全放到容器里面跑,再跑 novadocker等。 Docker监控 前面部署其实只是解决了实例运行的一些问题。运维的人的支撑对于一个真的能运营的产品很重要,所以对于Docker来说,假如真正要上业务,监控是很重要的一个话题。 携程一般在Linux上监控数据,大多数是来自proc文件系统,proc文件系统在Docker容器里面,我们知道Docker容器做隔离其实提供namespace ,对于PID做得很好的namespace ,这个没有问题,网络统计也是很准确的。但是很多很关键的CPU、内存使用这些在proc系统里是看宿主机。还有一些监控的系统比如sysinfo sysconf这些是没有任何的秘密空间提供的。所以这些数据来源是很成问题的。 对于Docker来说,我们监控该怎么办?其实现在有一些方式,比如说在宿主上监控所跑的容器现在也有方案,比如说Docker很早就提供了stats命令,可以看到每一个容器的读数,包括跨设备网络。还有一些比如像cAdvisor方案。为什么会看这个?因为在携程用的方式是zabbix,每个虚拟机里面都跑zabbix。这种方式是在宿主机上。但是下面每个虚拟机的监控数据对于携程来说,其实与现有的监控的方案不是非常的匹配,因为他们希望能够看到每个虚拟机单个作为一个的对象,能看到它的监控数据,而不是在宿主机上看到下面那些挂的。包括监控、告警这些都是有关联的。所以这些方式其实跟现有的监控的方案是有整合的成本在里面的。 如果想尽量减少修改,还有一种是容器内部监控它。之前听蘑菇街的分享,他们直接把监控工具改掉。还有一个是很多人很关心的一个项目,它基本的原理用了files文件系统,实现了对proc文件系统的代理,它帮你代理、修改proc文件系统的访问,把数字计算一下获得一个正确的。正确的数据其实都是从cgroup里面读出来的。 这个方式解决了这个问题之后。我们可以在容器内部获得正确的监控数据,包括启动时间,上线后怎么登进去了,怎么看到这个容器给它分配的资源是多少。一看宿主机48,怎么分了这么多给它?但是还是有一些问题,比如前面改内核者或者改工具,维护这些改动的成本在里面,还有一些部署。所以也有一些问题。 后来携程想到另外一种折中的方式。这个方式是说,它们通过用Linux的Id prelod的机制,劫持对proc文件的访问,真正需要获得的数据是参考IXCFS的实现,重新计算一下,也是通过从cgroup里面计算你分配了多少内存,使用了多少,CPU是怎样的,去计算的一个资源。当然CPU load挺麻烦的,需要额外支持。

15

图三

图三中有个例子。可以看到,这个容器里面,用了劫持的方案计算了之后,可以看到大概分了两个G的内存。把环境变量去掉之后,看这个宿主机,大概一百多个G的内存。它的工作方式,比如说,如果是free,就是命令,它真正在运行的时候,会有Id so init去加载二进制文件的时候,会先加载我们的so 文件,它会把真正的open库的实现给劫持掉。到这里是一个标准的劫持的过程。 之后free读文件的内存信息的时候,它其实读的是/proc/meminfo文件,劫持过来的时候,真正的逻辑到so文件里面,它读这个文件知道是干什么。实际上它读cgroup和lxcfs是一样的,计算然后把它保存到一个临时文件里面去。最后返回的是这个临时文件fd,Free会读这个临时文件。原理就是这样的。 其实携程在容器上还有很多事情要做。比如说,不光是为交付给用户的计算环境提供容器,其实想把自己的一些很多东西都放到容器上去。比如携程的OpenStack平台也想跑到Docker里面去,因为OpenStack很复杂,部署起来也是件很头疼的事情。 现在携程是用虚拟机的方式跑容器,其实是很重的。所以也想直接基于镜像的方式来应用持续交付。这就牵涉到很多东西,包括调度,打包,各种系统,包括进项的版本管理等。 将来的微软的windows  Container也是对携程影响很大的一个技术。另外如何进一步获得更高的的资源调动,如何动态的调度这些资源也是携程需要关注的地方,所以接下来携程还会有很多事情要做。

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接