利用角色简化playbook

1. 描述角色结构

1.1 利用角色构造ansible playbook

随着开发更多的playbook，我们可能会发现有很多机会重复利用以前缩写的playbook中的代码。或许，一个用于为某一应用配置MySQL数据库的play可以改变用途，通过利用不同的主机名、密码和用户来为另一个应用配置MySQL数据库。

但在现实中，这个play可能比较冗长且复杂，有许多包含或导入的文件，以及用于管理各种情况的任务和处理程序。将所有这些代码复制到另一playbook中可能比较困难。

Ansible角色提供了一种方法，让用户能以通用的方式更加轻松地重复利用Ansible代码。我们可以在标准化目录结构中打包所有任务、变量、文件、模板，以及调配基础架构或部署应用所需的其他资源。只需通过复制相关的目录，将角色从一个项目复制到另一个项目。然后，只需从一个play调用该角色就能执行它。

借助编写良好的角色，可以从playbook中向角色传递调整其行为的变量，设置所有站点相关的主机名、IP地址、用户名，或其他在本地需要的具体详细信息。例如，部署数据库服务器的角色可能已编写为支持多个变量，这些变量用于设置主机名、数据库管理员用户和密码，以及需要为安装进行自定义的其他参数。角色的作者也可以确保在选择不在play中设置变量值时，为这些变量设定合理的默认值。
Ansible角色具有下列优点：

• 角色可以分组内容，从而与他人轻松共享代码
• 可以编写角色来定义系统类型的基本要素：Web服务器、数据库服务器、Git存储库，或满足其他用途
• 角色使得较大型项目更容易管理
• 角色可以由不同的管理员并行开发

除了自行编写、使用、重用和共享角色外，还可以从其他来源获取角色。一些角色已包含在rhel-system-roles软件包中，用户也可以从Ansible Galaxy网站获取由社区提供支持的许多角色。

在控制主机上下载红帽公司提供角色：
yum -y install rhel-system-roles
角色一般存放在该目录下：
/usr/share/ansible/roles/
官方角色网站:
https://galaxy.ansible.com

1.2 检查ansible角色结构

Ansible角色由子目录和文件的标准化结构定义。顶级目录定义角色本身的名称。文件整理到子目录中，子目录按照各个文件在角色中的用途进行命名，如tasks和handlers。files和templates子目录中包含由其他YAML文件中的任务引用的文件。
以下tree命令显示了user.example角色的目录结构：

[root@localhost roles]# tree user.example/
user.example/
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

Ansible角色子目录:

1.3 定义变量和默认值

角色变量通过在角色目录层次结构中创建含有键值对的vars/main.yml文件来定义。与其他变量一样，这些角色变量在角色YAML文件中引用：{{ VAR_NAME }}。这些变量具有较高的优先级，无法被清单变量覆盖。这些变量旨在供角色的内部功能使用。

默认变量允许为可在play中使用的变量设置默认值，以配置角色或自定义其行为。它们通过在角色目录层次结构中创建含有键值对的defaults/main.yml文件来定义。默认变量具有任何可用变量中最低的优先级。它们很容易被包括清单变量在内的任何其他变量覆盖。这些变量旨在让用户在编写使用该角色的play时可以准确地自定义或控制它将要执行的操作。它们可用于向角色提供所需的信息，以正确地配置或部署某些对象。

在vars/main.yml或defaults/main.yml中定义具体的变量，但不要在两者中都定义。有意要覆盖变量的值时，应使用默认变量。
注意：
角色不应该包含特定于站点的数据。它们绝对不应包含任何机密，如密码或私钥。
这是因为角色应该是通用的，可以重复利用并自由共享。特定于站点的详细信息不应硬编码到角色中。
机密应当通过其他途径提供给角色。这是用户可能要在调用角色时设置角色变量的一个原因。play中设置的角色变量可以提供机密，或指向含有该机密的Ansible Vault加密文件。

