Ranger开源流水线docker化实践案例

1.背景

开发部门决定在Apache Ranger开源社区贡献代码，目标是个人国内排名Top1，世界排名Top2，并且在已经成为Ranger项目的Committer情况下，争取成为Ranger项目的PMC。同时部门投入的开发人员人力非常有限，开发人员的水平也无法和国外开发人员相比肩，大部分开发人员对于Ranger的熟悉程度也有限，在这种情况下我们不仅要提交自己的issue，还要积极review别人的issue,为了在提高效率达到目标的同时，尽量减少错误的发生，比如提交的issue补丁有问题，review别人的issue不完全，从而导致错误的代码被合入到Ranger代码库中，将会在开源社区产生非常不好的影响，不仅会使个人口碑和公司声誉受到影响，而且会影响我们达成对开源社区贡献的目标。

现在我们决定为Ranger的开源代码在所内搭建一套流水线，从代码提交到编译打包安装测试一整套流程，来保证我们向社区提交的代码不会出错，还可以帮助我们在review别人代码的时候验证相关功能，即使有其他开发临时加入，也可以很好的保证质量，尽量减少工作中可能发生的错误，特别是避免一些低级错误，从而在增加自己在社区的威信和话语权，达成开源贡献目标的同时，为以后我们部门和公司在开源社区更好的发展打下坚实的基础。

另外，虽然Ranger的所内代码是已经有了一套流水线的，但是所内Ranger是经过修改定制的，增加了一些无法合入社区的特性，并且阉割了一些用不到的功能，而且是基于DapManager开发和测试的，编写的测试用例也是强依赖DapManager的，同时所内的代码版本无法和开源的代码保持实时同步，两者在某种程度上是不兼容的，只能一定程度上借鉴，所以需要为了Ranger开源代码搭建一套新的流水线，专门用于开源。

2.Ranger

Apache Ranger能够监控和管理整个Hadoop平台的综合数据安全，它是Apache Top Level Project(TLP顶级项目)，主要提供如下特性:

• 基于策略(Policy-based)的访问权限模型
• 通用的策略同步与决策逻辑，方便控制插件的扩展接入
• 内置常见系统(如HDFS、YARN、HBase等12个)的控制插件，且可扩展
• 内置基于LDAP、File、Unix的用户同步机制，且可扩展
• 统一的中心化的管理界面，包括策略管理、审计查看、插件管理等

Ranger架构图：

3.方案

搭建Ranger开源流水线，经过研究之后，决定使用如下工具方案：

Jekins + Gerrit + Docker + RobotFramework

其中Jekins负责流水线整体流程，Gerrit负责Ranger代码，

Docker负责打包安装运行Ranger等业务组件，RobotFramework负责测试用例。

持续集成（Continuous integration，简称CI），根据敏捷大师Martin Fowler的定义，“持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次，也可以多次。每次集成会经过自动构建（包括自动测试）的检验，以尽快发现集成错误。许多团队发现这种方法可以显著减少集成引起的问题，并可以加快团队合作软件开发的速度。

持续集成流程图：

下面是持续集成的图谱介绍：

1.将更改提交到代码管理仓库

2.持续集成服务器收到请求拉取变更代码

3.持续集成服务器编译代码

4.持续集成服务器跑代码相关测试

5.持续集成服务器测试结束

6.持续集成服务器对结果进行反馈

根据上面的持续集成流程图，我们会重点介绍上面选型的4个工具在持续集成中的作用:

3.1.Jekins

Jenkins是一个可扩展的持续集成引擎。

主要用于：

• 持续、自动地构建/测试软件项目。
• 监控一些定时执行的任务。

Jenkins拥有的特性包括：

• 易于安装-只要把jenkins.war部署到servlet容器，不需要数据库支持。
• 易于配置-所有配置都是通过其提供的web界面实现。
• 集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知。
• 生成JUnit/TestNG测试报告。
• 分布式构建支持Jenkins能够让多台计算机一起构建/测试。
• 文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。
• 插件支持:支持扩展插件，你可以开发适合自己团队使用的工具。

3.2.Gerrit

Gerrit是一个免费、开放源代码的代码审查软件，是基于网页界面的代码评审工具，它基于git版本控制系统。

Gerrit旨在提供一个轻量级框架， 用于在代码入库之前对每个提交进行审阅。开发人员将代码更改提交到Gerrit，但实际上并不成为项目的一部分，直到它们被同一个团队的软件程序员相互审阅，决定是否能够提交，退回或者继续修改。它是标准开源过程的一个简单工具来支持提交补丁程序。Gerrit首先是一个临时区域, 由项目成员在应用到代码库之前进行评审，只有在被评审确认通过后，提交的代码才会正式成为代码库的一部分。

3.3.Docker

Docker是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。开发者在自己机器上编译测试通过的容器可以批量地在生产环境中部署，包括VMs（虚拟机）、bare metal、OpenStack 集群和其他的基础应用平台。

Docker通常用于如下场景：

• web应用的自动化打包和发布；
• 自动化测试和持续集成、发布；
• 在服务型环境中部署和调整数据库或其他的后台应用；
• 从头编译或者扩展现有的OpenShift或Cloud Foundry平台来搭建自己的PaaS环境。

3.4.RobotFramework

Robot Framework 是一款用Python编写的通用的自动化测试框架，支持关键字驱动且可扩展性好，它具有易于使用的表格来组织测试过程和测试数据。它主要用于需要进行多次验收的系统测试，或者验收测试驱动开发，框架能够提供用例组织，生成测试报告，尤其对于一些常年需要维护的系统来说，价值更大。

Robot Framework的特点：

• 使用简单
• 非常丰富的库
• 可以像编程一样写测试用例
• 支持开发系统关键字

