背景

Ambari是一个强大的大数据集群管理平台。在实际使用中，我们使用的大数据组件不会局限于官网提供的那些。如何在Ambari中集成进去其他组件呢？

Stacks & Services

Stack为一系列service的集合。可以在Ambari中定义多个不同版本的stacks。比如HDP3.1为一个stack，可以包含Hadoop, Spark等等多个特定版本的service。

Stack和Service的关系

Ambari中stacks相关的配置信息位于：

源码包：ambari-server/src/main/resources/stacks
安装后：/var/lib/ambari-server/resources/stacks

如果多个stacks需要使用相同的service配置，需要将配置放置于common-services中。common-services目录中存放的内容可供任意版本的stack直接使用或继承。

common-services目录

common-services目录位于源码包的ambari-server/src/main/resources/common-services目录中。如果某个服务需要在多个stacks之中共享，需要将此service定义在common-services中。通常来说common-services中给出了各个service的公用配置。比如下文提到的组件在ambari中的配置项（configuration）部分的配置。

Service目录结构

Service的目录结构如下图所示：

Service目录结构

如图所示，以HDFS为例，每个service的组成部分解释如下：

Service ID：通常为大写，为Service名称。
configuration：存放了service对应的配置文件。该配置文件为XML格式。这些XML文件描述了service的配置项如何Ambari的组件配置页面展示（即service的图形化配置页面的配置文件，配置该页面包含什么配置项）。
package：该目录包含了多个子目录。其中用service控制脚本（启动，停止和自定义操作等）和组件的配置文件模板。
alert.json：service的告警信息定义。
kerberos.json：service和Kerberos结合使用的配置信息。
metainfo.xml：service最为重要的配置文件。其中定义的service的名称，版本号，简介和控制脚本名称等等信息。
metrics.json：service的监控信息配置文件。
widgets.json：service的监控图形界面展示的配置。

metainfo.xml 详解

不仅service具有metainfo.xml配置文件，stack也会有这个配置文件。对于stack来说，metainfo.xml基本用于指定各个stack之间的继承关系。

service metainfo.xml的基础配置项：

<services>
    <service>
        <name>HDFS</name>
        <displayName>HDFS</displayName>
        <comment>Hadoop分布式文件系统。</comment>
        <version>2.1.0.2.0</version>
    </service>
</services>

displayName，comment和version中的内容会展示在安装service的第一步，勾选所需组件的列表中。

component相关配置

component配置组规定了该服务下每个组件的部署方式和控制脚本等内容。举例来说，对于HDFS这个service，它的component包含namenode，datanode，secondary namenode以及HDFS client等。在component配置项中可以对这些组件进行配置。

HDFS的namenode组件配置：

<component>
    <name>NAMENODE</name>
    <displayName>NameNode</displayName>
    <category>MASTER</category>
    <cardinality>1-2</cardinality>
    <versionAdvertised>true</versionAdvertised>
    <reassignAllowed>true</reassignAllowed>
    <commandScript>
        <script>scripts/namenode.py</script>
        <scriptType>PYTHON</scriptType>
        <timeout>1800</timeout>
    </commandScript>
    <logs>
        <log>
            <logId>hdfs_namenode</logId>
            <primary>true</primary>
        </log>
        <log>
            <logId>hdfs_audit</logId>
        </log>
    </logs>
    <customCommands>
        <customCommand>
            <name>DECOMMISSION</name>
            <commandScript>
                <script>scripts/namenode.py</script>
                <scriptType>PYTHON</scriptType>
                <timeout>600</timeout>
            </commandScript>
        </customCommand>
        <customCommand>
            <name>REBALANCEHDFS</name>
            <background>true</background>
            <commandScript>
                <script>scripts/namenode.py</script>
                <scriptType>PYTHON</scriptType>
            </commandScript>
        </customCommand>
    </customCommands>
</component>

其中各个配置项的解释：

name：组件名称。
displayName：组件显示的名称。
category：组件的类型，包含MASTER，SLAVE和CLIENT三种。其中MASTER和SLAVE是有状态的（启动和停止），CLIENT是无状态的。
cardinality：该组件可以安装几个实例。可以支持如下格式。1：一个实例。1-2：1个至2个实例。1+：1个或多个实例。
commandScript：组件的控制脚本配置。
logs：为log search服务提供日志接入。

其中commandScript中的配置项含义如下：

script：该组件的控制脚本相对路径。
scriptType：脚本类型，通常我们使用Python脚本。
timeout：脚本执行的超时时间。

