Ambari熟练应用篇

利用Ambari管理Hadoop集群

Service Level Action（服务级别的操作）

首先我们进到Ambari的GUI页面，并查看Dashboard。在左侧的Service列表中，我们可以点击任何一个您想要操作的Service。以MapReduce2为例（Hadoop这里的版本为 2.7.x，也就是YARN+HDFS+MapReduce2），当点击MapReduce2后，就会看到该Service的相关信息，如下图MapRduce2的Service 页面。

中间部分是Service的模块（Component）信息，也就是该Service有哪些模块及其数目。右上角有个Service Action的按钮，当点击该按钮后就可以看到很多Service的控制命令。也就是通过这些Service Action命令，对Service进行管理的。

可能有的人会说，装完Hadoop的集群后，并不知道这个集群是不是可用。这时候我们就可以运行一个“Run Service Check”。点击这个命令后，就会出现下图的进度显示。

其实这里就是通过运行一个经典的MapReduce Wordcount实例，来检查MapReduce是不是正常。结果运行失败了，报错：Python script has been killed due to timeout after waiting 300 secs

解决：vi /etc/yum.conf把installonly_limit的值设成600
注意：是在主节点的/etc/yum.conf文件下而不是从节点
对于Service Action里面的Start、Stop的含义就是，启停整个集群所有该Service的模块（也就是 Service level）。当执行进度页面弹出来的时候，我们可以点击Operations的名字，进而查看每个机器的进度和运行log。

Host Level Action（机器级别的操作）

首先，我们回到Ambari的Dashboard页面。页面最上面中间的地方有个Hosts，点击这个标签，我们就可以看到Ambari所管理的机器列表。如下图。

图片中红色的数字是警告信息（Ambari Alert），这里我们先略过它。先看左上角的Actions，点击这个按钮，就可以看到Host level Action的选项了，其实和Service Level是类似的，只是执行的范围不一样。如下图。当用户选择All Hosts -> Hosts -> Start All Components，Ambari就会将所有Service的所有模块启动。

如果用户选择 All Hosts-> DataNodes -> Stop，Ambari 就会把所有机器的 DataNode 这个模块关闭。如下图。

Component Level Action（模块级别的操作）

上面的图中，我们可以看到Decommisson、Recommission。这些命令其实是自定义的模块级别的操作（Component Level Action）。不过上图中命令一旦执行，就是对多个机器的同个模块执行。
我们现在尝试只对单个机器的一个模块（Component）执行。首先我们回到Hosts的页面。这时候点击机器名，我们就会进入到该机器的Component页面。如下图。

这时候只要点击每个Component（模块）后面的按钮，就可以看到该模块的操作命令了。例如，我们可以停掉这台机器的DataNode模块。

在Ambari中已经加入了很多自定义的Action去做一些特殊的操作。如果对Hadoop生态圈的软件足够熟悉，就可以尝试更多的Action。可能有的人会问，Ambari可不可以扩容集群。答案当然是可以的。Ambari可以给自身的集群添加机器（也就是添加 Ambari Agent），然后将Service的模块安装在新的机器，也可以把某些模块安装到已有的其他的机器。

Ambari Server会读取Stack和Service的配置文件。当用Ambari创建集群的时候，Ambari Server传送Stack和Service的配置文件以及Service生命周期的控制脚本到Ambari Agent。Agent拿到配置文件后，会下载安装公共源里软件包（Redhat，就是使用yum服务）。安装完成后，Ambari Server会通知Agent去启动Service。之后Ambari Server会定期发送命令到Agent检查Service的状态，Agent上报给Server，并呈现在Ambari的GUI上。
Ambari Server支持Rest API，这样可以很容易的扩展和定制化Ambari。甚至于不用登陆Ambari的GUI，只需要在命令行通过curl就可以控制Ambari，以及控制Hadoop的cluster。具体的API可以参见Apache Ambari的官方网页API reference。
对于安全方面要求比较苛刻的环境来说，Ambari可以支持Kerberos认证的Hadoop集群。