RIDE是一款专门用来编辑Robot Framework用例的软件，用Python编写并且开源。当我们针对一个系统编写好一套脚本后，每当我们对系统做一些更改的时候，便可以把已经写好的脚本拿出来稍作修改，通过执行这些脚本就可以检测系统的功能是否依旧完好。系统需要一个不断完善的过程，而RIDE用例也将随着系统的变更做着相应的修改。

3.5.工具集成

将上述4个工具集成到一起，完成Ranger开源流水线的搭建，整个过程可以使用如下流程图表示：

JekinsWithDocker.jpg

上图演示了Jekins + Gerrit + Docker + RobotFramework集成在一起之后的工作流程图，由于是从网上下载的图，特别说明其中Github可以等价于Gerrit，在进行itegration test的时候会调用RobotFramework编写的测试用例。

详细步骤的说明如下：

0.开发人员提交Ranger代码到Gerrit

1.触发Jenkins流水线构建操作

2.Jenkins将Ranger代码编译、打包

3.Jenkins将Ranger安装包封装在Docker镜像并上传至Docker仓库

4.Jenkins使用Docker安装Ranger及部署Ranger所需要的一系列测试环境

5.Jenkins调用RobotFramework编写的测试用例进行集成测试

6.集成测试通过，触发真实应用环境部署

7.对真实应用环境进行集成测试

8.提供外网真实用户访问

在实际使用中，我们会用到0--6这个步骤来测试Ranger，后面对外提供环境的步骤忽略。在第6步集成测试通过之后，我们的开发和测试人员也可以访问Ranger的测试环境了。

4.Docker实现方案

4.1.设计背景

采用Docker来进行Ranger环境的编译打包安装，是基于Ranger的架构设计考虑，Ranger本身的架构是由多模块组成的，各个部分相对独立，而且和其他组件有着大量的交互，不像其他组件那么单一，使用Docker能够很好的适应Ranger这种分离设计，发挥出Docker的巨大作用。

查看第二章节中提供的Ranger架构图，其中蓝色边框的圆角矩形是和Ranger相关的组成模块，主要包括UerSync, RangerAdmin, KMS, 以及12大数据组件对应的插件Plugin。

Ranger支持的大数据组件：

hdfs,hbase,hive,sqoop,storm,solr,kafka,knox,kylin,yarn,atlas,nifi

Ranger支持的元数据库和审计日志数据库，

元数据库支持5种常用的数据库：mysql, oracle, postgres, sqlanywhere, sqlserver

审计日志数据库支持2中常用的大数据组件：solr, hdfs

同时Ranger还支持http和https，kerberos和非kerberos等复杂的安全配置，可见Ranger本身的实现就是有许多部分组成的，而且还需要和各种各样的其他系统组件进行交互，导致Ranger安装的时候非常复杂困难，在更新Ranger的安装包和配置的的时候也比较复杂，在进行功能验证和测试的时候也需要考虑到比较多的东西，如果Ranger所有的功能进行一遍手工验证是非常耗时且不太可靠的，所以急需一个流水线实现自动化的打包安装测试等一系列流程。

4.2.实现方案

使用Docker对Ranger代码编译打包，使用预先制作好的Docker Maven镜像即可。

使用Docker预先安装Ranger需要的5种数据库，分别制作成相应的镜像，设置为在镜像容器启动的时候，会自动把安装好的数据库启动起来，并且把提供服务的端口映射到外部的端口，从而给Docker外部的系统提供服务，在需要的时候，启动该镜像即可提供对应的数据库服务。

使用单独的Docker镜像安装UerSync, RangerAdmin, KMS，每次Ranger编译打包成功后，只要启动一个新的Linux基础镜像容器，即可全新安装RangerAdmin等服务。

使用Docker预先安装12个常用的大数据组件,分别制作成相应的镜像，然后Ranger编译打包成功后，先启动镜像容器，安装对应的Ranger插件，之后再启动组件，把插件加载起来，之后便可以测试Ranger插件的权限控制功能。

5.RobotFramework实现方案

测试框架使用RobotFramework进行自动化测试，考虑到所内的Ranger测试用例是基于DAPManger安装和改造后的Ranger编写的，无法直接使用，需要进行用例迁移，主要是去掉对DAPManger的依赖和Ranger的定制部分，然而大部分用例的测试场景是可以使用的，不需要重新设计，可以很好的覆盖Ranger目前已有的功能，同时针对所内未使用而没有对应测试用例的Ranger功能，需要进行功能分析，测试场景设计和测试用例的编写。

测试完毕之后，这些Docker环境会保留，直到下一次构建的时候，开发和测试都可以登陆环境进行进一步操作，在新的构建开始的时候，脚本会先查看是否已经有Ranger相关的Docker进程，如果有则会先杀掉这些进程，然后再启动这些Docker镜像，这样启动的镜像就是一个干净的环境，不需要进行卸载动作，后续即可以进行全新的安装进行测试。

6.总结

该方案主要工作在于Docker镜像的制作，需要制作接近20个镜像，且每个镜像制作好之后，相关Ranger的安装脚本也需要新增，但是这些工作一旦完成之后，就可以大大减少以后的重复工作，制作好的镜像直接可以拿来使用，非常方便验证Ranger的安装升级等，

只有在少量变化的时候，需要更新对应的镜像，从而大大减少了Ranger安装的复杂度。同时测试用例还需要不断完善，增加测试的覆盖范围，在流水线中执行测试用例，能够保证Ranger的功能可用，减少bug，提升了代码质量，提高了工作效率，从而大大减少了Ranger测试的复杂度。

最后，相信有了这条Ranger开源流水线的帮助，我们一定能够达成开源贡献的目标。