角色是指一段已经写好了通用的playbook代码。
分为：
1、通用的角色(例如在playbook中那些安装的包是放在角色中的)
2、不通用的角色(用户数据、项目数据、业务数据是不会放到角色中去)

1.4 在playbook中使用ansible角色

在playbook中使用角色非常简单。下例演示了调用Ansible角色的一种方式：

[root@king ~]# yum -y install rhel-system-roles
[root@king ~]# ls /usr/share/ansible/roles/  //在此目录可以查看到角色
linux-system-roles.certificate      rhel-system-roles.certificate
linux-system-roles.crypto_policies  rhel-system-roles.crypto_policies
linux-system-roles.ha_cluster       rhel-system-roles.ha_cluster
linux-system-roles.kdump            rhel-system-roles.kdump
linux-system-roles.kernel_settings  rhel-system-roles.kernel_settings
linux-system-roles.logging          rhel-system-roles.logging
linux-system-roles.metrics          rhel-system-roles.metrics
linux-system-roles.nbde_client      rhel-system-roles.nbde_client
linux-system-roles.nbde_server      rhel-system-roles.nbde_server
linux-system-roles.network          rhel-system-roles.network
linux-system-roles.postfix          rhel-system-roles.postfix
linux-system-roles.selinux          rhel-system-roles.selinux
linux-system-roles.ssh              rhel-system-roles.ssh
linux-system-roles.sshd             rhel-system-roles.sshd
linux-system-roles.storage          rhel-system-roles.storage
linux-system-roles.timesync         rhel-system-roles.timesync
linux-system-roles.tlog             rhel-system-roles.tlog
linux-system-roles.vpn              rhel-system-roles.vpn
[root@king ~]# mkdir test
[root@king ~]# cd test/
[root@king test]# mkdir roles
[root@king roles]# vim postfix.yml

---
- hosts: test1
  roles:
    - role: rhel-system-roles.postfix   //所用的角色
[root@king roles]# ansible-playbook --syntax-check postfix.yml 

playbook: postfix.yml
[root@king roles]# tree
.
├── postfix.yml
└── rhel-system-roles.postfix  
    ├── ansible_pytest_extra_requirements.txt
    ├── COPYING
    ├── custom_requirements.txt
    ├── defaults
    │   └── main.yml
    ├── handlers
    │   └── main.yml
    ├── meta
    │   └── main.yml
    ├── molecule_extra_requirements.txt
    ├── pylint_extra_requirements.txt
    ├── pytest_extra_requirements.txt
    ├── README.html
    ├── README.md
    ├── tasks
    │   └── main.yml
    ├── tests
    │   ├── roles
    │   ├── tests_default.yml
    │   └── tests_set_banner.yml
    └── tox.ini

对于每个指定的角色，角色任务、角色处理程序、角色变量和角色依赖项将按照顺序导入到playbook中。角色中的任何copy、script、template或include_tasks/import_tasks任务都可引用角色中相关的文件、模板或任务文件，且无需相对或绝对路径名称。Ansible将分别在角色的files、templates或tasks子目录中寻找它们。

如果使用roles部分将角色导入到play中，这些角色会在用户为该play定义的任何任务之前运行。

以下示例设置role2的两个角色变量var1和var2的值。使用role2时，任何defaults和vars变量都会被覆盖。

---
- hosts: remote.example.com
  roles:
    - role: role1
    - role: role2
      var1: val1
      var2: val2

以下是在此情形中用户可能看到的另一种等效的YAML语法：

---
- hosts: remote.example.com
  roles:
    - role: role1
    - { role: role2, var1: val1, var2: val2 }  //设置role2的两个角色变量var1和var2的值

1.5 控制执行顺序

对于playbook中的每个play，任务按照任务列表中的顺序来执行。执行完所有任务后，将执行任务通知的处理程序。

在角色添加到play中后，角色任务将添加到任务列表的开头。如果play中包含第二个角色，其任务列表添加到第一个角色之后。