扩展Ambari管理一个自定义的Service

首先，我们需要规划自定义的Service属于哪个Stack（当然Stack也是可以自定义的）。这里为了快速创建一个新的Service，而且我们已经安装了HDP 2.4的Stack，所以就将自定义的Service放在HDP 2.4之下。

第一步，首先在Ambari Service机器上找到HDP 2.4 Stack的目录。

[root@SY-001 services]# pwd
/var/lib/ambari-server/resources/stacks/HDP/2.4/services

第二步，需要创建一个Service目录，我们这里用“SAMPLE”作为目录名。并在SAMPLE底下创建metainfo.xml。示例代码如下。主要解释下xml代码中的两个字段category和cardinality。category指定了该模块（Component）的类别，可以是MASTER、SLAVE、CLIENT。Cardinality指的是所要安装的机器数，可以是固定数字1，可以是一个范围比如1-2，也可以是1+，或者ALL。如果是一个范围的时候，安装的时候会让用户选择机器。另外这里有关Service和Component的name配置要用大写，小写有时候会有问题。Displayname可以随意设置。

[root@SY-001 services]# mkdir SAMPLE[root@SY-001 services]# cd SAMPLE/[root@SY-001 SAMPLE]# vi metainfo.xml<?xml version="1.0"?><metainfo> <schemaVersion>2.0</schemaVersion> <services> <service> <name>SAMPLE</name> <displayName>My Sample</displayName> <comment>My v1 Sample</comment> <version>1.0</version> <components> <component> <name>MYMASTER</name> <displayName>My Master</displayName> <category>MASTER</category> <cardinality>1</cardinality> <commandScript> <script>scripts/master.py</script> <scriptType>PYTHON</scriptType> <timeout>5000</timeout> </commandScript> </component> <component> <name>MYSALVE</name> <displayName>My Slave</displayName> <category>SLAVE</category> <cardinality>1+</cardinality> <commandScript> <script>scripts/slave.py</script> <scriptType>PYTHON</scriptType> <timeout>5000</timeout> </commandScript> </component> </components> <osSpecifics> <osSpecific> <osFamily>any</osFamily> </osSpecific> </osSpecifics> </service> </services></metainfo>

第三步，需要创建Service的控制脚本。这里我们需要在SAMPLE底下创建一个package目录，然后在package底下创建目录scripts，进而创建master.py和slave.py。这里需要保证脚本路径和上一步中metainfo.xml中的配置路径是一致的。这两个Python脚本是用来控制Master和Slave模块的生命周期。脚本中函数的含义也如其名字一样：install就是安装调用的接口；start、stop分别就是启停的调用；Status是定期检查component状态的调用；Configure是安装完成配置该模块的调用。示例目录结构如下图。

Python 脚本的示例代码：

master.py：import sysfrom resource_management import *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()slave.py:import sysfrom resource_management import *class Slave(Script):  def install(self, env):    print 'Install the Sample Srv Slave';  def stop(self, env):    print 'Stop the Sample Srv Slave';  def start(self, env):    print 'Start the Sample Srv Slave';  def status(self, env):    print 'Status of the Sample Srv Slave';  def configure(self, env):    print 'Configure the Sample Srv Slave';if __name__ == "__main__":  Slave().execute()

第四步，需要重启Ambari Server。因为Ambari Server只有在重启的时候才会读取Service和Stack的配置。命令行执行：
ambari-server restart

第五步，登录Ambari的GUI，点击左下角的Action，选择Add Service。如下图：

这时候就可以看到我们自定义的 Service：SAMPLE。如下图：

选择My Sample后，就可以一路Next了，这个过程其实和我们在搭建Hadoop2.x集群的时候是类似的。由于这个Service没有真的安装包，所以安装过程会非常的快，启动命令也没有真正的逻辑，所以启动过程也是很快的。等最后点击完Complete，整个安装过程也就结束了。再回到Ambari的Dashboard的时候，我们就可以看到这个My Sample了，如下图：

