本文主要通过ranger在hdfs acl中的应用以及原理介绍一下ranger的使用，另外介绍一下实际使用过程中碰到的问题。
上篇文章回顾：时间服务器—NTP
目前公司内部大多通过数据工场来管理hdfs上的数据，工场开发团队和hdfs、yarn的SRE同学也配合紧密。由于涉及到管理数据，那么不得不说到权限控制的问题。
接触过hadoop的同学都应该了解hdfs上数据的权限类似linux中的权限，分为r、w、x三种权限。数据工场中也提供了各个表的数据权限的访问申请，底层通过java api去设置hdfs的acl，具体的每张表有访问权限的详情，但是缺少整体的供管理者预览的权限展示。
另外有一些没有在数据工场管理的目录，需要配置acl的话就需要通知SRE去手动添加或者删除。ranger一方面整体可以控制集群的acl，管理者在页面中就可以配置相关的权限，同时也提供了直观的权限展示。当然，不仅仅是hdfs目录的acl，包括hive、hbase、yarn、storm这些大数据生态的服务，都可以通过ranger来控制权限。
1、ranger功能展示
首先看一下ranger登录后的整体页面：
这里就是当前ranger可以进行权限控制的各个组件，每点开一个组件都可以编辑，比如hdfs，点开后就是如下配置界面：
上图主要配置的是namenode的地址，可以把这步骤配置叫做service配置，service配置完毕后，可以配置policy，也就是具体的针对某个集群的目录权限控制策略，如下图所示：
定义policy的名字（Policy Name）、定义需要控制权限的路径（Resource Path）、定义user或者group的访问权限（这里的uesr和group是hdfs上的user和group）。add之后就生成了一条完整的访问策略。在hdfs层面就完成了权限控制。
总结来看在ranger控制台，可以完成如下操作：
（1）service manager：目前支持hdfs、yarn、hbase、hive、storm等服务的管理
（2）service：通过某个service manager可以创建一个service，如hdfs服务，可以根据不同集群创建不同的service从而管理不同的集群
（3）policy：具体的权限控制策略，在service的基础上建立策略来控制权限
（4）audit：审计。包括用户登录情况和触发policy记录
（5）settings：可以手动增加和删除用户（安装了usersync插件后，这里的用户会自动更新同步namenode上的用户）
2、ranger plugin配置
ranger的权限控制离不开各项plugin的使用。在安装初始，编译完代码之后会生成很多plugin，如admin、usersync、hdfs、yarn等。
（1）admin插件是用作web页面的生成，需要注意的是admin配置文件中的mysql配置需要能够创建用户的权限，或者填写的mysql的用户名密码已经地址在mysql的user表中存在
（2）usersync插件用于同步namenode上的用户至ranger中，需要启动在namenode节点上（访问集群的用户必须在namenode本地机器上存在这个用户）
（3）剩下插件就是上面提到的各个组件的控制访问需要用到的插件。文件格式类似ranger-{$version}-{$pluginName}.tar.gz。解压这些文件到各个服务对应的master节点进行安装（解压后会有setup.sh文件，运行文件进行安装），同时重新启动master服务即可完成
3、权限控制原理
hdfs本身自带了权限控制，在配置文件中dfs.namenode.inode.attributes.provider.class默认值是空，在使用ranger进行权限控制的时候，需要将此项设置成org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer。
ranger控制权限主要是通过启动插件时候生成的配置文件以及插件自带的jar包来进行（plugin配置中有说明plugin的安装），会将jar包放到hadoop安装目录的lib目录下，将xml配置文件放到hadoop安装目录的etc/hadoop目录下9与hdfs-site.xml这些文件在同一路径下)。
且ranger控制的权限在hdfs自带的权限控制之上，也就是启动了ranger控制权限之后，用户访问hdfs的时候会先通过ranger的认证，如果发现没有权限，直接拒绝访问；如果有权限，之后仍然会去通过hdfs自带的权限控制去判断是否有访问权限，所以不用担心ranger的权限控制会覆盖原有的已经设置的权限。
4、元数据的存储
在低版本的ranger中，元数据可以通过配置到mysql中存储，较新版本（0.5）以后取消了mysql的配置，统一将元数据存储到了solr中。solr是一个高性能的、基于Lucene的全文搜索服务器，它也经常被拿来和现今流行的elasticsearch做比较。一般来说，solr在实时搜索逊于es，且在数据量增大的时候，solr的查询效率降低，但是在对单纯的已有的数据进行搜索时候，solar表现得更为突出，且solr支持多种数据格式，而es只支持json。
solr的安装很简单，直接下载solr-6.6.0.tar.gz解压即可。解压之后，cd到solr的bin目录下启动即可。
solr start -c -s '/usr/local/solr/server/solr '-z zkaddress:port/solr要提前在zookeeper上建立 'solr' 这个znode才行，而后使用solr create -c {$collection}-rf 2（2个副本）创建collection。访问http://ip:8983/solr即可打开页面，可以在页面中执行查询操作。集群搭建的话，就是所有机器重复以上步骤。使用bin/post -c {$collection} path/，其中collection是索引的名称；path/表示path路径下的文件，该命令表示将path下的所有文件标记为索引{$collection} 放到solr中去。
5、碰到的问题
在使用的过程中也碰到过问题，在使用ranger来进行yarn权限控制，控制用户提交任务权限的时候，ranger做得不够完善。在建立新的service的时候，填写入'YARN REST URL' 后，点击test connection，出现了问题，页面弹出框提示无法通过该url获得队列，查看ranger-admin运行日志也没有报错。翻看底层代码后发现，ranger在对yarn的支持上只支持了capacity调度，对fair调度没有支持。当将运行中的集群的调度改为capacity调度后，test connection成功。根本原因就是，resourcemanager的rest api（http://rm:port/ws/v1/cluster/scheduler）在不同的调度器下，得到的json文件不同，由于ranger底层单纯地只解析了capacity调度的json文件，没有解析fair调度的，所以出现了上述问题。需要针对fair调度下的rest api返回的json重新做解析。
本文首发于公众号“小米运维”，点击查看原文。