customCommands配置

该配置项为组件的自定义命令，即除了启动，停止等等系统自带命令之外的命令。
下面以HDFS的REBALANCEHDFS命令为例说明下。

<customCommand>
    <name>REBALANCEHDFS</name>
    <background>true</background>
    <commandScript>
        <script>scripts/namenode.py</script>
        <scriptType>PYTHON</scriptType>
    </commandScript>
</customCommand>

该配置项会在service管理页面右上方菜单增加新的菜单项。配置项的含义和CommandScript相同。其中background为true说明此command为后台执行。
接下来大家可能有疑问，当点击这个custom command的菜单项之后，ambari调用了namenode.py这个文件的哪个函数呢？
实际上ambari会调用和customCommand的name相同，名称全为小写的python方法。如下所示。

def rebalancehdfs(self, env):
  ...

osSpecifics配置

同一个service的安装包在不同的平台下，名字通常是不一样的。安装包的名称和系统的对应关系是该配置项所负责的内容。
Zookeeper的osSpecifics配置示例

<osSpecifics>
    <osSpecific>
        <osFamily>amazon2015,redhat6,redhat7,suse11,suse12</osFamily>
        <packages>
            <package>
                <name>zookeeper_${stack_version}</name>
            </package>
            <package>
                <name>zookeeper_${stack_version}-server</name>
            </package>
        </packages>
    </osSpecific>
    <osSpecific>
        <osFamily>debian7,ubuntu12,ubuntu14,ubuntu16</osFamily>
        <packages>
            <package>
                <name>zookeeper-${stack_version}</name>
            </package>
            <package>
                <name>zookeeper-${stack_version}-server</name>
            </package>
        </packages>
    </osSpecific>
</osSpecifics>

注意：该配置中name为组件安装包全名除了版本号以外的部分。需要在系统中使用apt search 或者 yum search能够搜索到。如果包搜索不到，或者说没有当前系统对应的osFamily，service在安装过程不会报错，但是软件包并没有被安装，这点一定要注意。

service的继承关系配置

以HDP这个stack为例，各个版本的HDP存在继承关系，高版本的HDP的各个组件的配置继承自低版本的HDP。这条继承线可以一直追溯至HDP2.0.6。
此时common-services中的配置为何可以共用就得到了解释。common-services中的service配置之所以会生效，是因为在最基础的HDP stack（2.0.6）中，每个service都继承了common-services中的对应配置。
例如AMBARI_INFRA这个service。

<services>
  <service>
    <name>AMBARI_INFRA</name>
    <extends>common-services/AMBARI_INFRA/0.1.0</extends>
  </service>
</services>

HDP中的AMBARI_INFRA这个service的配置继承自common-services中的AMBARI_INFRA/0.1.0的配置。其他组件也是类似的，有兴趣可以查看下相关源代码。

禁用service

加入deleted标签，该service在新增service向导的列表中会被隐藏。

<services>
    <service>
        <name>FALCON</name>
        <version>0.10.0</version>
        <deleted>true</deleted>
    </service>
</services>

configuration-dependencies配置

列出了组件依赖的配置类别。如果依赖的配置类更新了配置信息，该组件会被ambari标记为需要重新启动。

其他配置项

更为详细的介绍请参考官方文档：https://cwiki.apache.org/confluence/display/AMBARI/Writing+metainfo.xml

configuration配置文件

configuration包含了一个或多个xml配置文件。其中每一个xml配置文件都代表了一个配置组。配置组名为xml文件名。
每个xml文件中规定了service配置项的名称，value类型和描述。
下面以HDFS的部分配置项为例说明。

<property>
    <!-- 配置项名称 -->
    <name>dfs.https.port</name>
    <!-- 配置的默认值 -->
    <value>50470</value>
    <!-- 配置的描述，即鼠标移动到文本框弹出的提示 -->
    <description>
        This property is used by HftpFileSystem.
    </description>
    <on-ambari-upgrade add="true"/>
</property>
<property>
    <name>dfs.datanode.max.transfer.threads</name>
    <value>1024</value>
    <description>Specifies the maximum number of threads to use for transferring data in and out of the datanode.
    </description>
    <display-name>DataNode max data transfer threads</display-name>
    <!-- 这里规定了属性值的类型为int，最小值为0，最大值为48000 -->
    <value-attributes>
        <type>int</type>
        <minimum>0</minimum>
        <maximum>48000</maximum>
    </value-attributes>
    <on-ambari-upgrade add="true"/>