角色处理程序添加到play中的方式与角色任务添加到play中相同。每个play定义一个处理程序列表。角色处理程序先添加到处理程序列表，后跟play的handlers部分中定义的任何处理程序。

在某些情形中，可能需要在角色之前执行一些play任务。若要支持这样的情形，可以为play配置pre_tasks部分。列在此部分中的所有任务将在执行任何角色之前执行。如果这些任务中有任何一个通知了处理程序，则这些处理程序任务也在角色或普通任务之前执行。

此外，play也支持post_tasks关键字。这些任务在play的普通任务和它们通知的任何处理程序运行之后执行。

以下play演示了一个带有pre_tasks、roles、tasks、post_tasks和handlers的示例。一个play中通常不会同时包含所有这些部分。

[root@king playbook]# vim test.yml 
[root@king playbook]# ansible-playbook --syntax-check test.yml 

playbook: test.yml
[root@king playbook]# cat test.yml 
---
- hosts: test1
  tasks:
    - name: test
      command: "echo hello "
  post_tasks:
    - name: post_tasks
      debug:
        msg: "pass"
  pre_tasks:
    - name: pre_tasks
      debug:
        msg: "pig wow~"      
[root@king playbook]# ansible-playbook test.yml 

PLAY [test1] *********************************************************************************

TASK [Gathering Facts] ***********************************************************************
ok: [test1]

TASK [pre_tasks] *****************************************************************************
ok: [test1] => {
    "msg": "pig wow~"
}

TASK [test] **********************************************************************************
changed: [test1]

TASK [post_tasks] ****************************************************************************
ok: [test1] => {
    "msg": "pass"
}

PLAY RECAP ***********************************************************************************
test1                      : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

[root@king playbook]#

以下playbook演示了如何通过include_role模块来利用任务包含角色：

[root@king playbook]# mkdir roles
[root@king playbook]# cp -a /usr/share/ansible/roles/rhel-system-roles.timesync roles/timesync[root@king playbook]# ls roles/
timesync
[root@king playbook]# vim play.yml
[root@king playbook]# ansible-playbook --syntax-check play.yml 

playbook: play.yml
[root@king playbook]# cat play.yml 
---
- hosts: test1
  tasks:
    - name: tasts
      debug:
        msg: Sure task
    - name: timesync
      include_role: 
        name: roles/timesync
      vars:
        timesyc_ntp_servers:
          - hostname: www.baidu.com
            iburst: yes

2. 利用系统角色重用内容

2.1 红帽企业Linux系统角色

自RHEL7.4开始，操作系统随附了多个Ansible角色，作为rhel-system-roles软件包的一部分。在RHEL8中，该软件包可以从AppStream中获取。以下是每个角色的简要描述：
RHEL系统角色

系统角色的目的是在多个版本之间标准化红帽企业Linux子系统的配置。使用系统角色来配置版本6.10及以上的任何红帽企业Linux主机。

2.2 安装RHEL系统角色

安装RHEL系统角色：

yum -y install rhel-system-roles

查看安装的RHEL系统角色位置：

ls /usr/share/ansible/roles/

红帽企业Linux中的默认roles_path在路径中包含/usr/share/ansible/roles，因此在playbook引用这些角色时Ansible可以很轻松的找到它们。
安装后，RHEL系统角色的文档位于/usr/share/doc/rhel-system-roles-/目录中。每个角色的文档目录均包含一个README.md文件。README.md文件含有角色的说明，以及角色用法信息。

2.3 时间同步角色示例

文件也会说明影响角色行为的角色变量。通常，README.md文件中含有一个playbook代码片段，用于演示常见配置场景的变量设置。

部分角色文档目录中含有示例playbook。首次使用某一角色时，请查看文档目录中的任何额外示例playbook。

RHEL系统角色的角色文档与Linux系统角色的文档相匹配。使用Web浏览器来访问位于Ansible Galaxy网站https://galaxy.ansible.com/docs/上的角色文档。
假设需要在服务器上配置NTP时间同步。我们可以自行编写自动化来执行每一个必要的任务。但是，RHEL系统角色中有一个可以执行此操作角色，那就是rhel-system-roles.timesync。

