ambari_doc

发表于   |   分类于

Stacks and Services

Introduction

Ambari支持Stack的概念，并且将服务组合在一个Stack定义中。通过堆栈的作用，Ambari有统一定义的安装接口，管理并监控一组服务，并且引入了Stacks+Servides来提供延伸。
从Ambari2.3开始，还支持Extension的概念，并将自定义服务组合在一个Extension定义中。

Terminology

Term Description
Stack 定义了一组服务，并且这些服务从这里获取软件包。一个Stack能够有一个或多个版本，并且每个版本可以是活跃/不活跃的。例如, Stack=”HDP-1.3.3”。
Extension 定义了一组自定义服务，这些自定义服务可以被添加到一个stack版本中。一个Extension能够有一个或多个版本。
Service 定义Components（MASTER、SLAVE、CLIENT）组成了Service。如，Service=”HDFS”。
Component 每个Component遵循确切的生命周期（start、stop、install等）。例如：Service=”HDFS”包含的组件有：”NameNode(MASTER)”、”Secondary NameNode(MASTER)”、”DataNode(SLAVE)”和”HDFS Client(CLIENT)”

Overview

Background

Stack的定义可以在源码结构的/ambari-server/src/main/resources/stacks中找到。在你安装了Ambari服务之后，Stack的定义可以在/var/lib/ambari-server/resources/stacks中找到。

Structure

Stack定义的结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|_ stacks
   |_ <stack_name>
      |_ <stack_version>
         metainfo.xml
         |_ hooks
         |_ repos
            repoinfo.xml
         |_ services
            |_ <service_name>
               metainfo.xml
               metrics.json
               |_ configuration
                  {configuration files}
               |_ package
                  {files, scripts, templates}

Defining a Service and Components

Service中的metainfo.xml描述了这个service、这个service的Components以及管理执行命令的脚本。服务的一个组件只能是MASTER、SLAVE或CLIENT三种类型中的一个。组件的类型用来告诉Ambari管理和监控这个组件的默认脚本。
对于每个Component，用来指从合适执行脚本。这个Component必须支持的一组默认命令。

| Component Category | Default Lifecycle Commands |
| MASTER | install, start, stop, configure, status |
| SLAVE | install, start, stop, configure, status |
| CLIENT | install, configure, status |

Ambari支持用PYTHON写的不同命令。类型用来知道如何执行命令脚本。如果你的Component需要支持多于默认生命周期的命令，你也能够创建自定义命令。
例如，下面的metainfo.xml在YARN服务描述了ResourceManager组件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<component>
  <name>RESOURCEMANAGER</name>
  <category>MASTER</category>
  <commandScript>
    <script>scripts/resourcemanager.py</script>
    <scriptType>PYTHON</scriptType>
    <timeout>600</timeout>
  </commandScript>
  <customCommands>
    <customCommand>
      <name>DECOMMISSION</name>
      <commandScript>
        <script>scripts/resourcemanager.py</script>
        <scriptType>PYTHON</scriptType>
        <timeout>600</timeout>
      </commandScript>
    </customCommand>
  </customCommands>
</component>

ResourceManager是一个MASTER组件，这个命令脚本为scripts/resourcemanager.py，这个脚本可以在services/YARN/package目录中找到。这个脚本是使用PYTHON写的，并且这个以python方法的方式实现了默认的生命周期命令。下面是install方法，对应的是默认的INSTALL命令：

1
2
3
4
class Resourcemanager(Script):
  def install(self, env):
    self.install_packages(env)
    self.configure(env)

你还可以看到有一个自定义命令DECOMMISSION，这意味着在python命令脚本中还有一个decommission方法：

1
2
3
4
5
6
7
8
9
def decommission(self, env):
  import params
 
  ...
 
  Execute(yarn_refresh_cmd,
          user=yarn_user
  )
  pass

Using Stack Inheritance

Stacks能够从其他Stack进行继承，以便共享命令脚本和配置。通过如下方式降低了代码的重复：

为子Stack定义了repositories。
在子Stack中添加新的Service（不是在父Stack中）。
重写父级Services的命令脚本。
重写父级Services的配置。

例如：HDP 2.1 Stack继承了HDP 2.0.6 Stack，因此只需要在Stack定义中对HDP 2.1 Stack中适当的修改。这个extension在metainfo.xml中对HDP 2.1 Stack进行定义。

1
2
3
4
5
6
<metainfo>
  <versions>
    <active>true</active>
  </versions>
  <extends>2.0.6</extends>
</metainfo>

Example: Implementing a Custom Service

在这个例子中，我们将创建一个名为”SAMPLESRV”的自定义service，并将它添加到已有的Stack定义中。这个service含有 MASTER、SLAVE和CLIENT组件。

Create and Add the Service

1、在Ambari server上，跳转到/var/lib/ambari-server/resources/stacks/HDP/2.0.6/services目录。在这个例子中，我们将浏览到HDP 2.0 stack定义。

1
cd /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services

2、创建一个目录：/var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/SAMPLESRV。它用来包含SAMPLESEV的service的定义。

1
2
mkdir /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/SAMPLESRV
cd /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/SAMPLESRV

3、跳转到新创建的SAMPLESRV目录，创建metainfo.xml文件，这个文件用来描述新的service。例如：

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
50
51
52
<?xml version="1.0"?>
<metainfo>
    <schemaVersion>2.0</schemaVersion>
    <services>
        <service>
            <name>SAMPLESRV</name>
            <displayName>New Sample Service</displayName>
            <comment>A New Sample Service</comment>
            <version>1.0.0</version>
            <components>
                <component>
                    <name>SAMPLESRV_MASTER</name>
                    <displayName>Sample Srv Master</displayName>
                    <category>MASTER</category>
                    <cardinality>1</cardinality>
                    <commandScript>
                        <script>scripts/master.py</script>
                        <scriptType>PYTHON</scriptType>
                        <timeout>600</timeout>
                    </commandScript>
                </component>
                <component>
                    <name>SAMPLESRV_SLAVE</name>
                    <displayName>Sample Srv Slave</displayName>
                    <category>SLAVE</category>
                    <cardinality>1+</cardinality>
                    <commandScript>
                        <script>scripts/slave.py</script>
                        <scriptType>PYTHON</scriptType>
                        <timeout>600</timeout>
                    </commandScript>
                </component>
                <component>
                    <name>SAMPLESRV_CLIENT</name>
                    <displayName>Sample Srv Client</displayName>
                    <category>CLIENT</category>
                    <cardinality>1+</cardinality>
                    <commandScript>
                        <script>scripts/sample_client.py</script>
                        <scriptType>PYTHON</scriptType>
                        <timeout>600</timeout>
                    </commandScript>
                </component>
            </components>
            <osSpecifics>
                <osSpecific>
                    <osFamily>any</osFamily>  <!-- note: use osType rather than osFamily for Ambari 1.5.0 and 1.5.1 -->
                </osSpecific>
            </osSpecifics>
        </service>
    </services>
</metainfo>

4、在上面，我们的service名为“SAMPLESRV”，它包含：

一个名为”SAMPLESRV_MASTER”的MASTER的组件。
一个名为“SLAVE”的SLAVE的组件。
一个名为“CLIENT”的CLIENT的组件。

5、接下来，创建命令脚本。为脚本创建目录/var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/SAMPLESRV/package/scripts，并在这个目录中定义service的metainfo。

1
2
mkdir -p /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/SAMPLESRV/package/scripts
cd /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/SAMPLESRV/package/scripts

跳转到script目录，并创建.py命令脚本文件。
master.py文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import sys
from 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文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import sys
from 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()

sample_client.py文件：

1
2
3
4
5
6
7
8
9
import sys
from resource_management import *
class SampleClient(Script):
  def install(self, env):
    print 'Install the Sample Srv Client';
  def configure(self, env):
    print 'Configure the Sample Srv Client';
if __name__ == "__main__":
  SampleClient().execute()

7、现在重启Ambari Server以便新的service定义分发到集群的所有Agents。

1
ambari-server restart

Install the Service(Via Ambari WEb “Add Service”)