</property>

其他更多的配置项，请参考官方文档：https://cwiki.apache.org/confluence/display/AMBARI/Configuration+support+in+Ambari

在Python脚本中读取配置项的值

举例来说，此处我们需要在控制脚本中读取用户在页面填写的instance_name配置项的值。

配置项的配置文件为： configuration/sample.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
    <property>
        <name>instance_name</name>
        <value>instance1</value>
        <description>Instance name for samplesrv</description>
    </property>
</configuration>

在python脚本中的读取方法为：
params.py

from resource_management.libraries.script import Script

config = Script.get_config()

# config被封装为了字典格式，层级为configurations/文件名/属性名
instance_name = config['configurations']['sample']['instance_name']

组件控制脚本的编写

组件的控制脚本位于package/scripts中。脚本必须继承resource_management.Script类。

package/scripts: 控制脚本
package/files: 控制脚本使用的文件
package/templates: 生成配置文件的模板文件，比如core-site.xml, hdfs-site.xml的样板配置文件等。

一个最简单的控制脚本文件：

import sys
from resource_management import Script
class Master(Script):
  def install(self, env):
    # 安装组件时执行的方法
    print 'Install the Sample Srv Master';
  def stop(self, env):
    # 停止组件时执行的方法
    print 'Stop the Sample Srv Master';
  def start(self, env):
    # 启动组件时执行的方法
    print 'Start the Sample Srv Master';
  def status(self, env):
    # 组件运行状态检测方法
    print 'Status of the Sample Srv Master';
  def configure(self, env):
    # 组件配置更新时执行的方法
    print 'Configure the Sample Srv Master';
if __name__ == "__main__":
  Master().execute()

ambari为编写控制脚本提供了如下库：

resource_management
ambari_commons
ambari_simplejson

这些库提供了常用的操作命令，无需再引入额外的Python包。

如果需要针对不同的操作系统编写不同的script，需要在继承resource_management.Script之时添加不同的@OsFamilyImpl()注解。

下面给出常用的部分控制脚本片段的写法。

检查PID文件是否存在（进程是否运行）

from resource_management import *

# 如果pid文件不存在，会抛出ComponentIsNotRunning异常
check_process_status(pid_file_full_path)

Template 填充配置文件模板

使用用户在service页面配置中填写的值，来填充组件的配置模板，生成最终的配置文件。

# params文件提前将用户在配置页填写的配置项的值读取进来
# 对于config-template.xml.j2所有的模板变量，必须在params文件中定义，否则模板填充会报错，也就是说所有模板内容必须能够正确填充。
import params
env.set_params(params)
# config-template为configuration文件夹中的j2文件名
file_content = Template('config-template.xml.j2')

Python替换配置文件模板使用的是Jinja2模板

InlineTemplate

和Template相同，只不过配置文件的模板来自于变量值，而不是Template中的xml模板

file_content = InlineTemplate(self.getConfig()['configurations']['gateway-log4j']['content'])

File

把内容写入文件

 File(path,
        content=file_content,
        owner=owner_user,
        group=sample_group)

User

用户操作

# 创建用户
User(user_name, action = "create", groups = group_name)

Execute

执行特定的脚本

Execute('ls -al', user = 'user1')

Package 安装指定的软件包

Package(params.all_lzo_packages,
            retry_on_repo_unavailability=params.agent_stack_retry_on_unavailability,
            retry_count=params.agent_stack_retry_count)

后记

本博客为大家指明了Ambari集成大数据组件的基本配置。本人会在后续博客中为大家介绍如何为Ambari集成Elasticsearch服务。

Ambari官网参考资料

https://cwiki.apache.org/confluence/display/AMBARI/Defining+a+Custom+Stack+and+Services

https://cwiki.apache.org/confluence/display/AMBARI/How-To+Define+Stacks+and+Services#How-ToDefineStacksandServices-metainfo.xml

Ambari集成组件的方法

Ambari集成组件的方法

背景

Stacks & Services

common-services目录

Service目录结构

metainfo.xml 详解

component相关配置

customCommands配置

osSpecifics配置

service的继承关系配置

禁用service

configuration-dependencies配置

其他配置项

configuration配置文件

在Python脚本中读取配置项的值

组件控制脚本的编写

检查PID文件是否存在（进程是否运行）

Template 填充配置文件模板

InlineTemplate

File

Directory

User

Execute

Package 安装指定的软件包

后记

Ambari官网参考资料

推荐阅读更多精彩内容