该角色的详细记录位于**/usr/share/doc/rhel-system-roles/timesync**目录下的README.md中。此文件说明了影响角色行为的所有变量，还包含演示了不同时间同步配置的三个playbook代码片段。

为了手动配置NTP服务器，该角色具有一个名为timesync_ntp_servers的变量。此变量取一个要使用的NTP服务器的列表作为值。列表中的每一项均由一个或多个属性构成。两个关键属性如下：
timesync_ntp_servers属性:

hostname	要与其同步的NTP服务器的主机名。
iburst	一个布尔值，用于启用或禁用快速初始同步。在角色中默认为no，但通常应该将属性设为yes.

根据这一信息，以下示例play使用rhel-system-roles.timesync角色将受管主机配置,并设置timezone时区：

[root@king playbook]# rm -rf play.yml 
[root@king playbook]# mkdir group_vars
[root@king playbook]# cd group_vars/
[root@king group_vars]# mkdir testhost
[root@king group_vars]# cd testhost/
[root@king testhost]# vim timesync.yml
[root@king testhost]# cd ..
[root@king group_vars]# cd ..
[root@king playbook]# vim play.yml
# timesync.yml定义时间同步变量，覆盖清单中servers组内主机的角色默认值。此文件看起来类似于：
[root@king playbook]# cat group_vars/testhost/timesync.yml 
timesync_ntp_servers:
  - hostname: time1. aliyun.com
    iburst: yes
timezone: Asia/Shanghai
# timesync_playbook.yml的内容简化为：
[root@king playbook]# cat play.yml 
---
- hosts: test1
  roles:
    - role: roles/timesync
  tasks:
    - name: set timezone
      timezone:
        name: "{{ timezone }}"
[root@king playbook]# ansible-playbook --syntax-check play.yml 

playbook: play.yml
[root@king playbook]# ansible-playbook play.yml
......

如果要设置不同的时区，可以使用tzselect命令查询其他有效的值。也可以使用timedatectl命令来检查当前的时钟设置。

[root@king playbook]# tzselect
Please identify a location so that time zone rules can be set correctly.
Please select a continent, ocean, "coord", or "TZ".
 1) Africa
 2) Americas
 3) Antarctica
 4) Asia
 5) Atlantic Ocean
 6) Australia
 7) Europe
 8) Indian Ocean
 9) Pacific Ocean
10) coord - I want to use geographical coordinates.
11) TZ - I want to specify the time zone using the Posix TZ format.
#? 4  //选择你要使用的州，如：Asia亚洲
Please select a country whose clocks agree with yours.
 1) Afghanistan		  18) Israel		    35) Palestine
 2) Armenia		  19) Japan		    36) Philippines
 3) Azerbaijan		  20) Jordan		    37) Qatar
 4) Bahrain		  21) Kazakhstan	    38) Russia
 5) Bangladesh		  22) Korea (North)	    39) Saudi Arabia
 6) Bhutan		  23) Korea (South)	    40) Singapore
 7) Brunei		  24) Kuwait		    41) Sri Lanka
 8) Cambodia		  25) Kyrgyzstan	    42) Syria
 9) China		  26) Laos		    43) Taiwan
10) Cyprus		  27) Lebanon		    44) Tajikistan
11) East Timor		  28) Macau		    45) Thailand
12) Georgia		  29) Malaysia		    46) Turkmenistan
13) Hong Kong		  30) Mongolia		    47) United Arab Emirates
14) India		  31) Myanmar (Burma)	    48) Uzbekistan
15) Indonesia		  32) Nepal		    49) Vietnam
16) Iran		  33) Oman		    50) Yemen
17) Iraq		  34) Pakistan
#? 9 //选择你要用的地方时区
Please select one of the following time zone regions.
1) Beijing Time
2) Xinjiang Time
#? 