从Ambari 1.7.0开始，可以通过Ambari Web来添加自定义服务。

在Ambari web页面，跳转到services，并点击左边service导航部分的Action按钮。
点击“Add Services”。你将看到一个包含“My Sample Service”（在metainfo.xml文件中定义service的）的选项。
选择“My Sample service”并点击下一步。
选择“Sample Srv Master”并点击下一步。
选择host来安装”Sample Srv Client”，并点击下一步。
一旦完成，”My Sample Service”将会在在service导航区可用。
如果你想要为所有host添加“Sample Srv Client”，你可以跳转到Host，并到航道指定的host并点击”+ Add”。

Example: Implementing a Custom Client-only Service

在这个例子中，我们将创建一个名为“TESTSRV”的自定义service，添加到已经存在的Stack定义上，并Ambari APIs来安装/配置这个service。这个service是一个CLIENT，因此它有两个命令：install和configure。

Create and Add the Service

1、在Ambari Service上，跳转到 /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services目录。在这个例子中，我们将跳转到HDP2.0 Stack 定义中。

1
cd /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services

2、创建一个名为/var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTSRV的目录，它用来包含TESTSRV的service定义。

1
2
mkdir /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTSRV
cd /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTSRV

3、跳转到新创建的TESTSRV目录，创建一个名为metainfo.xml的文件用来描述新的service。例如：

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
<?xml version="1.0"?>
<metainfo>
    <schemaVersion>2.0</schemaVersion>
    <services>
        <service>
            <name>TESTSRV</name>
            <displayName>New Test Service</displayName>
            <comment>A New Test Service</comment>
            <version>0.1.0</version>
            <components>
                <component>
                    <name>TEST_CLIENT</name>
                    <displayName>New Test Client</displayName>
                    <category>CLIENT</category>
                    <cardinality>1+</cardinality>
                    <commandScript>
                        <script>scripts/test_client.py</script>
                        <scriptType>PYTHON</scriptType>
                        <timeout>600</timeout>
                    </commandScript>
                    <customCommands>
                      <customCommand>
                        <name>SOMETHINGCUSTOM</name>
                        <commandScript>
                          <script>scripts/test_client.py</script>
                          <scriptType>PYTHON</scriptType>
                          <timeout>600</timeout>
                        </commandScript>
                      </customCommand>
                    </customCommands>
                </component>
            </components>
            <osSpecifics>
                <osSpecific>
                    <osFamily>any</osFamily>  <!-- note: use osType rather than osFamily for Ambari 1.5.0 and 1.5.1 -->
                </osSpecific>
            </osSpecifics>
        </service>
    </services>
</metainfo>

4、在上面，我们的service名为“TESTSRV”，并且它包含了一个名为“TEST_CLIENT”的组件，这个组件属于CLIENT类型。这个client通过命令脚本scripts/test_client.py来管理。接下来创建命令脚本。
5、为命令脚本创建目录/var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTSRV/package/scripts。

1
2
mkdir -p /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTSRV/package/scripts
cd /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTSRV/package/scripts

6、跳转到scripts目录，并创建test_client.py文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
import sys
from resource_management import *
 
class TestClient(Script):
  def install(self, env):
    print 'Install the client';
  def configure(self, env):
    print 'Configure the client';
  def somethingcustom(self, env):
    print 'Something custom';
 
if __name__ == "__main__":
  TestClient().execute()

7、现在，重启Ambari Server，将新的service定义分发到集群的所有Agents。

1
ambari-server restart

Install the Service(Via the Ambari REST API)

1、将Service添加到Cluster。

1
2
3
4
5
6
7
8
9
POST
/api/v1/clusters/MyCluster/services
 
{
"ServiceInfo": {
  "service_name":"TESTSRV"
  }
}

2、添加组件到Service。这个例子中，添加TEST_CLIENT到TESTSRV。

1
2
POST
/api/v1/clusters/MyCluster/services/TESTSRV/components/TEST_CLIENT

3、将组件添加到所有host。例如，要安装到c6402.ambari.apache.org和c6403.ambari.apache.org上，首先使用POST在这些主机上创建host_component源

1
2
3
4
5
POST
/api/v1/clusters/MyCluster/hosts/c6402.ambari.apache.org/host_components/TEST_CLIENT
 
POST
/api/v1/clusters/MyCluster/hosts/c6403.ambari.apache.org/host_components/TEST_CLIENT

4、现在，需要在所有主机上安装组件。在这个命令中，你指导Ambari来安装与这个service有关的所有组件。调用每个主机上命令脚本的install方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
PUT
/api/v1/clusters/MyCluster/services/TESTSRV
 
{
  "RequestInfo": {
    "context": "Install Test Srv Client"
  },
  "Body": {
    "ServiceInfo": {
      "state": "INSTALLED"
    }   
  }
}

除了同时安装所有的组件，你还可以只在某一台机器上装组件。在这个例子中，我们在c6402.ambari.apache.org上安装TEST_CLIENT：

1
2
3
4
5
6
7
8
9
10
11
12
13
PUT
/api/v1/clusters/MyCluster/hosts/c6402.ambari.apache.org/host_components/TEST_CLIENT
 
{
  "RequestInfo": {
    "context":"Install Test Srv Client"
  },
  "Body": {
    "HostRoles": {
      "state":"INSTALLED"
    }
  }
}

6、使用如下信息配置主机上的client。这将最终调用命令脚本中的configure()方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
POST
/api/v1/clusters/MyCluster/requests
  
{
  "RequestInfo" : {
    "command" : "CONFIGURE",
    "context" : "Config Test Srv Client"
  },
  "Requests/resource_filters": [{
    "service_name" : "TESTSRV",
    "component_name" : "TEST_CLIENT",
    "hosts" : "c6403.ambari.apache.org"
  }]
}

7、如果你想看哪些主机完成了安装。

1
2
GET
/api/v1/clusters/MyCluster/components/TEST_CLIENT

Install the Service(via Ambari Web “Add Services”)

1、在Ambari Web界面，跳转到Services并点击左侧Service导航区的Actions按钮。
2、点击“Add Services”。你将看到一个“My Test Service”的选项（在service的metainfo.xml文件中services的中定义）。
3、选择“My Test Service”并点击下一步。
4、选择主机来安装“New Test Client”并点击下一步。
5、一旦完成，“My Test Service”将在Service导航区中可用。
6、如果你想要在其他主机上添加“New Test Client”，你可以跳转到Hosts，并指定主机后点击“+ Add”。

Example: Implementing a Custom Client-only Service (with Configs)

在这个例子中，我们将创建一个名为“TESTCONFIGSRV”的自定义service，并将其添加到已有的Stack定义上。这个service是一个CLIENT类型，因此它有两个命令：install和configure。service还包含”test-confg”配置类型。

Create and Add the Service to Stack

1、在Ambari Server上，跳转到/var/lib/ambari-server/resources/stacks/HDP/2.0.6/services目录。在这个例子中，我们将跳转到HDP 2.0 Stack定义。

1
cd /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services

2、创建名为/var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTCONFIGSRV的目录，它包含了为TESTCONFIGSRV定义的service。

1
2
mkdir /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTCONFIGSRV
cd /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTCONFIGSRV

3、跳转到刚刚创建的TESTCONFIGSRV目录，创建一个metainfo.xml文件，这个文件描述了这个新的service。例如：

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
<?xml version="1.0"?>
<metainfo>
    <schemaVersion>2.0</schemaVersion>
    <services>
        <service>
            <name>TESTCONFIGSRV</name>
            <displayName>New Test Config Service</displayName>
            <comment>A New Test Config Service</comment>
            <version>0.1.0</version>
            <components>
                <component>
                    <name>TESTCONFIG_CLIENT</name>
                    <displayName>New Test Config Client</displayName>
                    <category>CLIENT</category>
                    <cardinality>1+</cardinality>
                    <commandScript>
                        <script>scripts/test_client.py</script>
                        <scriptType>PYTHON</scriptType>
                        <timeout>600</timeout>
                    </commandScript>
                </component>
            </components>
            <osSpecifics>
                <osSpecific>
                    <osFamily>any</osFamily>  <!-- note: use osType rather than osFamily for Ambari 1.5.0 and 1.5.1 -->
                </osSpecific>
            </osSpecifics>
        </service>
    </services>
