新东方利用容器技术在用户自服务方面的探索

如何减小运维团队的平常杂事？如何将服务平台化，赋予用户自我服务的能力？新东方云利用Rancher容器管理平台、Harbor镜像仓库和GitLab构建企业应用商店。赋能运维团队和用户，尝试破解用户自服务的难题。

---

开场先讲个小故事：

运维团队一线支持小哥接到某团队的工单，要求部署一套TiDB作功能测试。小哥在云平台上申请机器，按照内部标准的部署文档安装配置，最终交付给该团队。小哥回复邮件后已是下午3点多了，小哥的一天就这么过去了。平淡无奇的运维工做彷佛就应该是这样的。

我相信这是大多数运维团队都会面临的问题，运维团队面临着不少不断重复，事务性的工做。组织规模变大之后，像这样有的没的项目都会来运维团队寻求支持。运维团队招了不少人，忙了一年下来，发现好像也没作成什么事情，功劳彷佛都是别人的，成本都是本身的。为何会这样？由于运维团队的大量时间和精力在服务其余团队的杂事中消耗掉了。

这也是咱们信管部王威老师提出建设新东方云的初衷之一。咱们设想是否能把手中的资源和咱们的服务平台化？经过定制和开发，最终咱们交付出去的不是针对具体项目的劳务，而是一个服务的平台。让大部分重复性的平常部署和维护工做由用户本身完成。咱们将运维能力直接赋予其余团队和用户，让运维团队能将精力集中在提升SLA和技术提高上。
这也是我今天分享的主题，今天主要分享一下新东方利用容器技术在用户自服务方面的一些探索。

首先简单介绍一下新东方云和容器云服务：

新东方云采用自建数据中心 IDC 公有云的混合云架构，提供包括：云服务器、对象存储、分布式文件系统等IaaS层面的服务，提供消息队列、缓存服务等中间件层面服务，以及运维大数据方案和视频服务等等。

容器云服务是新东方云提供的最新服务，目前还在beta阶段。咱们的容器云平台也是基于Docker、Harbor等主流技术做为后台，使用Rancher提供的Cattle做为编排引擎。

提到Rancher你们可能也据说过，简单介绍一下Rancher。

Rancher是一个轻量级的容器管理平台，CNI兼容的网络服务、存储服务、主机管理、负载均衡等功能。Rancher如今分为两个分支：

X：采用Rancher本身开发的Cattle编排引擎，已经有一套完整的平台和全球众多的粉丝。

X：目前已经进入beta阶段， 2.X分支则彻底将Rancher创建在Kubernetes之上，提供对公有云或自建的各类Kubernetes平台的纳管。

咱们选择Rancher的主要是出于如下考虑：

项目100%开源，可选的商业支持。
提供丰富的API，可供用户自行定制。
学习成本低，直接沿用了Docker生态，好上手。
内置的应用商店框架（Rancher Catalog）。

Rancher Catalog功能相似Kubernetes的Helm，提供对应用的打包定制，并提供一整套用户UI。用户只须要简单输入便可部署一套应用。这刚好也是咱们比较看重的功能。咱们尝试将平常经常使用的基础软件经过容器云平台打包，发布在企业应用商店中，这样团队内部在须要的时候只须要简单的经过界面设置一下就马上得到这个服务。

说了这么多，应用商店是什么样的呢？下面就详细介绍一下应用商店的原理和实现。继续开场运维小哥的故事，一样的工做，他如今只须要打开应用商店：

填写一下表单：

大概等待3分钟左右， 一套完整的TiDB环境就出来了，期间小哥彻底不用理会这边建立的过程，能够作其余事情去了。

建立好后根据暴露出来的端口和IP，直接链接便可。

这就是应用商店建立应用的流程，从图片中你们也看到，咱们还在不断的增长企业内部应用。

好比图片中的SQL Server 2017 on Docker，定制这样一个应用的时间不会超过半天，复杂一些的应用两三天也能写完。

那么下面就简单说说应用商店的实现原理：

应用商店的组件

镜像仓库

咱们选择的是业界广为使用的Harbor项目，我相信你们也很了解了。

简单介绍一下：Harbor是VMware中国团队开源的一套基于Docker Registry构建的镜像仓库项目。这个项目集成了CoreOS的Clair脆弱性检查工具和Notary镜像签名工具，配以LDAP集成，UI等企业应用必须的功能。能够说是目前企业镜像仓库的首选项目， 此项目为开源项目。用户能够下载下来自行定制。

咱们对Harbor进行了简单的定制，咱们的Harbor直接对接Ceph对象存储（经过Swift接口）。 这样后端存储在性能和可靠性上都有保障。同时前端也能够根据须要进行扩容，实际上Harbor中除了MySQL和Pg数据库外，其余服务都是无状态的，彻底能够作到自动扩缩容，目前Harbor有基于Kubernetes和Rancher（社区Catalog中）的实现，你们能够参考。

咱们目前的实践是经过docker-compose方式离线安装的独立部署的，后期会考虑以独立的environment方式归入Rancher的管理中，后面有进一步的实践成果后再和你们分享。这里就不展开说了，有兴趣的朋友能够看一下个人工做笔记：http://jiangjiang.space/2017/...://jiangjiang.space/2017/11/03/harborregistry设置ceph对象存储/。