[root@king playbook]# timedatectl   //检查当前时钟时间
               Local time: Tue 2021-11-30 13:16:38 CST
           Universal time: Tue 2021-11-30 05:16:38 UTC
                 RTC time: Tue 2021-11-30 05:16:38
                Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: no
              NTP service: n/a
          RTC in local TZ: no

该结构可清楚地分隔角色、playbook代码和配置设置。Playbook代码简单易读，应该不需要复杂的重构。角色内容由红帽进行维护并提供支持。所有设置都以清单变量的形式进行处理。

该结构还支持动态的异构环境。具有新的时间同步要求的主机可能会放置到新的主机组中。相应的变量在YAML文件中定义，并放置到相应的group_vars（或host_vars）子目录中。

2.4 SELINUX角色示例

rhel-system-roles.selinux角色可以简化SELinux配置设置的管理。它通过利用SELinux相关的Ansible模块来实施。与自行编写任务相比，使用此角色的优势是它能让用户摆脱编写这些任务的职责。取而代之，用户将为角色提供变量以对其进行配置，且角色中维护的代码将确保应用用户需要的SELinux配置。
此角色可以执行的任务包括：

• 设置enforcing或permissive模式
• 对文件系统层次结构的各部分运行restorecon
• 设置SELinux布尔值
• 永久设置SELinux文件上下文
• 设置SELinux用户映射

2.5 调用SELinux角色

有时候，SELinux角色必须确保重新引导受管主机，以便能够完整应用其更改。但是，它本身从不会重新引导主机。如此一来，用户便可以控制重新引导的处理方式。

其工作方式为，该角色将一个布尔值变量selinux_reboot_required设为True，如果需要重新引导，则失败。你可以使用block/rescure结构来从失败中恢复，具体操作为：如果该变量未设为true，则让play失败，如果值是true，则重新引导受管主机并重新运行该角色。Play中的块看起来应该类似于：

[root@king playbook]# vim myplay.yml
[root@king playbook]# ansible-playbook --syntax-check myplay.yml 

playbook: myplay.yml
[root@king playbook]# cat myplay.yml 
---
- hosts: test1
  vars:
    selinux_policy: targeted
    selinux_state: disabled
  tasks:
    - name: apply selinux
      block:
        - include_role:
            name: rhel-system-roles.selinux
      rescue:
        - name: selinux...
          fail:
          when: not selinux_reboot_required
        - name: reboot
          reboot:

        - include_role:
            name: rhel-system-roles.selinux
[root@king playbook]# ansible-playbook myplay.yml

2.6 配置SELinux角色

用于配置rhel-system-roles.selinux角色的变量的详细记录位于其README.md文件中。以下示例演示了使用此角色的一些方法。

selinux_state变量设置SELinux的运行模式。它可以设为enforcing(运行-严格)、permissive(宽松-管理)或disabled(关闭)。如果未设置，则不更改模式。

 selinux_policy: targeted  //有针对性
 selinux_state: disabled

selinux_booleans变量取一个要调整的SELinux布尔值的列表作为值(一般不会变动布尔值)。列表中的每一项是变量的散列/字典：布尔值的name、state（它应是on还是off），以及该设置是否应在重新引导后persistent。

本例将httpd_enable_homedirs永久设为on：

selinux_booleans:
  - name: 'httpd_enable_homedirs'
    state: 'on'
    persistent: 'yes'

selinux_fcontext变量取一个要永久设置（或删除）的文件上下文的列表作为值。它的工作方式与selinux fcontent命令非常相似。

以下示例确保策略中包含一条规则，用于将/srv/www下所有文件的默认SELinux类型设为httpd_sys_content_t。

selinux_fcontexts:
  - target: '/srv/www(/.*)?'
    setype: 'httpd_sys_content_t'
    state: 'present'

selinux_ports变量取应当具有特定SELinux类型的端口的列表作为值:

[root@king playbook]# vim myplay.yml 
[root@king playbook]# ansible-playbook --syntax-check myplay.yml 