</metainfo>

4、在上面，我的service的名为“TESTCONFIGSRV”，并且它包含一个名为“TESTCONFIG_CLIENT”组件，这个组件的类型为“CLINT”。这个client通过命令脚本scripts/test_client.py来管理。接下来创建这个命令脚本。
5、为命令脚本创建目录/var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTCONFIGSRV/package/scripts，这个脚本在ervice metainfo 中指定。

1
2
mkdir -p /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTCONFIGSRV/package/scripts
cd /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTCONFIGSRV/package/scripts

6、调转到scripts目录，并创建test_client.py文件。例如：

1
2
3
4
5
6
7
8
9
10
11
import sys
from resource_management import *
 
class TestClient(Script):
  def install(self, env):
    print 'Install the config client';
  def configure(self, env):
    print 'Configure the config client';
 
if __name__ == "__main__":
  TestClient().execute()

7、现在，为这个service定义配置类型。为配置目录/var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTCONFIGSRV/configuration创建一个目录。

1
2
mkdir -p /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTCONFIGSRV/configuration
cd /var/lib/ambari-server/resources/stacks/HDP/2.0.6/services/TESTCONFIGSRV/configuration

8、跳转到配置目录，并创建test-config.xml文件。例如：

1
2
3
4
5
6
7
8
9
10
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
 
<configuration>
  <property>
    <name>some.test.property</name>
    <value>this.is.the.default.value</value>
    <description>This is a kool description.</description>
 </property>
</configuration>

9、现在，重启Ambari Server以便将service分发到集群中的所有Agent上。

1
ambari-server restart

How-To Define Stacks and Services

Ambari管理的Services在Ambari的stacks文件夹中定义。
要定义自己的services和stacks并被Ambari管理，请遵循如下步骤。
上面的create your custom stack and service的例子也可以学习。
stack是services的集合。一个stack可以定义多个版本，每个版本有自己的一组service。Ambari中的Stacks在 ambari-server/src/main/resources/stacks 文件夹中定义，这个文件夹可以在安装之后的/var/lib/ambari-server/resources/stacks目录找到。
被stack管理的servces能够在 ambari-server/src/main/resources/common-services 或 ambari-server/src/main/resources/stacks 文件夹中定义。这些文件对应安装后的目录分别为：/var/lib/ambari-server/resources/common-services 或 /var/lib/ambari-server/resources/stacks。

Question : 什么时候在 common-services 或 stacks 文件夹中定义service呢
当service可能被用于多个stacks时，我们将在common-services文件夹中定义service。例如，几乎所有的stacks都需要HDFS service，因此将它定义在common-services而不是在每个stack中定义是值得推荐的。同样，如果一个service从不会被共享，它能够被定义在stack文件夹中。基本上来说stacks文件夹中定义services是不推荐的，而推荐将service定义在common-services中。

Define Service

下面展示了如何在common-services文件夹中定义一个service。在stacks文件夹中定义services时，也可以使用相同的方法，具体会在定义stack章节介绍。

Services必须提供主要的metainfo.xml文件，它提供了关于这个service的重要元数据。
除此之外，其他文件提供了关于server的更多信息。关于这些文件的更多信息将在下面提供。

一个service也可能继承自它的之前版本或common services。关于继承的更多信息，请查看Service Inheritance。

metainfo.xml

在metainfo.xml服务描述符中，首先被定义的是service和它的components。
完整的参考文献可以在Writing metainfo.xml中找到。
值得推荐的metainfo.xml实现是HDFS metainfo.xml。

Question : 是否可以在同一个metainfo.xml中定义多个services？
可以。尽管可以，但是强烈拒绝在相同的service文件夹中定义多个services。
YARN和MapReduces2就被一起定义在YARN文件夹中。它的metainfo.xml同时定义了两个services。

Scripts

对于components的定义，我们需要提供脚本来处理service的不同阶段以及组件的生命周期。
管理service和components的脚本在metainfo.xml(HDFS)中指定。
每个脚本应该继承Script类，这个父类提供了有用的方法。例如：NameNode script。


这些脚本应该在//package/script文件夹中提供。

Folder Purpose
package/script 包含了由Ambari执行的脚本。这些脚本使用正确的环境被加载到执行路径中。例如：HDFS
package/files 包含被上面脚本使用的文件。一般是其他一些作为独立进程执行的脚本（bash、python等）。例如：checkWebUI.py在HDFS检查中运行，用来确定Journal Node是否活跃。
package/tmplates 上述脚本在管理节点上生成的临时文件。一般是service需要操作的配置文件。例如：exclude_hosts_list.j2 ，被脚本使用来产生/etc/hadoop/conf/dfs.exclude。

Python

Ambari默认支持python脚本来管理service和components。
component脚本应该继承resource_management.Script类并提供component的生命周期所需的方法。
参考how to create custom stack页面，MASTER、SLAVE和CLIENT组件贯穿生命周期所需的方法如下：
master.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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()

slave.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import sys
from resource_management import Script
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()

client.py

1
2
3
4
5
6
7
8
9
import sys
from resource_management import Script
class SampleClient(Script):
  def install(self, env):
    print 'Install the Sample Srv Client';
  def configure(self, env):
    print 'Configure the Sample Srv Client';
if __name__ == "__main__":
  SampleClient().execute()

Ambari提供了有用的Python库，以便在以下方面提供写servier脚本的帮助。对于这些库的完整介绍，请通过Ambari Python Libraries页面访问。

resource_management
ambari_commons
ambari_simplejson

OS Variant Script

如果service支持多个操作系统，则需要根据不同的操作系统由独立的脚本，可以继承resource_management.Script类并使用不同的@OSFamilyImpl()注解。
这能够区分组件的不同操作系统的方法。
例如： NameNode default script， NameNode Windows script

Examples
NameNode Start， Stop
DataNode Start and Stop
HDFS configurations persistence

Custom Actions

有些时候，services需要执行一些行为，这些行为不同于Ambari提供的默认行为（install、start、stop、configure等）。
services能够定义一些action，并将这些action在UI中展示给用户，因此这些行为能够方便执行。
举例说明，如HDFS实现的Rebalance HDFS自定义行为。

Stack Changes

1、在metainfo.xml中component的部分中定义指定义命令。
2、在metainfo.xml相关的脚本中，用相同的名字实现方法，来作为自定义命令。
a）如果自定义命令不含有操作系统变量，它可以在同一个继承resource_management.Script的类中被实现。
b）如果含有操作系统变量，每个类中的不同方法可以通过@OsFamilyImpl(os_family=…)来实现。Default rebalancehdfs, Windows rebalancehdfs。
这将提供在安装了service的被管理的主机上以后端方式运行脚本的能力。

UI Changes

在host页面上查看自定义action不需要修改UI。
action将展示在主机组件的action列表中。任何master-component action将自动展示在service的action菜单上。
当action被点击后，将自动产生POST调用来触发上面定义的脚本。

Question ： 如何为UI中的自定义action提供自己的标签和图标？
在Ambari UI中，使用自定义图标和名称，添加你的component action到App.HostComponentActionMap对象。

Configuration