删除自定义服务SAMPLE（发现web页面中没有删除的方法，这时可用CURL来删除）：

(1)停止服务

[root@SY-001 scripts]# curl -u admin:admin -H "X-Requested-By: ambari" -X PUT -d '{"RequestInfo": {"context":"Stop Service"},"Body":{"ServiceInfo":{"state":"INSTALLED"}}}' http://192.168.205.153:8080/api/v1/clusters/bigdata/services/SAMPLE
{
  "href" : "http://192.168.205.153:8080/api/v1/clusters/bigdata/requests/49",
  "Requests" : {
    "id" : 49,
    "status" : "Accepted"
  }
}

SAMPLE服务因为实际上没干任何事，短暂时间后可能会自己又启动，所以手速要快

(2)删除服务（快速执行）

curl -u admin:admin -H "X-Requested-By: ambari" -X DELETE http://192.168.205.153:8080/api/v1/clusters/bigdata/services/SAMPLE
如果没有停止的话会出现
{
  "status" : 500,
  "message" : "org.apache.ambari.server.controller.spi.SystemException: An internal system exception occurred: Cannot remove bigdata/SAMPLE. MYSALVE is in a non-removable state."
}

(3)验证
重新访问页面，你会发现SAMPLE service已经消失了

Ambari的自定义命令（Custom Command）

在Ambari的Stack中，每个Service都会有start、stop、status、configure这样的命令，我们称之为生命周期的控制命令（lifecycle command）。Service的每个模块（Component）都必须实现这几个命令的逻辑。为了让用户可以更好地控制每个Service以及每个模块，Ambari支持了自定义命令（Custom Command）。不过目前只能支持到模块级别（Component Level），Service Level的还不支持。
具体的自定义命令配置在每个Service的metainfo.xml中。不过不同的模块类型，呈现在GUI的方式是有差异的。当给一个Service的Master模块增加一个自定义命令时，该命令会显示在该Service的Service Action List。如果点击这个命令，Ambari Server就会通知Master所在机器的Agent，Agent就会执行该自定义命令的逻辑。当增加一个自定义命令给Slave或Client类型的Component（模块），该命令则会呈现在机器的Component页面。在哪个机器的Component页面点击该命令，Ambari Server就会通知该机器Agent调用这个自定义的命令接口。

Master Component的自定义命令
这里我以YARN为例，给Resource Manger模块（Master）增加一个自定义命令。首先假设一个需求，例如，要在YARN的Service Action里面加一个命令来检查Resource Manger所在机器的内存空间还有多大。

第一步，需要找到Yarn的metainfo.xml，并在Resource Manager的Component配置中增加一个自定义命令。Component段的示例代码如下（metainfo.xml），其中GetMem这个命令就是我们新增的自定义命令。

[root@SY-001 2.1.0.2.0]# pwd
/var/lib/ambari-server/resources/common-services/YARN/2.1.0.2.0

[root@SY-001 2.1.0.2.0]# vi metainfo.xml        <component>          <name>RESOURCEMANAGER</name>          <displayName>ResourceManager</displayName>          <category>MASTER</category>          <cardinality>1</cardinality>          <versionAdvertised>true</versionAdvertised>          <commandScript>            <script>scripts/resourcemanager.py</script>            <scriptType>PYTHON</scriptType>            <timeout>1200</timeout>          </commandScript>          <customCommands>            <customCommand>              <name>DECOMMISSION</name>              <commandScript>                <script>scripts/resourcemanager.py</script>                <scriptType>PYTHON</scriptType>                <timeout>600</timeout>              </commandScript>            </customCommand>            <customCommand>              <name>REFRESHQUEUES</name>              <commandScript>                <script>scripts/resourcemanager.py</script>                <scriptType>PYTHON</scriptType>                <timeout>600</timeout>              </commandScript>            </customCommand>            <!--新增部分开始-->            <customCommand>              <name>GetMem</name>              <commandScript>                <script>scripts/resourcemanager.py</script>                <scriptType>PYTHON</scriptType>                <timeout>600</timeout>              </commandScript>            </customCommand>            <!--新增部分结束-->          </customCommands>          <configuration-dependencies>            <config-type>capacity-scheduler</config-type>            <config-type>hdfs-site</config-type>          </configuration-dependencies>        </component>