playbook: myplay.yml
[root@king playbook]# cat myplay.yml 
---
 1. hosts: test1
  vars:
    selinux_ports:
      - setype: http_port_t   //添加端口得类型,查看服务端口类型[semanage port -l|grep http]
        ports: 82
        start: present
        proto: tcp
    roles：
      - role: rhel-system-roles.selinux

3. 创建角色

角色创建流程
在Ansible中创建角色不需要特别的开发工具。创建和使用角色包含三个步骤：

① 创建角色目录结构
② 定义角色内容
③ 在playbook中使用角色

3.1 创建角色目录结构

默认情况下，Ansible在Ansible Playbook所在目录的roles子目录中查找角色。这样，用户可以利用playbook和其他支持文件存储角色。

如果Ansible无法在该位置找到角色，它会按照顺序在Ansible配置设置roles_path所指定的目录中查找。此变量包含要搜索以下三个目录(优先级逐次减小)，其中某个目录会被定义有角色列表。此变量的默认值为：

~/.ansible/roles
/usr/share/ansible/roles
/etc/ansible/roles

这允许用户将角色安装到由多个项目共享的系统上。例如，用户可能将自己的角色安装在自己的主目录下的~/.ansible/roles子目录中，而系统可能将所有用户的角色安装在/usr/share/ansible/roles目录中。
每个角色具有自己的目录，采用标准化的目录结构。例如，以下目录结构包含了定义motd角色的文件。

[root@localhost ~]# tree roles/
roles/
└── motd
    ├── defaults
    │   └── main.yml
    ├── files
    ├── handlers
    ├── meta
    │   └── main.yml
    ├── tasks
    │   └── main.yml
    └── templates
        └── motd.j2

README.md提供人类可读的基本角色描述、有关如何使用该角色的文档和示例，以及其发挥作用所需要满足的任何非Ansible要求。
meta子目录包含一个main.yml文件，该文件指定有关模块的作者、许可证、兼容性和依赖项的信息。
files子目录包含固定内容的文件，而templates子目录则包含使用时可由角色部署的模板。
其他子目录中可以包含main.yml文件，它们定义默认的变量值、处理程序、任务、角色元数据或变量，具体取决于所处的子目录。
如果某一子目录存在但为空，如本例中的handlers，它将被忽略。如果某一角色不使用功能，则其子目录可以完全省略。例如，本例中的vars子目录已被省略。

3.2 创建角色框架

可以使用标准Linux命令创建新角色所需的所有子目录和文件。此外，也可以通过命令行实用程序来自动执行新角色创建过程。

ansible-galaxy命令行工具可用于管理Ansible角色，包括新角色的创建。用户可以运行ansible-galaxy init来创建新角色的目录结构。指定角色的名称作为命令的参数，该命令在当前工作目录中为新角色创建子目录。

[root@king playbook]# mkdir roles
[root@king playbook]# ls
roles
[root@king playbook]# touch play.yml
[root@king playbook]# ll
total 0
-rw-r--r-- 1 root root 0 Dec  2 16:28 play.yml
drwxr-xr-x 2 root root 6 Dec  2 16:27 roles
[root@king playbook]# cd roles/
[root@king roles]# ansible-galaxy init httpd   //创建新角色httpd
- Role httpd was created successfully
[root@king roles]# ls
httpd
[root@king roles]# cd httpd/
[root@king httpd]# tree
.
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

8 directories, 8 files

3.3 定义角色内容

创建目录结构后，用户必须编写角色的内容。ROLENAME/tasks/main.yml任务文件是一个不错的起点，它是由角色运行的主要任务列表。

[root@king httpd]# tree
.
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
│   └── httpd.conf.j2
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

8 directories, 9 files
[root@king httpd]# cat tasks/main.yml 
---
# tasks file for httpd

- name: install httpd
  yum:
    name: httpd
    state: present

- name: config httpd
  template:
    src: ../templates/httpd.conf.j2
    dest: /etc/httpd/conf/httpd.conf

  notify:
    - restart httpd