service的配置文件应当位于默认的configuration文件夹中。
如果使用了不同的文件夹，metainfo.xml中的，可以用来指明使用的文件夹。
metainfo.xml中需要考虑配置的重要部分是：

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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
<?xml version="1.0"?>
<metainfo>
  <schemaVersion>2.0</schemaVersion>
  <services>
    <service>
      <name>HDFS</name>
      <displayName>HDFS</displayName>
      <comment>Apache Hadoop Distributed File System</comment>
      <version>2.1.0.2.0</version>
      <components>
        ...
        <component>
          <name>HDFS_CLIENT</name>
          ...
          <configFiles>
            <configFile>
              <type>xml</type>
              <fileName>hdfs-site.xml</fileName>
              <dictionaryName>hdfs-site</dictionaryName>
            </configFile>
            <configFile>
              <type>xml</type>
              <fileName>core-site.xml</fileName>
              <dictionaryName>core-site</dictionaryName>
            </configFile>
            <configFile>
              <type>env</type>
              <fileName>log4j.properties</fileName>
              <dictionaryName>hdfs-log4j,yarn-log4j</dictionaryName>
            </configFile>                         
            <configFile>
              <type>env</type>
              <fileName>hadoop-env.sh</fileName>
              <dictionaryName>hadoop-env</dictionaryName>
            </configFile>
          </configFiles>
          ...
          <configuration-dependencies>
             <config-type>core-site</config-type>
             <config-type>hdfs-site</config-type>
          </configuration-dependencies>
        </component>
          ...
      </components>
  
      <configuration-dir>configuration</configuration-dir>
      <configuration-dependencies>
        <config-type>core-site</config-type>
        <config-type>hdfs-site</config-type>
        <config-type>hadoop-env</config-type>
        <config-type>hadoop-policy</config-type>
        <config-type>hdfs-log4j</config-type>
        <config-type>ranger-hdfs-plugin-properties</config-type>
        <config-type>ssl-client</config-type>
        <config-type>ssl-server</config-type>
        <config-type>ranger-hdfs-audit</config-type>
        <config-type>ranger-hdfs-policymgr-ssl</config-type>
        <config-type>ranger-hdfs-security</config-type>
        <config-type>ams-ssl-client</config-type>
      </configuration-dependencies>
    </service>
  </services>
</metainfo>

config-type - 字符串表示的一组配置。例如：core-site, hdfs-site, yarn-site等。当配置在Ambari中保存，它们被固化到一个config-type版本中，而且这个版本是不可变的。如果你更改并保存HDFS core-site配置4次，你将有4个版本的config-type core-site。同样，当一个service的配置被保存时，只有更改的config-type被更新。
configFiles - 列出由处理的配置文件。
configFile - 某种类型的一个配置文件。
type - 基于文件内容的不同指定文件的类型
xml - Hadoop中友好的方式，XML文件。
env - 通常用于将内容值作为模版的脚本。模版具有配置标签，并且它的值在运行时生成。
properties - 生成属性文件，每条属性的格式为key=value。
dictionaryName - 配置类型的名字。
configuration-dependencies - 列出component或service所依赖的config-type的列表。
configuration-dir - configFiles所指定的文件所处的目录。可选的，默认为configuration。

Adding new configs in a config-type

向config-type中添加一个配置项时有很多不同的参数可选。它们在这里被全面介绍。

UI - Categories

上面的定义的配置在service的配置页面显示。
要自定义分类并在UI中对配置进行排序，需要更新下面的文件。
Create Category - 更新 ambari-web/app/models/stack_service.js 文件，用来添加自己的service，以及你的新分类。
Use Category - 要将配置置于某种分类中，并指定配置的顺序，将配置添加到 ambari-web/app/data/HDP2/site_properties.js 文件中。在这个文件中，可以指定需要使用到分类，以及配置的索引。ambari-web/app/data中的stack文件夹时分层的且继承自前一个版本。片段中的配置属性在这里定义。例如 Hive Categories, Tez Categories

UI - Enhanced Configs

Enhanced Config特性使得服务提供者能够定制他们自己的service配置，并确定哪些配置主要显示给用户，而不需要修改任何UI代码。自定义包括为service提供友好的布局，更好的控制（sliders, combos, lists, toggles, spinners, etc）、更好的验证（minimum, maximum, enums）、自动的单位转换（MB, GB, seconds, milliseconds, etc.）、配置依赖以及默认值的动态推荐。
servier提供者能够达成上面所有的，只需要在stacks文件夹中修改它们service的定义。
在Enhanced Configs页面中查看更多。

Alerts

通过提供一个alert.js文件，每个service都能够定义Ambari应该跟踪的警报。
在Alerts wiki page页面能够读到更多关于报警框架的信息，而alerts.json文件的格式在Alerts definition document中可以了解到。

Kerberos

Ambari能够对一个集群启用或禁用Kerberos。要通知Ambari服务及其组件使用的身份和配置，每个服务需要提供一个kerberos.json文件。
在Automated Kerberizationwiki页面可以读到关于Kerberos的支持的信息，还可以在Kerberos Descriptor documentation中得到Kerberos的描述信息。

Metrics

对于Hadoop和Ambari管理的集群，Ambari提供了Ambari Metrics System服务，用来收集、聚合系统的metrics。
每个service可以定义哪些metrics能够被AMS收集，通过metrics.json文件来定义。你可以在Stack Defined Metrics页面中得到关于metrics.json格式的信息。

一个service通过向一个文本添加metainfo来实现向Ambari web UI中添加一个快速链接的列表，添加数据的文本遵循一个预定义JSON格式。Ambari server解析quicklink JSON文件，并将它的内容展示在UI。因此，Ambari web UI能够根据这些信息计算quick link URLs，并相应的填充quicklink的下拉列表。
关于quick link的JSON文件的设计，可以参看Quick Links页面。

Widgets

每个service都可以通过定一个widgets.json文件来定义在service的摘要页面上默认显示哪些widgets和heatmaps。
你可以在Enhanced Service Dashboard页面中看到更多关于widgets描述符的信息。

Role Command Order

从Ambari 2.2开始，每个service通过在service文件夹中包含一个role_rommand_order.json文件来定义自己的role command order。这个service应当只指定它的组件到其他组件之间的关系。换句话说，如果service只包含COMP_X，那么servier应当只列出与COMP_X相关的依赖。如果COMP_X启动，它依赖于NameNode的启动，当NameNode停止时，NameNode应该要等COMP_X先停止，下面的信息将被包含在role command order中：
Example service role_command_order.json

1
2
"COMP_X-START": ["NAMENODE-START"],
"NAMENODE-STOP": ["COMP_X-STOP"]

service的role command order条目将会与stack中定义的role command order合并。例如，因为stack已经依赖NAMENODE_STOP，在上面的例子中，COMP_X-STOP将被添加到NAMENODE-STOP的依赖，此外，COMP_X-START对NAMENODE-START的依赖将作为一个新的依赖项被添加。
对于role command order的更多信息，可以查看Role Command Order章节。

Service Advisor

从Ambari 2.4开始，每个service可以选择定义自己的service advisor，而不是在stack advisor中定义它的配置和布局的细节。这专门用于哪些没有在stack中定义的自定义service。service能够在它的service文件夹中编写一个名为service-advisor.py的Python脚本来提供Service Advisor的能力。这个文件夹可以位于定义service的stack的services目录或者用来定义可继承service的common-services目录。例如：common-services/HAWQ/2.0.0。
与Stack-advisor脚本不同，service-advisor脚本不会自动的继承父级service的service-advisor脚本。service-advisor脚本需要声明来继承它们父级service的service-advisor脚本。下面的代码向你展示了如何引用父级service的service-advisor.py。在这个例子中，它继承了位于resource/stacks中的顶级service-advisor.py。
Sample service-advisor.py file inheritance

1
2
3
4
5
6
7
8
9
10
11
12
SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__))
STACKS_DIR = os.path.join(SCRIPT_DIR, '../../../stacks/')
PARENT_FILE = os.path.join(STACKS_DIR, 'service_advisor.py')
 
try:
  with open(PARENT_FILE, 'rb') as fp:
    service_advisor = imp.load_module('service_advisor', fp, PARENT_FILE, ('.py', 'rb', imp.PY_SOURCE))
except Exception as e:
  traceback.print_exc()
  print "Failed to load parent"
 
class HAWQ200ServiceAdvisor(service_advisor.ServiceAdvisor):

与stack advisors类似，service advisor在4个重要概念上提供了信息：

1、推荐集群上service的布局。
2、推荐service配置。
3、验证集群上service的布局。
4、验证service配置。
通过提供的service-advisor.py文件，service能够动态控制上面的每一个。
对于service-advisor脚本来说主要接口是如何调用上面的每一项，以及给它们提供什么数据。

