中国电信基于Mesos+Docker的运维自动化在CDN中的实践

本次分享讲解容器技术在CDN系统中的应用，包括应用的容器化，使用Mesos、Marathon、ZooKeeper对线上业务的快速部署、升级、回滚以及Docker在研发测试环境中的实践。在引入Docker技术之后，CDN不同角色的服务部署在一个物理服务器，资源利用率明显提高，另外应用都可以一键部署，运维工作量明显减少。

大家好，我是中国电信云公司CDN运营中心的张其栋，今天跟大家分享的题目是《中国电信基于Mesos+Docker的运维自动化在CDN中的实践》。CDN指的是内容分发网络，指的是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定，提高用户访问的响应速度。

今天跟大家分享三部分内容，第一部分是使用Mesos+Docker的大背景，就是我们CDN的整个架构。第二部分是怎么用Mesos+Docker落地的，最后是在Docker落地过程中遇到了一些坑，跟大家分享一下。

首先介绍一下我们的CDN运营中心，隶属中国电信云公司，部门成立的时候，要做一个融合的CDN。主要的业务包括承载天翼高清、IPTV和传统CDN业务。目前天翼高清盒子正在卖，有将近30万的用户。目前我们也在做融合IPTV，还有传统的互联网公司的CDN加速业务也在做。

下面我介绍一下业务范围，天翼高清这个项目未来会覆盖全国各省，有上亿用户。主要包括的内容就是天翼高清和IPTV。CDN中主要使用的技术有音视频加速，CDN传统业务中，还有图片、静态网页加速。

因为后期的范围比较大，用户比较广，我们后期的设备量会达到几万台。当时我们就考虑到，未来自动化运维相关的东西，考虑到不能再用传统的思路进行运维了，因为那样的话，对于运维的压力就太大了，几百台、几千台设备的时候可能还好，但是到了上万台设备之后，再用传统思路运维，压力是不可想象的。

这是我们整个CDN架构，主要包括4个内容，一个是上层调度，内容分发、内容的管理还有最后的运营管理。调度有基于DNS的全局调度，基于HTTP 302、301的精准调度，还有我们现在一直在做的IP地址库，以及实现之后，实现自动化的调度，最终实现业务的自动迁移。

中间这部分就是内容分发，内容分发从内容中心到省节点，最后到地市边缘节点这部分，CDN在全国的整个架构，从北京、南京或者广东中心到分中心，最后到省中心。

下面就是我们的内容管理。音视频的加速肯定要有内容，首先要从CP方把内容引入进来存储，最后给用户进行加速。最后一部分是运营相关的，有CDN自动化运维、监控告警、日志分析、客户管理和后面的计费。

这个图是目前我们天翼高清内容分发的一个详细架构图。最上面这部分是我们从CP方拿到内容之后，放到三大内容中心，这三大内容中心，包括存储的所有内容，目前放到广州、南京和北京。有了这三大中心以后，九大区域中心就可以去三大中心取内容，再下面是各省中心，最后到边缘节点，最后用户从边缘中心拉到对应的内容，实现最后用户的访问。

在这个架构中，缓存是内容分发特别主要的组件，它把所有热点的内容，缓存到边缘，实现用户的就近访问，改善用户的访问速度、提高服务质量。目前天翼高清项目主要用这个架构，后面我们会基于整个架构再做图片和静态网页的加速。另外缓存服务器，我们用的是三级缓存，分别是硬盘、固态硬盘还有内存。这就是我们整个的CDN架构。

下面这个部分就是我们使用Docker的落地。首先我们在前期调研了以下容器技术有哪些优势，容器的生态系统中，我们运用Docker和系统中的生态组件，我们到底具体能实现哪些东西？

第一个，首先我们考虑到的是自动化部署，我们有将近上万台的设备，首先我们要解决的就是部署和升级的问题，有了Docker以后，第一个可以实现自动化部署，可以实现一键部署所有的设备，当然也有一键升级和一键销毁。

第二部分是持续集成，包括敏捷开发和提高开发效率，这个主要是对公司研发和测试。有了持续集成的环境之后，开发的迭代速度明显加快，包括测试相关的都可以用自动化的方式来进行。

第三部分是弹性调度。因为业务出现异常的可能性还是存在的，当业务出现异常的时候，如果我们使用Docker技术以及生态系统中的这些组件能否实现自动化的恢复呢？这也是我们当时最后选择Docker的很大的原因，它可以实现自动化的恢复。另外物理设备宕机了，这是最致命的，物理设备挂掉以后，我们也要通过容器化的方式迁移到另外一台物理设备上，从而不间断业务。

