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

容器对携程的价值 为什么要在携程内部推容器？肯定是想获得容器带来的好处。公共的好处大家都会知道，但有一个可能是携程特有的痛点，因为携程有大量的应用是部署在Windows上，因此携程也很希望将来Windows的容器会给它们带来一些提高和帮助。 目前携程为容器在内部的推动制订了一些路线图。携程希望尽量以虚拟机的方式来运行容器，这主要是考虑到它带来的优点是对现有的应用和体系的影响小，携程希望尽量以平滑的方式过度到容器中。但是，目前在推广上会有一个困难，大家会在你推销它的时候质疑，因为改变很小意味着带来容器特殊的优势很少。而这个确实是它的缺点。另外目前在携程内部主要是通过 OpenStack来管理云架构的基础设施。 携程部署Docker的架构

图一

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

图二

除了容器本身生命周期之外，网络的架构复用了现在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挺麻烦的，需要额外支持。

图三

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