- name: httpd service
  service:
    name: httpd
    state: restarted
[root@king httpd]# cat handlers/main.yml 
---
# handlers file for httpd

- name: restart httpd
  service:
    name: httpd
    state: restarted
[root@king playbook]# ls
play.yml  roles
[root@king playbook]# vim play.yml 
[root@king playbook]# ansible-playbook --syntax-check play.yml 

playbook: play.yml
[root@king playbook]# cat play.yml 
---
- hosts: test1
  roles:
    - role: roles/httpd

4 使用ansible galaxy部署角色

4.1 介绍ansible galaxy

Ansible Galaxy [https://galaxy.ansible.com]是一个Ansible内容公共资源库，这些内容由许许多多Ansible管理员和用户编写。它包含数千个Ansible角色，具有可搜索的数据库，可帮助Ansible用户确定或许有助于他们完成管理任务的角色。Ansible Galaxy含有面向新的Ansible用户和角色开发人员的文档和视频链接。
此外，用于从Ansible Galaxy获取和管理角色的ansible-galaxy命令也可用于为您的项目获取和管理自有的git存储库中的角色。

4.2 Ansible Galaxy命令行工具

4.2.1 从命令行搜索角色

ansible-galaxy search子命令在Ansible Galaxy中搜索角色。如果以参数形式指定了字符串，则可用于按照关键字在Ansible Galaxy中搜索角色。用户可以使用–author、–platforms和–galaxy-tags选项来缩小搜索结果的范围。也可以将这些选项用作主要的搜索键。例如，命令ansible-galaxy search --author geerlingguy将显示由用户geerlingguy提交的所有角色。[EL:指的是企业版的Linux，企业版Linux一般指Redhat操作系统]

# 搜索跟httpd相关的角色包
[root@king playbook]# ansible-galaxy search httpd 

Found 341 roles matching your search:
......

# 搜索作者是robertdebock用户下httpd角色包
[root@king playbook]# ansible-galaxy search 'httpd' --author robertdebock

Found 14 roles matching your search:
.....

ansible-galaxy info子命令显示与角色相关的更多详细信息。Ansible Galaxy从多个位置获取这一信息，包括角色的meta/main.yml文件及其GigHub存储库。以下命令显示了Ansible Galaxy提供的robertdebock.backup角色的相关信息。

# 显示作者robertdebock所写的backup角色包的详细信息
[root@king playbook]# ansible-galaxy info robertdebock.backup

Role: robertdebock.backup
        description: The purpose of this role is to make backups of your system.
        active: True
        commit: 139ee7a58687b732796537f09442a095e8cb8eac
        commit_message: Test against Fedora 34, 35 (latest) and 36/rawhide.
        commit_url: https://api.github.com/repos/robertdebock/ansible-role-backup/git/commits>
        company: none
        created: 2018-09-19T20:03:37.768578Z
        download_count: 8363
        forks_count: 0
        github_branch: master
        github_repo: ansible-role-backup
        github_user: robertdebock
        id: 29899
(END).............

# 显示包含redis并且适用于企业Linux(EL)平台的角色的名称
[root@king playbook]# ansible-galaxy search 'redis' --platforms EL

Found 239 roles matching your search:
.....

4.2.2 从Ansible Galaxy安装角色

ansible-galaxy install子命令从Ansible Galaxy下载角色，并将它安装到控制节点本地。

默认情况下，角色安装到用户的roles_path下的第一个可写目录中。根据为Ansible设置的默认roles_path，角色通常将安装到用户的~/.ansible/roles目录。默认的roles_path可能会被用户当前Ansible配置文件或环境变量ANSIBLE_ROLES_PATH覆盖，这将影响ansible-galaxy的行为。

用户可以通过使用**-p** 选项，指定具体的目录来安装角色。

[root@king ~]# ansible-galaxy install robertdebock.backup -p playbook/roles/
- downloading role 'backup', owned by robertdebock
- downloading role from https://github.com/robertdebock/ansible-role-backup/archive/3.1.1.tar.gz
- extracting robertdebock.httpd to /root/playbook.roles/robertdebock.backup
- robertdebock.backup(7.2.0) was  installed successfully.

4.2.3 使用要求文件安装角色

可以使用ansible-galaxy，根据某一文本文件中的定义来安装一个角色列表。例如，如果用户的一个playbook需要安装特定的角色，可以在项目目录中创建一个roles/requirements.yml文件来指定所需的角色。此文件充当playbook项目的依赖项清单，使得playbook的开发和调试能与任何支持角色分开进行。
例如，一个用于安装geerlingguy.redis的简单requirements.yml可能类似于如下：

- src: geerlingguy.redis
  version: "1.5.0"

src属性指定角色的来源，本例中为来自Ansible Galaxy的geerlingguy.redis角色。version属性是可选的，指定要安装的角色版本，本例中为1.5.0。
重要:
应当在requirements.yml文件中指定角色版本，特别是生产环境中的playbook。
如果不指定版本，将会获取角色的最新版本。如果作者对角色做出了更改，并与用户的playbook不兼容，这可能会造成自动化失败或其他问题。

若要使用与playbook相关角色文件来安装角色，可使用**-r** roles/requirements.yml文件中角色选项：

ansible-galaxy install -r roles/requirements.yml -p playbook/roles/

4.2.4 管理下载的角色

ansible-galaxy命令也可管理本地的角色，如位于playbook项目的roles目录中的角色。ansible-galaxy list子命令列出本地找到的角色。

[root@king ~]# ansible-galaxy list
# /usr/share/ansible/roles
- linux-system-roles.certificate, (unknown version)
- linux-system-roles.crypto_policies, (unknown version)
........

可以使用ansible-galaxy remove子命令本地删除角色:

[root@king ~]# ansible-galaxy remove /usr/share/ansible/roles/rhel-system-roles.tlog
- successfully removed /usr/share/ansible/roles/rhel-system-roles.tlog
[root@king ~]# ansible-galaxy list //查看是否移除角色

查看ansible-galaxy相关的帮助选项：

[root@king ~]# ansible-galaxy --help
usage: ansible-galaxy [-h] [--version] [-v] TYPE ...

Perform various Role and Collection related operations.

positional arguments:
  TYPE
    collection   Manage an Ansible Galaxy collection.
    role         Manage an Ansible Galaxy role.

optional arguments:
  --version      show program's version number, config file location,
                 configured module search path, module location, executable
                 location and exit
  -h, --help     show this help message and exit
  -v, --verbose  verbose mode (-vvv for more, -vvvv to enable connection
                 debugging)

# 查看ansible-galaxy后跟类型帮助选项：
[root@king ~]# ansible-galaxy role --help
usage: ansible-galaxy role [-h] ROLE_ACTION ...

positional arguments:
  ROLE_ACTION
    init       Initialize new role with the base structure of a role.
    remove     Delete roles from roles_path.
    delete     Removes the role from Galaxy. It does not remove or alter the
               actual GitHub repository.
    list       Show the name and version of each role installed in the
               roles_path.
    search     Search the Galaxy database by tags, platforms, author and
               multiple keywords.
    import     Import a role
    setup      Manage the integration between Galaxy and the given source.
    info       View more details about a specific role.
    install    Install role(s) from file(s), URL(s) or Ansible Galaxy

optional arguments:
  -h, --help   show this help message and exit

[root@king ~]# ansible-galaxy collection --help  //集合collection
usage: ansible-galaxy collection [-h] COLLECTION_ACTION ...

positional arguments:
  COLLECTION_ACTION
    init             Initialize new collection with the base structure of a
                     collection.
    build            Build an Ansible collection artifact that can be publish
                     to Ansible Galaxy.
    publish          Publish a collection artifact to Ansible Galaxy.
    install          Install collection(s) from file(s), URL(s) or Ansible
                     Galaxy

optional arguments:
  -h, --help         show this help message and exit