Base service_advisor.py from resources/stacks

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
class ServiceAdvisor(DefaultStackAdvisor):
  """
  Abstract class implemented by all service advisors.
  """
 
  """
  If any components of the service should be colocated with other services,
  this is where you should set up that layout.  Example:
 
    # colocate HAWQSEGMENT with DATANODE, if no hosts have been allocated for HAWQSEGMENT
    hawqSegment = [component for component in serviceComponents if component["StackServiceComponents"]["component_name"] == "HAWQSEGMENT"][0]
    if not self.isComponentHostsPopulated(hawqSegment):
      for hostName in hostsComponentsMap.keys():
        hostComponents = hostsComponentsMap[hostName]
        if {"name": "DATANODE"} in hostComponents and {"name": "HAWQSEGMENT"} not in hostComponents:
          hostsComponentsMap[hostName].append( { "name": "HAWQSEGMENT" } )
        if {"name": "DATANODE"} not in hostComponents and {"name": "HAWQSEGMENT"} in hostComponents:
          hostComponents.remove({"name": "HAWQSEGMENT"})
  """
  def colocateService(self, hostsComponentsMap, serviceComponents):
    pass
 
  """
  Any configuration recommendations for the service should be defined in this function.
  This should be similar to any of the recommendXXXXConfigurations functions in the stack_advisor.py
  such as recommendYARNConfigurations().
  """
  def getServiceConfigurationRecommendations(self, configurations, clusterSummary, services, hosts):
    pass
 
  """
  Returns an array of Validation objects about issues with the hostnames to which components are assigned.
  This should detect validation issues which are different than those the stack_advisor.py detects.
  The default validations are in stack_advisor.py getComponentLayoutValidations function.
  """
  def getServiceComponentLayoutValidations(self, services, hosts):
    return []
 
  """
  Any configuration validations for the service should be defined in this function.
  This should be similar to any of the validateXXXXConfigurations functions in the stack_advisor.py
  such as validateHDFSConfigurations.
  """
  def getServiceConfigurationsValidationItems(self, configurations, recommendedDefaults, services, hosts):
    return []

Examples

Service Upgrade

从Ambari开始，每个service能够在它的service definition中定义它自己的更新。这对哪些不再需要修改stack的upgrade-packs的自定义service，以便它们融合到集群的更新。

每个service能够定义upgrade-packs，upgrade-packs是一些XML文件，它们描述了某个service的更新进程已经这个更新包如何与所有的stack更新包相关联。这些upgrade-pack XML文件在service的upgrades/文件夹中的独立的子文件夹中，这些子文件夹指明了需要扩展的stack版本。测试代码中的一些例子。

Examples

service定义的每个upgrade-pack通过一个特定的stack版本，应当匹配service定义的文件名。例如，在测试代码中，HDP 2.2.0有一个名为upgrade_test_15388.xml的upgrade-pack。HDFS service定义了一个extension来扩展那个upgrade packHDP/2.0.5/services/HDFS/upgrades/HDP/2.2.0/upgrade_test_15388.xml。在这个例子中，upgrade-pack定义在HDP/2.0.5的stack中。这个upgrade-pack是HDP/2.2.0的一个扩展，因为他被定义在upgrade/HDP/2.2.0目录中。最终，扩展到upgrad-pack upgrade_test_15388.xml的service的名字与HDP/2.2.0/upgrades中的upgrade-pack的名字匹配。
对于service的文件格式与stack的有很大的相同。target、target-stack和type属性应该和stack的upgrade-pack的信息完全对应。service能够添加自己的前提检测。

General Attributes and Prerequisite Checks

1
2
3
4
5
6
7
<upgrade xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <target>2.4.*</target>
  <target-stack>HDP-2.4.0</target-stack>
  <type>ROLLING</type>
  <prerequisite-checks>
    <check>org.apache.ambari.server.checks.FooCheck</check>
  </prerequisite-checks>

upgrade-pack的部分，由标签组成，就像stack的upgrade-pack。关键的不同是如何定义这些，使它们与stack的upgrade pack的或其他service的upgrade pack的相关联。在第一个例子中，我们引入了名为PRE_CLUSTER的并为名为FOO的service新增了一个。该项应该在基于标签的HDFS之后的中添加。

Order Section - Add After Group Entry

1
2
3
4
5
6
7
8
9
<order>
  <group xsi:type="cluster" name="PRE_CLUSTER" title="Pre {{direction.text.proper}}">
    <add-after-group-entry>HDFS</add-after-group-entry>
    <execute-stage service="FOO" component="BAR" title="Backup FOO">
      <task xsi:type="manual">
        <message>Back FOO up.</message>
      </task>
    </execute-stage>
  </group>

同样的语法也可以被用于service检查优先级和group services等。

Order Section - Further Add After Group Entry Examples

1
2
3
4
5
6
7
8
9
10
11
12
13
<group name="SERVICE_CHECK1" title="All Service Checks" xsi:type="service-check">
  <add-after-group-entry>ZOOKEEPER</add-after-group-entry>
  <priority>
    <service>HBASE</service>
  </priority>
</group>
 
<group name="CORE_MASTER" title="Core Masters">
  <add-after-group-entry>YARN</add-after-group-entry>
  <service name="HBASE">
    <component>HBASE_MASTER</component>
  </service>
</group>

还可以在stack的upgrade-pack中增加新的group，并将它们排列在其他group之后。在下面的例子中，我们在使用标签的HIVE的group之后增加了一个名为FOO的group。

Order Section - Add After Group

1
2
3
4
5
6
7
8
<group name="FOO" title="Foo">
  <add-after-group>HIVE</add-after-group>
  <skippable>true</skippable>
  <allow-retry>false</allow-retry>
  <service name="FOO">
    <component>BAR</component>
  </service>
</group>

你还可以在同一个中同时创建和。这将会在指定的group不存在的情况下才会创建一个新的group，并且会将他排列在指定的group之后。将会确定它的group的service的内部排序、优先级和执行阶段。

Order Section - Add After Group

1
2
3
4
5
6
7
8
9
<group name="FOO" title="Foo">
  <add-after-group>HIVE</add-after-group>
  <add-after-group-entry>FOO</add-after-group-entry>
  <skippable>true</skippable>
  <allow-retry>false</allow-retry>
  <service name="FOO2">
    <component>BAR2</component>
  </service>
</group>

upgrade-pack剩余的部分，与stack的upgrade-pack的相同。

Processing Section

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<processing>
    <service name="FOO">
      <component name="BAR">
        <upgrade>
          <task xsi:type="restart-task" />
        </upgrade>
      </component>
      <component name="BAR2">
        <upgrade>
          <task xsi:type="restart-task" />
        </upgrade>
      </component>
    </service>
  </processing>

Define Stack

一个Stack就是一个版本化的service的集合。每个stack就是一个定义在ambari-server/src/main/resource/stacks中的一个文件夹。安装ambari之后，stack的定义则位于ambari-server主机的/var/lib/ambari-server/resources/stacks中。
每个stack文件夹中包含该stack的每个版本的子文件夹。一些stack版本可用，一些不可用。每个stack版本包含一些service，这些service有的继承自common-services，有些在stack版本的services中定义。

Example : HDP stack.HDP-2.4 stack version。

Stack-Version Descriptor

每个Stack-version应当提供一个metainfo.xml（如：HDP-2.3、HDP-2.4 ）文件作为描述符，它如下描述了stack-verion：

1
2
3
4
5
6
7
8
<metainfo>
    <versions>
      <active>true</active>
    </versions>
    <extends>2.3</extends>
    <minJdk>1.7</minJdk>
    <maxJdk>1.8</maxJdk>
</metainfo>

versions/active - 当前版本的stack是否还可以用于安装。如果不可用，这个版本在安装的时候将不会在UI中显示。
extends - 当前stack继承的版本。进行继承的stack版本会继承service以及父stack版本的所有方面。
minJdk - stack版本支持的最低JDK版本。在安装向导期间如果被Ambari使用的JDK低于这个版本，用户将被警告。
maxJdk - stack版本支持的最高JDK版本。在安装向导期间，如果被Ambari使用的JDK版本高于这个版本，用户将被警告。