最后一个就是资源复用。大家都知道Docker是轻量级虚拟化。我们可以在一个物理设备上部署N个Docker，我们可以在同一台物理设备上部署不同的业务，不同的业务对硬件资源使用情况是不一样的。这样的话，我们就可以把一个耗CPU比较多的服务和一个耗内存比较多的服务放到一台物理设备上。这样的话，就可以实现物理设备资源利用率最大化，最后提高资源的利用率。

我们选择了Docker之后，首先要做的是实现业务软件的容器化。总结了一下，在整个CDN架构中有五大组件，第一个就是直播转码，我们是做音视频相关的东西，天翼高清的直播和点播，我们主要用的是，先把直播转码和直播切片相关的东西放到容器里面去，先在测试环境里面跑。因为直播软件是我们这边的架构师自己开源的一个软件gstreamill，大家可以在GitHub上找到，功能还是挺完善的。首先针对自研的软件进行容器化，这样的话，难度和可控性都会降低一些，业务软件和容器都可以针对调整。

第二部分，我们用的是缓存。刚才介绍了，缓存在CDN中是非常大的一个组件，它占的比重是非常大的。基于ATS我们做了相应的开发，这是我们实现的第二个业务的容器化。

第三个点播转码和业务切片的软件，最后也要实现容器化。还有Nginx，最后是GSLB全局调度。

有了这些组件，实现容器化，要实现这些组件的一键部署，包括一键生成镜像，一键升级所有的业务，还有自动化配置相关的东西，最后通过自动化的方式解放运维，提高运维的效率。

这是我们具体的直播转码的业务软件实现容器化。当前我们所有的业务软件都用Dockerfile实现容器化，线上的业务可以使用镜像。因为做直播转码，特别是音视频相关的东西，它对包的依赖要求是特别严苛的，必须要统一。但是有一些软件，特别是新版本的软件，你要下载它，这次下载可能是不成功的，可能10次成功3、4次下载对应的依赖软件。

大家可以看一下，Dockerfile有3页，生成第一个镜像之后，你再用的话肯定简单一点，因为在Docker里面有一个默认的机制，生成镜像的时候，它会自动缓存，你可以设置它不缓存Dockerfile生成镜像的时候的中间内容。因为它依赖特别多，我们做了一个改变，把Dockerfile分开，先做一个基础的镜像，一直到最后一个RUN，上面的所有的镜像，我们都做了基础镜像，几乎不改基础镜像，需要改的时候生成一下它，然后再用我们自己开发的软件再用Dockerfile生成镜像，这样我们生成Dockerfile的时间就会大大缩短。

大家可以看到在CMD这儿，我们有一个共享内存，我们使用Dockerfile生成镜像的时候，使用Docker的时候，发现Docker的共享内存默认的只有64M，当时我们使用的那个版本Docker是不可以更改共享内存的，当然新版本Docker已经支持共享内存的设置了。下面就是我们的启动命令，这是我们做的一个Dockerfile，其他的就不介绍了。

我们实现了业务软件的容器化之后就要选择编排软件了。当时我们也调研了三个比较主流的编排软件，第一个就是Swarm、谷歌的Kubernetes，最终我们选择了Apache的Mesos。当时我们选择Mesos的原因有几个，一个是它相对比较成熟一点，当时Twitter已经在用了，当时是2015年的6月份左右。另外，在架构图里面介绍到了，包括一些数据分析相关的东西等。调研发现这些软件跟Mesos结合起来更容易一些，而且社区内也有一些成功的案例。Mesos是一个抽象和管理集群中速度资源的工具，把所有的资源集中起来，最终形成一个数据中心操作系统，而Mesos就是整个数据中心操作系统的内核，基于Mesos再做相应的开发，这样就使整个系统是一个系统。

选择了Mesos以后，集群搭建要有这4个软件，一个是Mesos的Mastes、Slave、Marathon和ZooKeeper。

Mesos Master是主节点，分配Slave的资源，管理整个集群。Mesos Slave管理本节点所有的执行器，Master Slave可以扩容到一万个节点。Marathon是专门为Mesos而生。用Marathon可以对Mesos上的Slave进行任务的下发，指定哪一个Slave执行什么样的任务。ZooKeeper是分布式应用程序的协调服务。这样我们就可以搭起我们自己的架构。

这是我们整个Mesos的架构。上面这部分是我们的Master集群，目前我们测试环境和线上环境都用3台Master的集群，这个集群包括3台Master，3台ZooKeeper，以及3个Marathon，并且Marathon上的任务数目前将近有300个。右下角就是Mesos Slave的集群，在这个地方可以放N个Slave，可扩展10000个左右。目前在线上集群中Slave有200多台。