第二步，实现自定义命令的逻辑。这里CustomComand的xml段已经指定了具体的脚本（resourcemanager.py），所以需要在这个脚本中增加该命令的接口，而且函数名必须是小写且与配置的中的name保持一致。接下来，我们需要先找到Ambari Server上的resourcemanager.py文件。找到之后，在resourcemanager.py增加如下的示例代码（python脚本中注意代码的对齐方式，否则会出现语法错误。可以参考resourcemanager.py中的decommission函数）：

[root@SY-001 scripts]# pwd
/var/lib/ambari-server/resources/common-services/YARN/2.1.0.2.0/package/scripts

[root@SY-001 scripts]# vi resourcemanager.pyclass Resourcemanager(Script):  def install(self, env):    self.install_packages(env)#新增部分开始  def getmem(self, env):    import os    print 'Execute this coustom command to get mem info on this host'    os.system("free")#新增部分结束  def stop(self, env, upgrade_type=None):    import params    env.set_params(params)    service('resourcemanager', action='stop')

第三步，重启Ambari Server以及Resource Manger所在机器的Ambari Agent。这一步为了加载新的配置，并且同步我们修改的脚本到Agent机器。因为在每个Agent的机器上，都有一个cache目录，用来存放从Server端下载的配置及脚本。当重启Agent时候，Agent便会尝试从Server端下载最新的配置和脚本。重启命令如下：
ambari-server restart
ambari-agent restart

第四步，重新登录Ambari的WEB GUI，并检查Yarn的Service Actions。这时候我们已经可以看到这个GetMem的命令了。由于CustomComand的xml段不支持DisplayName标签，所以我们没法通过配置更改这个名字。如果需求要更改这个名字，则不得不更改GUI的JS代码。
重新登录的时候可能会出现这种情况，请不要惊慌，只需要你多刷新登录几次就行了。。。

第五步，如果GetMem可以显示，就可以点击并执行该命令了。执行结果如下图显示。
自定义命令GetMem执行进度页面

Slave/Client Component的自定义命令
本质上讲，为Slave、Client类型的Component增加自定义命令，与Master类型是没有什么区别的。唯一的区别就是在GUI上呈现的位置不一样。因此这里给一个简单的示例，不再赘述具体的步骤。
这里我为Yarn的NodeManager增加了一个自定义命令“iostat”，用来查看NodeManager所在机器的IO状况。在Yarn的metainfo.xml中，为NodeManager新增如下的配置。
[root@SY-001 2.1.0.2.0]# pwd
/var/lib/ambari-server/resources/common-services/YARN/2.1.0.2.0

[root@SY-001 2.1.0.2.0]# vi metainfo.xml        <component>          <name>NODEMANAGER</name>          <displayName>NodeManager</displayName>          <category>SLAVE</category>          <cardinality>1+</cardinality>          <versionAdvertised>true</versionAdvertised>          <commandScript>            <script>scripts/nodemanager.py</script>            <scriptType>PYTHON</scriptType>            <timeout>1200</timeout>          </commandScript>          <!--新增部分开始-->          <customCommands>            <customCommand>              <name>iostat</name>              <commandScript>                <script>scripts/nodemanager.py</script>                <scriptType>PYTHON</scriptType>                <timeout>600</timeout>              </commandScript>            </customCommand>          </customCommands>          <!--新增部分结束-->        </component>

在nodemanager.py中增加如下的示例代码
[root@SY-001 scripts]# pwd
/var/lib/ambari-server/resources/common-services/YARN/2.1.0.2.0/package/scripts

[root@SY-001 scripts]# vi nodemanager.pyclass Nodemanager(Script):  def install(self, env):    self.install_packages(env)#新增部分开始  def iostat(self, env):    import os    os.system("iostat")#新增部分结束  def stop(self, env, upgrade_type=None):    import params    env.set_params(params)    service('nodemanager',action='stop')