Stack Properties

stack必须包含或继承一个属性字典，属性字典包含两个文件：stack_features.json和stack_tools.json。这个字典是在Ambari 2.4中新增的。
stack_features.json中包含了一个features的列表，这个列表指定了哪些版本的stack包含这些特性。
特性列表由特定的Ambari版本所确定。特定Ambari版本的详细列表能够在HDP/2.0.6/properties/stack_features.json中找到。每个feature由name、description以及特性所支持stack的最高版本和最低版本来构成。

1
2
3
4
5
6
7
8
9
10
{
  "stack_features": [
    {
      "name": "snappy",
      "description": "Snappy compressor/decompressor support",
      "min_version": "2.0.0.0",
      "max_version": "2.2.0.0"
    },
    ...
}

stack_tools.json包含了stack_selector和conf_selector这两个工具对应的名称以及安装位置。
任何自定义的stack必须包含这两个JSON文件。更多的信息请查看Stack Properties的wiki页面。

Services

每个stack版本中都包含services，这些services要么是引用的common-services中的，要么是在stack版本中services文件夹下定义的。
common-services中定义的services能够被多个stack共享。如果他们不会被共享，那么他们可以定义在stack版本中。

Reference common-services

要引用common-services中的一个service，service描述文件需要使用项。（例如： HDFS in HDP-2.0.6）

1
2
3
4
5
6
7
8
9
<metainfo>
  <schemaVersion>2.0</schemaVersion>
  <services>
    <service>
      <name>HDFS</name>
      <extends>common-services/HDFS/2.1.0.2.0</extends>
    </service>
  </services>
</metainfo>

Define Service

与common-services中定义的services格式相同，可以子啊services文件夹中定义新的service。
Examples：

Extend Service

当一个版本继承另外一个版本时，它继承父级service的所有细节。它也可以自由的重写或删除继承的service定义的任何部分。
Examples：

Role Command Order

Role是Component（如：NAMENODE、DATANODE、RESOURCEMANAGER、HBASE_MASTER等）的另一个名称。
顾名思义，它可以告诉Amberi在你stack中定义的component执行命令的顺序。
例如：”ZooKeeper Server 应当在启动NameNode之前启动”。“HBase Master应当在NameNode和DataNode启动之后再启动”。
这可以通过在stack-version文件夹中包含role_command_order.json来具体说明。

Format

以JSON格式指定，这个文件包含一个JSON对象，并且顶级key是section名称或comments。如：HDP-2.0.6。
在每个section对象内部，key描述了它对应的component的行为，value列出当前component-action之前应当完成的component-action。
Structure of role_command_order.json

1
2
3
4
5
6
7
8
9
10
11
{
  "_comment": "Section 1 comment",
  "section_name_1": {
    "_comment": "Section containing role command orders",
    "<DEPENDENT_COMPONENT_1>-<COMMAND>": ["<DEPENDS_ON_COMPONENT_1>-<COMMAND>", "<DEPENDS_ON_COMPONENT_1>-<COMMAND>"],
    "<DEPENDENT_COMPONENT_2>-<COMMAND>": ["<DEPENDS_ON_COMPONENT_3>-<COMMAND>"],
    ...
  },
  "_comment": "Next section comment",
  ...
}

Sections

Ambari只使用了如下的sections：

Section Name When Used
general_deps 适用于所有情况
optional_glusterfs 当集群有GLUSTERFS服务实例时
optional_no_glusterfs 当集群没有GLUSTERFS服务实例时
namenode_optional_ha 当安装了HDFS服务，且有JOURNALNODE组件时
resourcemanager_optional_ha 当安装了YARN服务，且存在多个RESOURCEMANAGER host-components存在时

Commands

Ambari当前支持的命令有：

INSTALL
UNINSTALL
START
RESTART
STOP
EXECUTE
ABORT
UPGRADE
SERVICE_CHECK
CUSTOM_COMMAND
ACTIONEXECUTE

Examples

Role Command Order Explanation
“HIVE_METASTORE-START”:[“MYSQL_SERVER-START”, “NAMENODE-START”] 启动Hive Metastore之前先启动MySQL和NameNode。
“MAPREDUCE_SERVICE_CHECK-SERVICE_CHECK”:[“NODEMANAGER-START”, “RESOURCEMANAGER-START”] MapReduce服务检查需要ResourceManager和NodeManager的启动。
“ZOOKEEPER_SERVER-STOP”:[“HBASE_MASTER-STOP”, “HBASE_REGIONSERVER-STOP”, “METRICS_COLLECTOR-STOP”] 在停止Zookeeper之前，应该先确保HBase Master、Hbase RegionServers和AMS Metrics收集器先停止。

Repositories

通过提供一个repos/repoinfo.xml（如 HDP-2.0.6），每个stack版本可以提供package的库的位置来使用。
repoinfo.xml文件中包含的库根据操作系统进行分组。每个os指定一个库列表，这些库列表会在stack版本安装时展示给用户。
这些库与packages defined in a service’s metainfo.xml配合使用，以便在系统上安装正确的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<reposinfo>
  <os family="redhat6">
    <repo>
      <baseurl>http://public-repo-1.hortonworks.com/HDP/centos6/2.x/updates/2.0.6.1</baseurl>
      <repoid>HDP-2.0.6</repoid>
      <reponame>HDP</reponame>
    </repo>
    <repo>
      <baseurl>http://public-repo-1.hortonworks.com/HDP-UTILS-1.1.0.17/repos/centos6</baseurl>
      <repoid>HDP-UTILS-1.1.0.17</repoid>
      <reponame>HDP-UTILS</reponame>
    </repo>
  </os>
<reposinfo>

baseurl - RPM库的URL，可以在这里找到repoid提供的软件。
repoid - baseurl地址使用的repo id。
reponame - 需要使用的repo的展示名。

Latest Builds

尽管repository基本URL能够对某个特定repo提供更新，但是必须在构建时定义它。当repository变更位置或更新包位于不同网站时，这就会成为一个问题。
对于这样的情况，stack-version能够提供一个JSON文件，来提供要使用的其他repo URL。
例如： HDP-2.3 repoinfo.xml uses file，它指出最新的构建包的repository URL。

json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
    ...
    "HDP-2.3":{
        "latest":{
            "centos6":"http://s3.amazonaws.com/dev.hortonworks.com/HDP/centos6/2.x/BUILDS/2.3.6.0-3586/",
            "centos7":"http://s3.amazonaws.com/dev.hortonworks.com/HDP/centos7/2.x/BUILDS/2.3.6.0-3586/",
            "debian6":"http://s3.amazonaws.com/dev.hortonworks.com/HDP/debian6/2.x/BUILDS/2.3.6.0-3586/",
            "debian7":"http://s3.amazonaws.com/dev.hortonworks.com/HDP/debian7/2.x/BUILDS/2.3.6.0-3586/",
            "suse11":"http://s3.amazonaws.com/dev.hortonworks.com/HDP/suse11sp3/2.x/BUILDS/2.3.6.0-3586/",
            "ubuntu12":"http://s3.amazonaws.com/dev.hortonworks.com/HDP/ubuntu12/2.x/BUILDS/2.3.6.0-3586/",
            "ubuntu14":"http://s3.amazonaws.com/dev.hortonworks.com/HDP/ubuntu14/2.x/BUILDS/2.3.6.0-3586/"
        }
    },
    ...
}

Hooks

stack-version会有非常基本且通用的指令，这些指令需要在某个Ambari命令之前或之后运行。
避免将代码在service脚本之间复制并要求用户确认，通过将前置代码和后置代码放到hooks文件夹中，Ambari提供了Hooks的功能。（如：HDP-2.0.6）

Command Sub-Folders

hooks子文件夹的命名模式为”->”。
那意味着子文件夹中的scripts/hook.py文件是在命令之前运行还是之后运行。
Examples：