另外再有一部分，Etcd存储集群，这是我们配置相关的集群，大家把前期的配置，都会默认到写到Etcd集群里面去。当对应的某一个Slave需要对应的配置的时候就去Etcd拉去配置，实现每一台设备的差异化。目前主要用IP作为同一软件唯一的区分方式。

下面这部分就是我们持续集成相关的东西，当一个工程师把代码提交到我们的服务器上之后，当文件中的标志改变了以后，会自动构建生成Jenkins的Job，自动生成镜像，如果成功的话就PUSH到我们测试环境里面。如果测试成功的话，就会发邮件通知，告诉运维同事，这个镜像可以用了，以及我们的Etcd集群里面，配置也会做好相应的准备，就可以自动向Slave集群里面下发任务了。

当然这个地方主要是用Jenkins做的集成，不可能每一次都是成功的，如果失败了，我们也会发相关的邮件通知，把错误的日志信息发送到负责相关代码的工程师的邮箱里，通知修改代码，直至生成镜像。

这里面还有一部分是Mesos Master集群，我们下发任务的时候，也会去Etcd里面取，另外也有一部分内容要从Master往Etcd集群里面写内容。还有一部分是Mesos Master和Mesos Slave之间的自动调度。如果设置选择了有10台服务器进行部署设备，但是你可以部署9台，如果其中有一台设备出现了问题，类似于宕机，它就会默认的再另外一台设备把这个任务集成。访问Mesos Slave的时候，也会把IP放进去了，如果IP内容访问服务失败了，会默认再探测另外一台，这样就实现了弹性调度。

我下发任务以后，会检测Mesos Slave是否有镜像，如果没有的话就去下拉。每次下发任务的时候，如果有镜像的时候，第一次会把镜像拉下来，如果想第二次再下发任务使用相同的镜像的话，可以设置一下，还可以再下拉一次，也可以不设置，这个就要看大家自己的选择了。

这就是我们做的Etcd配置的管理界面，通过这个管理界面，我们可以对Etcd集群里面所有的内容进行更改。这是登录界面，这是健康检查，检查IP地址配置是否存在，以及有没有异常。在这个界面里面我们可以对Etcd进行更改操作和删除相关的操作。这个界面是基于Etcd原生的界面进行修改把那个加进来了。最终通过这个界面，我们可以针对我们的其他业务实现最终的修改。对应一个IP地址，它里面的配置，我可以更改里面一个组，也可以实现一下更改10个IP或者100个IP里面的相同的内容，这样的话最大限度的实现解放运维。

当我们使用Etcd的时候，虽然配置改了，但是还要重启具体的业务，在Docker里面你是不能重启的，所以只能reload这个业务。当我们更新这个配置以后，会勘测，每隔10秒或者5秒勘测一下这个业务的配置是否进行了修改，如果修改以后会把这个配置拉下来，确认成功以后就会reload具体的任务。目前主要用到我们的Cache服务当中，因为这里面的硬盘和CPU，甚至内存都是有差异的，通过这个可以让它实现它是一个标准的过程，但是具体不一样的操作是在这里。

另外我们还写了一个Etcd相关的获取服务器上相关的资源。比如说硬盘和CPU这种，甚至是另外一个IP地址。因为我们目前的设置有两个IP地址，一个是公网的IP，还有一个内网的IP。获取到这个IP地址上传到Etcd，注册到Etcd集群里面存储起来，等待着使用。

这样的话，整个流程就可以跑通了，从生成镜像到Etcd的配置，实现每一台物理设备的差异化，这样的话，整个服务就可以跑起来了。

这些都准备好之后，我们就可以下发具体的任务了。这是我们用Marathon下发一个直播转码的任务。下发脚本，就可以对Marathon下发任务，最后实现具体在哪个Slave上执行这个。最上面就是一个ID，下面就是使用Docker，再下面是使用具体哪个镜像。去我们自己镜像仓库拉下来，我们用的是HOST网络模式，给了它最高权限，因为要改共享内存，然后强行下拉，然后把日志目录映射出来，下拉一个内容，HOST作为唯一的标志。具体资源是多少，可以分配多少个CPU、多少内存等。这就是整个Marathon下发的内容。