配置完成后，重启Ambari Server以及NodeManager所在的Agent的机器。当重新登录Ambari GUI的时候，就可以在NodeManger所在机器的Component页面看到这个命令。如下图：

到这里，我们就成功的为YARN的Master和Slave模块分别增加了一个自定义命令。现实的生产环境中，可以通过自定义命令扩展Ambari现在的控制功能，可以让Ambari更好的与Hadoop等软件切合。如果需要更深入应用自定义命令，以及增强GUI上面的显示功能，则可能需要向社区贡献patch。这样可以更好的提升用户体验等。

Ambari中Service之间的依赖关系
在Hadoop的生态圈中，一个完整的解决方案往往是需要几个framework共同的协作才能完成的。所以Ambari必须支持定义Service之间、Component之间的依赖关系，以及Component状态和Action之间的依赖关系。
对于Service和Component之间的依赖关系，可以在metainfo.xml中定义。例如打开YARN的metainfo.xml，就可以看到在YARN的Service段，有一个requiredService的字段。每个Service段底下，可以用这个字段来定义一个Service依赖哪些其他的Service。YARN所示配置如下，代表YARN需要HDFS和MAPREDUCE2。

      <requiredServices>        <service>HDFS</service>        <service>MAPREDUCE2</service>      </requiredServices>

对于Component来说，也有一个字段dependencies。在这个字段定义了Component的依赖关系。我以HBASE的HBASE_MASTER配置为例。可以从示例代码中看到，HBASE_MASTER需要HDFS的HDFS_CLIENT，以及ZOOKEEPER的ZOOKEEPER_SERVER。
[root@SY-001 0.96.0.2.0]# pwd
/var/lib/ambari-server/resources/common-services/HBASE/0.96.0.2.0

[root@SY-001 0.96.0.2.0]# vi metainfo.xml         <component>          <name>HBASE_MASTER</name>          <displayName>HBase Master</displayName>          <category>MASTER</category>          <cardinality>1+</cardinality>          <versionAdvertised>true</versionAdvertised>          <timelineAppid>HBASE</timelineAppid>          <dependencies>            <dependency>              <name>HDFS/HDFS_CLIENT</name>              <scope>host</scope>              <auto-deploy>                <enabled>true</enabled>              </auto-deploy>            </dependency>            <dependency>              <name>ZOOKEEPER/ZOOKEEPER_SERVER</name>              <scope>cluster</scope>              <auto-deploy>                <enabled>true</enabled>                <co-locate>HBASE/HBASE_MASTER</co-locate>              </auto-deploy>            </dependency>          </dependencies>          <commandScript>            <script>scripts/hbase_master.py</script>            <scriptType>PYTHON</scriptType>            <timeout>1200</timeout>          </commandScript>          <customCommands>            <customCommand>              <name>DECOMMISSION</name>              <commandScript>                <script>scripts/hbase_master.py</script>                <scriptType>PYTHON</scriptType>                <timeout>600</timeout>              </commandScript>            </customCommand>          </customCommands>        </component>

Ambari的维护模式（Maintenance Mode）介绍
Ambari提供的Maintenance Mode，是为了让用户在调试或者维护Service的时候，抑制不必要的告警（Alert）信息，以及避免批量操作的影响。对Maintenance Mode来说，有几个不同级别的设置，分别是Service Level，Host Level，以及Component Level。三种级别之间存在着覆盖关系。下面我会举几个例子来详细说明Maintenance Mode的应用场景。另外注意，在Ambari的WEB GUI上面会用一个照相机的图标，标记打开Maintenance Mode的模块、机器或者Service。

Component Level（模块级别）
在Component页面里，如果用户对某一个Component（模块）打开了维护模式，对该模块会有两种影响。其一，对于该机器的该模块不再受批量操作的控制；其二，抑制该机器该模块告警信息的产生。

