实例 2，获取 Service 的 Component 和 Host 列表上个实例中，让用户登录到每个机器去执行 yum 卸载安装包，其实是不太现实的。一般我们会写一个脚本先通过 curl 调用 GET 方法，先获取到 Service 的 Component 列表，然后再调用 GET 方法，获取 Component 的机器列表，接着调用 DELETE 从 Ambari 中删除 Service。最后脚本通过 SSH 登录到各个 Agent 机器上执行 yum 卸载安装包。脚本示例代码如下（该脚本只能在 Ambari Server 上执行，因为 Ambari Server 有无密码登录所有 Agent 机器的权限）。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| #!/bin/sh
GetHostList()
{
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 1
fi
AMBARI_HOST=$1
CLUSTER=$2
SERVICE=$3
PACKAGE=$4
GetServiceComponent
cat ./temp_component_list|while read line
do
COMPONENT=`echo $line|awk -F: '{print $2}'`
GetHostList $COMPONENT
done
curl -u admin:admin -H "X-Requested-By: ambari" -X DELETE
http://$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 $hosts
do
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，就是该 Service 的 Check 命令。以 YARN 为例，执行如下的命令。
1
2
3
4
| 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。如下图：
图 19. Service Check 执行进度 在这里我们可以发现，这个 Operation 的名字其实就是 context 字段的值。我们在 WEB GUI 上面直接点击 Service Check 的时候，Operation 的名字其实是 JS code 中指定了一个特殊 context。
这里我们也可以指定执行自定义命令（Custom Comand）。以给 Resource Manager 添加的 GetMem 为例。执行如下的命令。
1
2
3
4
5
| 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 的显示如下
图 20. 自定义命令 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 的 Roadmap 页面查看 Ambari 最新 release 的进展，以及未来 Ambari 将会开发怎样的功能。例如现在的 Ambari Server 是存在单点问题的，如果 Server 机器宕机了，就无法恢复整个 Ambari Server 的数据，也就是说无法再通过 Ambari 管理集群。我们可以从 Ambari 的 Roadmap 中看到，Ambari 未来会在 2.2 的 release 中考虑这个问题。 |