其实这些都跑通以后，这些并不是我们的终级目的，我们也想把资源更加充分利用起来。目前我们的设备上都是我们自己的业务，直播点播缓存，301、302的调度。我们分析完了以后，我们发现直播是最耗CPU和内存，点播最耗CPU，缓存耗硬盘和内存，30* 最耗网络。因为目前我们所有的服务都是供我们自己服务的，这个物理机就是我们自己的。所以说我们要使用Docker轻量级的资源隔离，这样的话，我们就不用考虑其他的问题，我们就可以实现资源的复用，直播耗CPU和硬盘，302相关的服务软件耗网络比较多。这样就可以把直播和缓存放在一起使用。一个服务器可以放两个组件。如果我不想使用302放在这个设备上，我直接把Docker一删，系统没有用过302用过的痕迹。点播和缓存可以放在一起使用，一个耗CPU比较多，一个耗硬盘比较多。

比如说我们的IP探测，生成IP地址库的一些小软件，它对CPU和其他的资源用的比较少，可以放到这些服务器上。可能它需要的量比较大，但是对于资源的使用并不多，但是需要多个客户端运行，我们就可以放到所有的设备上同时进行，把任务分配好就可以了。

其实资源利用在业内来讲是一个非常大的痛点，资源利用率比较低。用这么一种方式和弹性的调度来讲，就更加让这个资源利用率会更高一些。这是我们目前具体的使用情况。

大家可能关心的就是你的架构到底放了多少台设备，这么多设备跑起来是不是安全，包括稳定性，这里面是我们上线业务的具体时间。2015年10月上天翼高清直播服务器，这里都是物理机。天翼高清上了一百台，一开始我们测试环境里面测试十几台之后，我们就慢慢的把这一百台都上到了整个天翼高清的项目里面。11月份我们紧接着上了60台的点播设备，目前都在跑，挺正常的。另外就是2016年1月份的时候，我们上线了某一个直播网站的业务测试，它用了30台的物理设备，包括全国有七八个省份，每一个省份有3、4台的样子，都是在我们整个Mesos平台上进行管理的。后期测试完了以后，这30台设备把资源成功回收了，效果还是比较理想的。

最近我们才上线的福建省的缓存服务，26台Cache设备，这些设备最终都会纳入到整个管理平台上去。目前来讲，一共有200多台物理设备，业务范围有直播、点播和缓存。目前我们主要做的就是缓存相关的一些，把软件都放到我们的Mesos直播管理平台上。因为Cache服务量是特别大的，特别是用户量越大，Cache服务器就会越多。考虑到Cache服务器，后期可能有上万台的设备，我们在搭建另外的Mesos集群专门进行管理Cache。

另外说一下我们的升级次数，这些业务都升级了几十次，最终都平滑升级了，中间肯定遇到一些小问题，一些小坑，大家也都会去弥补它。

最后一个部分给大家讲一下我们在整个落地过程当中遇到的一些问题。第一个Docker默认共享内存太小，普通权限无法更改，最后我们就给了最高权限。现在新版本Docker已经支持更改共享内存了，在测试环境里面我们用新的命令去更改，目前测试效果还是比较理想的，并没有出现致命的问题。后期我们也会把最高权限去掉，使用命令行进行共享内存的更改。

另外一个问题，Docker最高权限会把容器107G存储给写满，如果你写满之后，再想生成一个容器的话，Create成功，但是RUN不起来。这个有两个方法，一个是更改107G存储，给它一个2T或者4T的大硬盘，这样的话不能从根源上解决问题。最终我们想了一个办法，从业务软件上避免这个问题。首先把日志尽量往小了写，另外把日志映射出来。

另外一个问题，我们在直播程序中，直播转码和切片中我们需要获取CP方给我们的组播流，但是我们获取不到组播流，最后我们给这个容器HOST模式，性能上几乎没有损失了，用的网络可能比较多一点，目前我们还在用HOST模式。

还有一个可能是Docker的bug，防火墙进行修改以后，Docker网络环境是不通的。修改了防火墙，重启防火墙之后，之前RUN起来的镜像，再RUN的时候，网络是不通的。目前我们的解决方案，只能规避它，我们在使用镜像的时候，先把防火墙所有的配置参数调好以后，具体后面再用镜像的话就会好一点，不要重启防火墙。

我们使用Cache的时候，要对Cache软件要有一定的了解，你用的内存比较大的时候，你下发任务的时候，对内存配置比较小了以后，容易发现这个容器特别慢，因为特耗内存。在做任务下发的时候，要对业务软件有一个更加了解以后，再容器化和下发任务，遇到的坑可能会更少一点，不能以为给它最大的就是最好的或者是一些相关的操作。这就是今天分享的全部内容，谢谢大家！