例如，对机器SY-002.hadoop的ZooKeeper Server模块打开维护模式，那么当用户从Host Action中关闭所有ZooKeeper Server的时候，该机器的ZooKeeper Server就不会被关闭。这是因为关闭ZooKeeper Server的批量操作会直接越过SY-002.hadoop。图10中可以看到SY-002.hadoop不在执行的序列。并且SY-002.hadoop的ZooKeeper Server不会产生任何新的告警。

过一会儿出现这个图标

关闭ZooKeeper Server的批量操作

操作完成后的结果

Host Level（机器级别）
对Host级别的维护模式来说，就是打开了该机器所有模块的维护模式。操作起来也很简单，在Hosts页面中勾选完机器，然后在Host Actions里面选择“Turn On Maintenance Mode”即可。如果该机器已经有告警信息，当Maintenance Mode打开后，告警信息会被屏蔽，并且抑制新告警信息的产生。所有的批量操作都会越过该机器。
Host打开Maintenance Mode之前

Host打开Maintenance Mode之后

Service Level（服务级别）

对Service级别的维护模式来说，就是打开一个Service所有Component的维护模式。由于Service可能部署在多台机器，也就相当于用户在多个机器打开Service Component的维护模式。这样一来，这个Service就不会产生任何新的告警。当用户重启集群所有Service的时候，该Service会越过这个批量操作。当用户重启一个机器的所有Component的时候，该Service的Component也会被越过。下图是对HDFS打开维护模式的示例。

Service 打开 Maintenance Mode 之前

Service 打开 Maintenance Mode 之后

利用Ambari扩展集群

（我的三台虚拟机机器装完HDFS、MapReduce2、YARN、ZooKeeper、Ambari Metrics后就卡的要死，要是再增加一台虚拟机的话我怕卡爆了！于是我为了做这个实验就又重装了一遍，再安装的时候我就选择两台机器安装服务，安装成功之后我再扩展一台）
利用Ambari搭建好的集群，可以通过Ambari来扩展。这里的步骤其实类似于Add Service，只是少了选择Master的页面。下面是详细的描述。

第一步，需要打开Hosts页面，然后点击左上角的Actions，在下拉列表中选择“Add New Hosts”。

第二步，在Add Host Wizard需要输入新增的机器名（包含完整域名）以及Ambari Service机器上生成的私钥。选择Agent机器页面

第三步，选择对应的Service的配置。这里Ambari为用户已经选择了默认的配置。选择完后，便会开始安装Ambari Agent到新的机器，并且安装选择的模块。
当Add Host Wizard完成时，我们就可以从Hosts的页面中看到新的机器，以及安装的模块（Component）。

Ambari应用举例（快速搭建 Spark on YARN 的集群）
[root@SY-001 0.96.0.2.0]# yum list | grep spark
Repository HDP-UTILS-1.1.0.20 is listed more than once in the configuration
spark_2_4_0_0_169-yarn-shuffle.noarch   1.6.0.2.4.0.0-169.el6          @HDP-2.4 
spark.noarch                            1.6.0.2.4.0.0-169.el6          HDP-2.4  
spark-master.noarch                     1.6.0.2.4.0.0-169.el6          HDP-2.4  
spark-python.noarch                     1.6.0.2.4.0.0-169.el6          HDP-2.4  
spark-worker.noarch                     1.6.0.2.4.0.0-169.el6          HDP-2.4  
spark-yarn-shuffle.noarch               1.6.0.2.4.0.0-169.el6          HDP-2.4  
spark_2_4_0_0_169.noarch                1.6.0.2.4.0.0-169.el6          HDP-2.4  
spark_2_4_0_0_169-master.noarch         1.6.0.2.4.0.0-169.el6          HDP-2.4  
spark_2_4_0_0_169-python.noarch         1.6.0.2.4.0.0-169.el6          HDP-2.4  
spark_2_4_0_0_169-worker.noarch         1.6.0.2.4.0.0-169.el6          HDP-2.4  
在Ambari的Add Service上增加Spark这个Service就可以了。如果之前了解过Spark，就会发现Ambari部署的Spark集群的模式是Spark on YARN。这也是为什么在Add Spark的时候，Ambari会提示要选择依赖的YARN。