Sub-Folder Purpose Example
before-START hook脚本，会在stack-version的任何组件启动之前被调用 HDP-2.0.6 1、设置hadoop的日志和pid目录。2、创建javahome的symlink。3、创建/etc/hadoop/conf/topology_script.py脚本
before-INSTALL hook脚本，会在stack-version的任何组件安装之前被调用 HDP-2.0.6 1、在/etc/yum.repos.d中创建repo文件。 2、安装基本包，如curl、unzip等

Ambari当前支持的命令，根据需要可以创建如下的子文件夹

Prefix Command Details
before INSTALL  
before UNINSTALL  
before START  
before RESTART  
before STOP  
after EXECUTE  
after ABORT  
after UPGRADE  
after SERVICE_CHECK &nbps;
after < custom_command> 用户指定的自定义命令，如HDFS指定的DECOMMISSION或REBALANCEHDFS这两个命令。

script/hooks.py脚本应该导入resource_management.libraries.script.hook模块，并继承Hook类。

1
2
3
4
5
6
7
8
from resource_management.libraries.script.hook import Hook
 
class CustomHook(Hook):
  def hook(self, env):
    # Do custom work
     
if __name__ == "__main__":
  CustomHook().execute()

Configurations

尽管大多数配置是在service级别设置的，但是也可以有适用于所有servies的配置，以便指示安装了此stack的集群的状态。
例如，像is security enabled?，what user runs smoke tests? 等。
这样的配置可以定义在sstack的configuration文件夹中。它们就像service级配置一样访问。

Stack Advisor

由于每个stack包含多个复杂的service，因此有必要动态确定services的布局以及确定某些配置的值。
stacks在services/目录中编写一个名为stack-advisor.py的Python脚本，使Ambari提供了Stack Advisor的能力。例如：HDP-2.0.6。Stack advisor脚本能够自动继承父级stack版本的stack advisor脚本。这允许较新的stack版本能够改变行为而不会影响之前的版本的行为。
Stack advisor在4个重要概念上提供了信息：

Recommend layout of services on cluster。
Recommend service configurations。
Validate layout of services on cluster。
Validate service configurations。

通过提供stack-advisor.py文件，能够动态的控制上面的每一项。
stack-advisor脚本的主要接口描述了上面每项应当如何调用，以及提供什么数据。

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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
class StackAdvisor(object):
  """
  Abstract class implemented by all stack advisors. Stack advisors advise on stack specific questions.
 
 
  Currently stack advisors provide following abilities:
  - Recommend where services should be installed in cluster
  - Recommend configurations based on host hardware
  - Validate user selection of where services are installed on cluster
  - Validate user configuration values
 
  Each of the above methods is passed in parameters about services and hosts involved as described below.
 
 
    @type services: dictionary
    @param services: Dictionary containing all information about services selected by the user.
      Example: {
      "services": [
        {
          "StackServices": {
            "service_name" : "HDFS",
            "service_version" : "2.6.0.2.2",
          },
          "components" : [
            {
              "StackServiceComponents" : {
                "cardinality" : "1+",
                "component_category" : "SLAVE",
                "component_name" : "DATANODE",
                "display_name" : "DataNode",
                "service_name" : "HDFS",
                "hostnames" : []
              },
              "dependencies" : []
            }, {
              "StackServiceComponents" : {
                "cardinality" : "1-2",
                "component_category" : "MASTER",
                "component_name" : "NAMENODE",
                "display_name" : "NameNode",
                "service_name" : "HDFS",
                "hostnames" : []
              },
              "dependencies" : []
            },
            ...
          ]
        },
        ...
      ]
    }
  @type hosts: dictionary
  @param hosts: Dictionary containing all information about hosts in this cluster
    Example: {
      "items": [
        {
          Hosts: {
            "host_name": "c6401.ambari.apache.org",
            "public_host_name" : "c6401.ambari.apache.org",
            "ip": "192.168.1.101",
            "cpu_count" : 1,
            "disk_info" : [
              {
              "available" : "4564632",
              "used" : "5230344",
              "percent" : "54%",
              "size" : "10319160",
              "type" : "ext4",
              "mountpoint" : "/"
              },
              {
              "available" : "1832436",
              "used" : "0",
              "percent" : "0%",
              "size" : "1832436",
              "type" : "tmpfs",
              "mountpoint" : "/dev/shm"
              }
            ],
            "host_state" : "HEALTHY",
            "os_arch" : "x86_64",
            "os_type" : "centos6",
            "total_mem" : 3664872
          }
        },
        ...
      ]
    }
 
 
    Each of the methods can either return recommendations or validations.
 
    Recommendations are made in a Ambari Blueprints friendly format.
    Validations are an array of validation objects.
  """
 
 
  def recommendComponentLayout(self, services, hosts):
    """
    Returns recommendation of which hosts various service components should be installed on.
 
    This function takes as input all details about services being installed, and hosts
    they are being installed into, to generate hostname assignments to various components
    of each service.
 
 
    @type services: dictionary
    @param services: Dictionary containing all information about services selected by the user.
    @type hosts: dictionary
    @param hosts: Dictionary containing all information about hosts in this cluster
    @rtype: dictionary
    @return: Layout recommendation of service components on cluster hosts in Ambari Blueprints friendly format.
        Example: {
          "resources" : [
            {
              "hosts" : [
                "c6402.ambari.apache.org",
                "c6401.ambari.apache.org"
              ],
              "services" : [
                "HDFS"
              ],
              "recommendations" : {
                "blueprint" : {
                  "host_groups" : [
                    {
                      "name" : "host-group-2",
                      "components" : [
                        { "name" : "JOURNALNODE" },
                        { "name" : "ZKFC" },
                        { "name" : "DATANODE" },
                        { "name" : "SECONDARY_NAMENODE" }
                      ]
                    },
                    {
                      "name" : "host-group-1",
                      "components" :
                        { "name" : "HDFS_CLIENT" },
                        { "name" : "NAMENODE" },
                        { "name" : "JOURNALNODE" },
                        { "name" : "ZKFC" },
                        { "name" : "DATANODE" }
                      ]
                    }
                  ]
                },
                "blueprint_cluster_binding" : {
                  "host_groups" : [
                    {
                      "name" : "host-group-1",
                      "hosts" : [ { "fqdn" : "c6401.ambari.apache.org" } ]
                    },
                    {
                      "name" : "host-group-2",
                      "hosts" : [ { "fqdn" : "c6402.ambari.apache.org" } ]
                    }
                  ]
                }
              }
            }
          ]
        }
    """
    pass
 
  def validateComponentLayout(self, services, hosts):
    """
    Returns array of Validation issues with service component layout on hosts
 
 
    This function takes as input all details about services being installed along with
    hosts the components are being installed on (hostnames property is populated for
    each component). 
 
    @type services: dictionary
    @param services: Dictionary containing information about services and host layout selected by the user.
    @type hosts: dictionary
    @param hosts: Dictionary containing all information about hosts in this cluster
    @rtype: dictionary
    @return: Dictionary containing array of validation items
        Example: {
          "items": [
            {
              "type" : "host-group",
              "level" : "ERROR",
              "message" : "NameNode and Secondary NameNode should not be hosted on the same machine",
              "component-name" : "NAMENODE",
              "host" : "c6401.ambari.apache.org"
            },
            ...
          ]
        } 
    """
    pass
 
 
  def recommendConfigurations(self, services, hosts):
    """
    Returns recommendation of service configurations based on host-specific layout of components.
 
    This function takes as input all details about services being installed, and hosts
    they are being installed into, to recommend host-specific configurations.
 
 
    @type services: dictionary
    @param services: Dictionary containing all information about services and component layout selected by the user.
    @type hosts: dictionary
    @param hosts: Dictionary containing all information about hosts in this cluster
    @rtype: dictionary
    @return: Layout recommendation of service components on cluster hosts in Ambari Blueprints friendly format.
        Example: {
         "services": [
          "HIVE",
          "TEZ",
          "YARN"
         ],
         "recommendations": {
          "blueprint": {
           "host_groups": [],
           "configurations": {
            "yarn-site": {
             "properties": {
              "yarn.scheduler.minimum-allocation-mb": "682",
              "yarn.scheduler.maximum-allocation-mb": "2048",
              "yarn.nodemanager.resource.memory-mb": "2048"
             }
            },
            "tez-site": {
             "properties": {
              "tez.am.java.opts": "-server -Xmx546m -Djava.net.preferIPv4Stack=true -XX:+UseNUMA -XX:+UseParallelGC",
              "tez.am.resource.memory.mb": "682"
             }
            },
            "hive-site": {
             "properties": {
              "hive.tez.container.size": "682",
              "hive.tez.java.opts": "-server -Xmx546m -Djava.net.preferIPv4Stack=true -XX:NewRatio=8 -XX:+UseNUMA -XX:+UseParallelGC",
              "hive.auto.convert.join.noconditionaltask.size": "238026752"
             }
            }
           }
          },
          "blueprint_cluster_binding": {
           "host_groups": []
          }
         },
         "hosts": [
          "c6401.ambari.apache.org",
          "c6402.ambari.apache.org",
          "c6403.ambari.apache.org"
         ]
        }
    """
    pass
 
  def validateConfigurations(self, services, hosts):
    """"
    Returns array of Validation issues with configurations provided by user
    This function takes as input all details about services being installed along with
    configuration values entered by the user. These configurations can be validated against
    service requirements, or host hardware to generate validation issues.
 
 
    @type services: dictionary
    @param services: Dictionary containing information about services and user configurations.
    @type hosts: dictionary
    @param hosts: Dictionary containing all information about hosts in this cluster
    @rtype: dictionary
    @return: Dictionary containing array of validation items
        Example: {
         "items": [
          {
           "config-type": "yarn-site",
           "message": "Value is less than the recommended default of 682",
           "type": "configuration",
           "config-name": "yarn.scheduler.minimum-allocation-mb",
           "level": "WARN"
          }
         ]
       }
    """
    pass