源码仓库

源码仓库是用来做为应用商店的载体，应用商店其实是一个Git的项目。全部的编排文件以目录的形式存放在指定的路径下，这样Rancher就能读取为一个一个应用。

如图：

GitLab中的目录结构：

Templates下面是各个应用。

使用私有部署的GitLab或者直接使用GitHub也能够。

终于说到重点了，应用商店

以前提到过Rancher的Catalog和Kubernetes的Helm很类似，好比Helm各类Charts，Values和Templates等定义，帮助用户固化对应用的定制。Rancher的Catalog也是这个设计思路，Helm围绕Kubernetes，Rancher则是围绕Cattle而生。

下面以Catalog中的一个应用来解释一下。这是刚刚TiDB应用的目录结构：

0目录和1目录是版本目录，Rancher能够帮助维护应用的版本，能够帮你把老版本的应用实例升级到新版本，升级动做也是经过应用商店手工完成的。

进入0目录能够看到文件，这就是Rancher的服务定义文件了。

看到熟悉的docker-compose.yml和陌生的rancher-compose.yml，这两个文件的关系要从Cattle提及。

Rancher的Cattle编排引擎设计的很巧妙。 Cattle直接用docker-compose定义服务和服务的关系，好比一个服务使用哪些镜像，暴露哪些端口，存储卷定义等等。咱们知道docker-compose实际上是一个单机容器编排工具，直接做为集群编排文件的话还缺乏不少重要元素：

缺乏对服务的replica（副本）定义。
缺乏容器之间的隶属关系（模拟Kubernetes的Pod），经过deponds_on能控制service的前后启动，可是一个service中的多个容器之间的关系就没有了。
缺乏对服务的编排控制，好比一个服务起来后调度到哪一个主机上。
缺乏对容器的生命周期控制，好比只在服务启动时某容器执行一次，重启服务也再也不启动等。

docker-compose缺乏的定义则由rancher-compose.yml来补充。实际在执行时Cattle只是根据编排规则，将docker-compose文件中容器的定义部分直接丢给对应主机的Docker执行建立容器。利用Docker容器的label功能作标记，容器起来后Cattle从label中获取容器的现状，再与编排规则作对比看看是否知足要求， 好比：Scale，多了就干掉，少了就拉起。有了这两个文件的定义Cattle就能够在各个主机间调度和建立容器了，举几个调度的例子：

a：若是要调度一个容器到某个主机上，只须要在容器上打上以下标签：

Cattle就会将容器的定义发送到有cn.xdf.edge=true标签的主机上，随后启动容器。

b：更复杂一点的调度实现，好比在每一个主机上只启动某服务的一个容器（单例），或者说相似Kubernetes daemonset，这个在Rancher里是怎么实现呢？

这个标签会把容器在每台主机上启动，并只启动一个。

若是我不想占用全部主机，只是按照Scale数目调度到目标主机，而且每一个主机只跑一个实例：

这个意思是说：

启动时的主机上必须没有符合冒号后面表达式的容器，而且是一个软限制，去掉soft则是严格限制。
服务名字是这个服务的实例名和服务名。

也就是说只要这台机器启动了这个服务的一个实例就不要再调度另外一个上去。

还有其余一些标签：

io.rancher.sidekicks：容器名，容器名
设置从属容器，好比作个side car容器，你但愿第一个容器启动提供存储volume，而后启动第二个容器跑服务，接着第三个容器作日志的接收转发等等。
io.rancher.container.pull_image：always

启动服务时老是拉取容器镜像

详细的调度和标签说明请参考：http://rancher.com/docs/ranch...。

rancher-compose除了定义调度外，还提供了questions功能。

questions设置一些问题，用户在启动的时候输入，输入的结果保留到answer.txt中, 这个设计相似helm的values_file，只不过value文件不是预先定义的，而是用户启动时输入后产生的。

根据上面的定义，Rancher UI会为不一样类型的question配置输入框，好比 enum是一个下拉列表， int是一个只能输入整数的输入框，Rancher会作基本的输入检查。

上图的代码会被自动转化为下图中的UI。

解释到这里可能你们就明白了，这就是应用商店的原理：

一套服务和容器的定义（docker-compose）
一套编排的设置（rancher-compose）
一套用户能够输入值的UI
用户在UI中填入值

随后由编排引擎交给主机上的Docker执行。

应用商店使用状况：

目前应用商店主要是运维团队内部使用。下一步咱们打算以Rancher做为管理后台，经过调用Rancher的API，对接到新东方云平台上。与新东方云现有的申请和开通流程保持一致，简化用户的输入，最终造成一套用户能自服务的PaaS平台。

我最近会将Rancher 1.X的实践工做作一系列的总结，具体技术细节你们能够关注个人工做日志http://jiangjiang.space。

推荐阅读

推荐阅读

原创干货│利用Rancher构建容器服务

原创干货│生产环境部署容器的五大挑战及应对之策

CaaS“容器即服务”：是营销手段仍是有其价值？

钢铁电商平台的Docker容器云平台建设实践微信号：RancherLabs