Ambari常用的REST API介绍
Ambari借鉴了很多成熟分布式软件的API设计。Rest API就是一个很好地体现。通过Ambari的Rest API，可以在脚本中通过curl维护整个集群。并且，我们可以用Rest API实现一些无法在Ambari GUI上面做的操作。下面是一些实例。

实例 1，通过API卸载已安装的Service
目前Ambari不支持在GUI上面卸载已安装的Service。所以当一个Service不再需要的时候，用户没法删除掉该Service。幸运的是Ambari提供了DELETE的Rest API，我们可以通过该API来删除Ambari中Service。不过这里需要注意，这个方法只是从Ambari Service中删除了Service。这样一来，Ambari的GUI界面中不再显示这个Service。但是Service本身还安装在Agent 所在的机器。如果用户需要彻底的清除掉这个Service，仍需要手工的到每个机器卸载（例如，在每个机器执行yum erase）。
这里我以删除Storm为例。卸载之前，需要确认是否停掉了该Service。我们通过GET方法来得到这个结果（这里当然也可以直接从GUI上面看到Service状态）。具体的命令如下：
因为机器实在是卡爆了所以我并没有安装STORM，这里以https://www.ibm.com/developerworks/cn/opensource/os-cn-bigdata-ambari2/index.html为例
curl -u admin:admin -H "X-Requested-By: ambari" -X GET http://zwshen86:8080/api/v1/clusters/bigdata/services/STORM
Get返回的结果

用Rest API停掉Service的命令格式如下，有兴趣的朋友可以尝试一下。
curl -u admin:admin -H "X-Requested-By: ambari" -X PUT -d '{"RequestInfo": {"context":"Stop Service"},"Body":{"ServiceInfo":{"state":"INSTALLED"}}}' http://AMBARI_SERVER_HOST:8080/api/v1/clusters/c1/services/SERVICE_NAME
执行如下命令删除 STORM：
curl -u admin:admin -H "X-Requested-By: ambari" -X DELETE  http://zwshen86:8080/api/v1/clusters/bigdata/services/STORM
执行完成后，Storm就从Ambari的Service里面删掉了，但是Storm的package还存在于机器。
Storm的RPM包

如果需要彻底清除掉 Storm 的 package，则需要到各个 Agent 机器执行如下命令。
yum erase“storm_2_2*”
执行完后，这个Service就被彻底的清除掉了。

实例2，获取Service的Component和Host列表
上个实例中，让用户登录到每个机器去执行yum卸载安装包，其实是不太现实的。一般我们会写一个脚本先通过curl调用GET方法，先获取到Service的Component列表，然后再调用GET方法，获取Component的机器列表，接着调用DELETE从Ambari中删除Service。最后脚本通过SSH登录到各个Agent机器上执行yum卸载安装包。脚本示例代码如下（该脚本只能在Ambari Server上执行，因为Ambari Server有无密码登录所有Agent机器的权限）。

#!/bin/shGetHostList(){ curl -u admin:admin -H "X-Requested-By: ambari" -X GET http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE/components/$1 2>/dev/null |grep host_name|awk -F: '{print $2}'|sed 's/"//g' >> temp_host_list} GetServiceComponent(){ curl -u admin:admin -H "X-Requested-By: ambari" -X GET http://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE 2>/dev/null | grep "component_name" > ./temp_component_list sed -i 's/"//g' ./temp_component_list sed -i 's/,//g' ./temp_component_list} if [ $# != 4 ]; then echo "Usage: $0 Ambari_Server Cluster_Name Service_Name Package_Name" exit 1fi AMBARI_HOST=$1CLUSTER=$2SERVICE=$3PACKAGE=$4 GetServiceComponent cat ./temp_component_list|while read linedo COMPONENT=`echo $line|awk -F: '{print $2}'` GetHostList $COMPONENTdone curl -u admin:admin -H "X-Requested-By: ambari" -X DELETEhttp://$AMBARI_HOST:8080/api/v1/clusters/$CLUSTER/services/$SERVICE rm -f ./temp_component_list >/dev/null 2>&1#delete duplicated lines (duplicated host name) hosts=`cat temp_host_list|sort |uniq`for host in $hostsdo ssh $host "yum erase $PACKAGE"done rm -f temp_host_list >/dev/null 2>&1