Examples:

Stack Advisor interface
Default Stack Advisor implementation - for all stacks
HDP(2.0.6) Default Stack Advisor implementation
YARN container size calculate
Recommended configurations - HDFS，YARN，MapReduce2, HBase (HDP-2.0.6)，HBase (HDP-2.3)
Delete HBase Bucket Cache configs on smaller machines
Specify maximum value for Tez config

Properties

与stack的配置类似，大多属性都是在service级定义，然而也可以在stack-version级别定义全局属性来影响所有的services。
一些例子：stack-selector and conf-selector 或 stack versions certain stack features。这里的大多属性都是在Ambari 2.4版本引入的以影响stack信息参数化和促进common-service代码重用。
这些属性可以定义在stack的properties文件中的.json文件中。
stack属性的更多信息可以在Stack Properties section找到。

Widgets

暂无

Kerberos

之前我们已经在service级别介绍了Kerberos。
stack-version级别定义的Kerberos为所有的service提供了身份描述。

Examples：Smoke test user and SPNEGO user define in HDP-2.0.6

Stack Upgrades

暂无

Writing metainfo.xml

metainfo.xml是Ambari管理的service的定义，它描述了service的内容。它是service定义中最重要的文件。这一章来介绍metainfo.xml中的各个片段。

Structure

不重要的字段使用斜体显示。
描述一个service的顶级字段如下：

Field What is it used for Sample Values
name service的名字。这个名字必须是service所在Stack范围内唯一的。 HDFS
displayName service在UI中显示的名字。 HDFS
version service的版本。名字和版本一起确定了唯一的service。 2.1.0.2.0
components service的组件列表 < check out HDFS metainfo>
osSpecifics 指定service运行所需的操作系统 < check out HDFS metainfo>
commandScript 定义service check脚本 < check out HDFS metainfo>
comment service的简短描述 Apache Hadoop Distributed File System
requiredServices 该服务所需的前置服务 < check out HDFS metainfo>
configuration-dependencies service所需的其他配置文件（这些配置文件本身属于其他service） < check out HDFS metainfo>
restartRequiredAfterRackChange Rack变更后是否必须重启 true / false
configuration-dir 如果配置目录不是默认的configuration，则需要使用该项来指定 -

service/components - 一个service包含多个components。与component有关的字段有：

Field What is it used it Sample Values
name component的名字。 NameNode
dsplayName component的显示名。 NameNode
category component的类型。可选值为MASTER、SLAVE或CLIENT。 -
commandScript 应用的命令。 < check out HDFS metainfo>
cardinality 允许的实例个数。 MASTER一般设置为1-2， SLAVE一般设置为1+
reassignAllowed 是否允许component被重新分配或移动到另外的主机。 true / false
versionAdvertised component是否显示它的版本信息。回滚/升级时使用。 true / false
timelineAppid metrics收集时用来进行区分的id。 HDFS
dependencies component所依赖的其他component列表。 < check out HDFS metainfo>
customCommands 组件的自定义命令，有别与标准命令。 RESTART_LLAP (Check out HIVE metainfo)

service/osSpecifics - 操作系统包的名

Field What is it used for Sample Values
osFamily service对应的操作系统 any => all， amazon2015、redhat6、debian7
packages 部署这个service所需的packages列表 < check out HDFS metainfo>
package/name package的名字(会被yum\apt等命令使用) 如 hadoop-lzo

service/commandScript - service检查的脚本

Field What is it used for Sample Values
script 脚本的相对路径 scripts/service_check.py
scriptType 脚本的类型，当前纸支持PYTHON PYTHON
timeout 命令的超时时间 300

service/component/customCommand - component的自定义命令

name: 自定义命令的名字
commandScript: 实现自定义命令的脚本信息，它包含其他片段。
commandScript/script: 脚本的相对路径
commandScript/scriptType: 脚本的类型，目前只支持PYTHON。
commandScript/timeout: 命令的超时时间。

Sample metainfo.xml

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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
<metainfo>
  <schemaVersion>2.0</schemaVersion>
  <services>
    <service>
      <name>HBASE</name>
      <displayName>HBase</displayName>
      <comment>Non-relational distributed database and centralized service for configuration management &amp;
 synchronization
      </comment>
      <version>0.96.0.2.0</version>
      <components>
        <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>
        <component>
          <name>HBASE_REGIONSERVER</name>
          <displayName>RegionServer</displayName>
          <category>SLAVE</category>
          <cardinality>1+</cardinality>
          <versionAdvertised>true</versionAdvertised>
          <timelineAppid>HBASE</timelineAppid>
          <commandScript>
            <script>scripts/hbase_regionserver.py</script>
            <scriptType>PYTHON</scriptType>
          </commandScript>
        </component>
        <component>
          <name>HBASE_CLIENT</name>
          <displayName>HBase Client</displayName>
          <category>CLIENT</category>
          <cardinality>1+</cardinality>
          <versionAdvertised>true</versionAdvertised>
          <commandScript>
            <script>scripts/hbase_client.py</script>
            <scriptType>PYTHON</scriptType>
          </commandScript>
          <configFiles>
            <configFile>
              <type>xml</type>
              <fileName>hbase-site.xml</fileName>
              <dictionaryName>hbase-site</dictionaryName>
            </configFile>
            <configFile>
              <type>env</type>
              <fileName>hbase-env.sh</fileName>
              <dictionaryName>hbase-env</dictionaryName>
            </configFile>
          </configFiles>
        </component>
      </components>
      <osSpecifics>
        <osSpecific>
          <osFamily>any</osFamily>
          <packages>
            <package>
              <name>hbase</name>
            </package>
          </packages>
        </osSpecific>
      </osSpecifics>
      <commandScript>
        <script>scripts/service_check.py</script>
        <scriptType>PYTHON</scriptType>
        <timeout>300</timeout>
      </commandScript>
      
      <requiredServices>
        <service>ZOOKEEPER</service>
        <service>HDFS</service>
      </requiredServices>
      <configuration-dependencies>
        <config-type>core-site</config-type>
        <config-type>hbase-site</config-type>
        <config-type>ranger-hbase-policymgr-ssl</config-type>
        <config-type>ranger-hbase-security</config-type>
      </configuration-dependencies>
    </service>
  </services>
</metainfo>