实例3，通过API执行Service的命令
这里，我们以调用API执行Service Check为例。首先需要知道命令的名字，这里每个Service的Check命令也是不同的。不过Service Check是build-in的命令，所以有一定的格式可循。
格式大致如下：NAME_SERVICE_CHCECK
只要将NAME替换成对应的Service，就是该Service的Check命令。以YARN为例，执行如下的命令。
curl -u admin:admin -H "X-Requested-By: ambari" -X POST -d '
   {"RequestInfo":{"context":"My YARN Service Check", "command":
   "YARN_SERVICE_CHECK"},"Requests/resource_filters":[{"service_name":"YARN"}]}'
   http://zwshen86:8080/api/v1/clusters/bigdata/requests
执行完后，可以发现在WEB GUI上面，就多了一个正在进行的Operation。如下图：
Service Check执行进度

在这里我们可以发现，这个Operation的名字其实就是context字段的值。我们在WEB GUI上面直接点击Service Check的时候，Operation的名字其实是JS code中指定了一个特殊context。
这里我们也可以指定执行自定义命令（Custom Comand）。以给Resource Manager添加的GetMem为例。执行如下的命令。
curl -u admin:admin -H "X-Requested-By: ambari" -X POST -d '
   {"RequestInfo":{"context":"Get RM host Mem
Usage","command":"GetMem"},"Requests/resource_filters":[{"service_name":
   "YARN","component_name":"RESOURCEMANAGER","hosts":"zwshen86.eng.platformlab.ibm.com"}]}'
   http://zwshen86:8080/api/v1/clusters/bigdata/requests

WEB GUI的显示如下：自定义命令GetMem的执行进度

跟 Service Check 相比，不难看出其中的差异。对于自定义命令，我们需要指定参数 Component 以及 Host。当这两个参数缺失的时候，Ambari 是不会接受这个请求的。
通过这三个简单实例，就可以体会到Ambari Rest API的作用。在Rest API的基础上，就算脱离了WEB，我们也可以很好地控制Ambari。当然，我们也不得不记住很多生涩的参数。因此，大多情况下，只有当Ambari的GUI不足以完成需求，或者不期望暴露在GUI上面的时候，就可以使用Rest API。有兴趣的读者可以搜索下Ambari Server目录所有的Python脚本，其实Ambari自身很多地方都在用curl调用Rest API。

Ambari的发展：（以下是原文章的一些话说的不错我就复制了下来，由于该文章已经有几年了，所以他说的版本都有些老了，我这里安装的是ambari-2.2.2.0和HDP-2.4.0.0）
我们可以到Ambari的Roadmap页面查看Ambari最新release的进展，以及未来Ambari将会开发怎样的功能。例如现在的Ambari Server是存在单点问题的，如果Server机器宕机了，就无法恢复整个Ambari Server的数据，也就是说无法再通过Ambari管理集群。我们可以从Ambari的Roadmap中看到，Ambari未来会在2.2的release中考虑这个问题。
结束语：
Ambari作为一个Hadoop生态圈的管理工具，起步比Hadoop等软件晚一些。应用中免不了也会碰到一些奇怪的问题，所以未来Ambari的发展也离不开社区的贡献，更离不开每一位Committer。希望Ambari能在Hadoop的管理中脱颖而出，成为一个完美的管理平台。

参考：
https://www.ibm.com/developerworks/cn/opensource/os-cn-bigdata-ambari/
https://www.ibm.com/developerworks/cn/opensource/os-cn-bigdata-ambari2/index.html