1. 角色的结构
1.1 利用角色构造ansible playbook
ansible角色提供了一种方法,让用户能以通用的方式更加轻松地重复利用ansible代码
我们可以在标准化目录结构中打包所有任务、变量、 文件、模板,以及调配基础架构或部署应用所需的其他资源,只需通过复制相关的目录,将角色从一个项目复制到另一个项目。然后,只需从一个play调用该角色就能执行它
借助编写良好的角色,可以从playbook中向角色传递调整其行为的变量,设置所有站点相关的主机名、IP地址、用户名,或其他在本地需要的具体详细信息
ansible角色的优点:
- 角色可以分组内容,从而与他人轻松共享代码
- 可以编写角色来定义系统类型的基本要素:web服务器、数据库服务器、git存储库,或满足其他通途
- 角色使得较大型项目更容易管理
- 角色可以由不同的管理员并行开发
除了自行编写、使用、重用和共享角色外,还可以从其他来源获取角色。一些角色已包含在rhel-system-roles软件包中,用户也可以从Ansible Galaxy网站获取由社区提供支持的许多角色
使用rhel-system-roles软件包使用角色
//在控制节点上查看本地的角色
[root@localhost ~]# ls /usr/share/ansible/roles/
//安装rhel-system-roles
[root@localhost ~]# yum list | grep rhel-system-roles
rhel-system-roles.noarch 1.0-9.el8 appstream
[root@localhost ~]# yum install -y rhel-system-roles
//在次查看本地的角色
[root@localhost ~]# ls /usr/share/ansible/roles/
linux-system-roles.kdump linux-system-roles.postfix linux-system-roles.storage rhel-system-roles.kdump rhel-system-roles.postfix rhel-system-roles.storage
linux-system-roles.network linux-system-roles.selinux linux-system-roles.timesync rhel-system-roles.network rhel-system-roles.selinux rhel-system-roles.timesync
从Ansible Galaxy网站获取由社区提供支持的许多角色,请访问:https://galaxy.ansible.com/
1.2 Ansible角色结构
Ansible角色由子目录和文件的标准化结构定义。顶级目录定义角色本身的名称。文件整理到子目录中,子目录按照各个文件在角色中的用途进行命名,如tasks和handlers。files和templates子目录中包含由其他YAML文件中的任务引用的文件。
子目录 | 功能 |
---|---|
defaults | 此目录中的main.yml文件包含角色变量的默认值,使用角色时可以覆盖这些默认值。这些变量的优先级较低,应该可以在play中更改和自定义 |
files | 此目录包含由角色任务引用的静态文件 |
handlers | 此目录中的main.yml文件包含角色的处理程序定义 |
meta | 此目录中的main.yml文件包含与角色相关的信息,如作者、许可证、平台和可选的角色依赖项 |
tasks | 此目录中的main.yml文件包含角色的任务定义 |
templates | 此目录包含由角色任务引用的Jinja2模板 |
tests | 此目录可以包含清单和名为test.yml的playbook,可用于测试角色 |
vars | 此目录中的main.yml文件定义角色的变量值。这些变量通常用于角色内部用途。这些变量的优先级较高,在playbook中使用时不应更改 |
注意:并非每个角色都拥有这些目录
1.3 定义变量和默认值
1. 定义变量
角色变量通过在角色目录层次结构中创建含有键值对的vars/main.yml文件来定义(键值对:key = value)。这些角色变量在角色yaml文件中引用{{ VAR_NAME }},这些变量具有较高的优先级,无法被清单变量覆盖
2. 定义默认值
角色变量通过在角色目录层次结构中创建含有键值对的vars/main.yml文件来定义。与其他变量一样,这些角色变量在角色YAML文件中引用:{{ VAR_NAME }}。这些变量具有较高的优先级,无法被清单变量覆盖。这些变量旨在供角色的内部功能使用。
默认变量允许为可在play中使用的变量设置默认值,以配置角色或自定义其行为。它们通过在角色目录层次结构中创建含有键值对的defaults/main.yml文件来定义。默认变量具有任何可用变量中最低的优先级。它们很容易被包括清单变量在内的任何其他变量覆盖。这些变量旨在让用户在编写使用该角色的play时可以准确地自定义或控制它将要执行的操作。它们可用于向角色提供所需的信息,以正确地配置或部署某些对象。
在vars/main.yml或defaults/main.yml中定义具体的变量,但不要在两者中都定义。有意要覆盖变量的值时,应使用默认变量。
注意
角色不应该包含特定于站点的数据。它们绝对不应包含任何机密,如密码或私钥
这是因为角色应该是通用的,可以重复利用并自由共享。特定于站点的详细信息不应硬编码到角色中
机密应当通过其他途径提供给角色。这是用户可能要在调用角色时设置角色变量的一个原因
play中设置的角色变量可以提供机密,或指向含有该机密的Ansible Vault加密文件
1.4 在playbook中使用ansible角色
在playbook中简单调用ansible角色
---
- host: all
roles:
- role_one
- role_two
- role_three
对于每个指定的角色,角色任务、角色处理程序、角色变量和角色依赖项将按照顺序导入到playbook中
角色中的任何copy、script、template或include_tasks/import_tasks任务都可引用角色中相关的文件、模板或任务文件,且无需相对或绝对路径名称
Ansible将分别在角色的files、templates或tasks子目录中寻找它们
重要:
内嵌设置的角色变量具有非常高的优先级。它们将覆盖大多数其他变量
不要重复使用内嵌设置在play中任何其他位置的任何角色变量的名称,因为角色变量的值将覆盖清单变量和任何play中的vars
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中通常不会同时包含所有这些部分。
---
- hosts: 192.168.101.210
tasks:
block:
- include_role:
name: selinux
rescue:
- name: Check for failure for other reasons than required reboot
fail:
when: not selinux_reboot_required
- name: Restart managed host
reboot:
- name: Reapply SELinux role to complete changes
include_role:
name: selinux
vars:
power: true
pre_tasks:
- debug:
msg: 'pre-tasks'
changed_when: power
notify: my handler
roles:
- selinux
tasks:
- debug:
msg: 'first tasks'
changed_when: power
notify: my handler
post_tasks:
- debug:
msg: 'post-tasks'
changed_when: power
notify: my handler
handlers:
- name: my handler
debug:
msg: Running my handler
在上例中,每个部分中都执行debug任务来通知my handler处理程序。my handler任务执行了三次:
- 在执行了所有pre_tasks任务后
- 在执行了所有角色任务和tasks部分中的任务后
- 在执行了所有post_tasks后
除了将角色包含在play的roles部分中外,也可以使用普通任务将角色添加到play中。使用include_role模块可以动态包含角色,使用import_role模块则可静态导入角色。
以下playbook演示了如何通过include_role模块来利用任务包含角色。
---
- hosts: 192.168.101.210
tasks:
- debug:
msg: 'first tasks'
- name: selinux
include_role:
name: selinux
2. 系统角色的使用
2.1 timesync的使用
假设需要在服务器上配置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角色将受管主机配置为利用快速初始同步从三个NTP服务器获取时间。此外,还添加了一个任务,以使用timezone模块将主机的时区设为UTC。
- name: shijiantongbu
hosts: all
vars:
timesync_ntp_servers:
- hostname: 0.rhel.pool.ntp.org
iburst: yes
timezone: UTC
roles:
- timesync
tasks:
- name: Set timezone
timezone:
name: "{{ timezone }}"
注意
如果要设置不同的时区,可以使用tzselect命令查询其他有效的值。也可以使用timedatectl命令来检查当前的时钟设置。
2.2 SELINUX的使用
rhel-system-roles.selinux角色可以简化SELinux配置设置的管理。它通过利用SELinux相关的Ansible模块来实施。与自行编写任务相比,使用此角色的优势是它能让用户摆脱编写这些任务的职责。取而代之,用户将为角色提供变量以对其进行配置,且角色中维护的代码将确保应用用户需要的SELinux配置。
此角色可以执行的任务包括:
- 设置enforcing或permissive模式
- 对文件系统层次结构的各部分运行restorecon
- 设置SELinux布尔值
- 永久设置SELinux文件上下文
- 设置SELinux用户映射
有时候,SELinux角色必须确保重新引导受管主机,以便能够完整应用其更改。但是,它本身从不会重新引导主机。如此一来,用户便可以控制重新引导的处理方式。
其工作方式为,该角色将一个布尔值变量selinux_reboot_required设为True,如果需要重新引导,则失败。你可以使用block/rescure结构来从失败中恢复,具体操作为:如果该变量未设为true,则让play失败,如果值是true,则重新引导受管主机并重新运行该角色。Play中的块看起来应该类似于:
---
- hosts: 192.168.101.210
tasks:
- name: Apply SELinux role
block:
- include_role:
name: selinux
rescue:
- name: Check for failure for other reasons than required reboot
fail:
when: not selinux_reboot_required
- name: Restart managed host
reboot:
- name: Reapply SELinux role to complete changes
include_role:
name: selinux
用于配置rhel-system-roles.selinux角色的变量的详细记录位于其README.md文件中。以下示例演示了使用此角色的一些方法
selinux_state变量设置SELinux的运行模式。它可以设为enforceing、permissive或disabled。如果为设置,则不更改模式。
vars:
selinux_state: enforcing
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_restore_dirs变量指定要对其运行restorecon的目录的列表:
selinux_restore_dirs:
- /srv/www
selinux_ports变量取应当具有特定SELinux类型的端口的列表作为值。
selinux_ports:
- ports: '82'
setype: 'http_port_t'
proto: 'tcp'
state: 'present'
.*)?'
setype: 'httpd_sys_content_t'
state: 'present'
selinux_restore_dirs变量指定要对其运行restorecon的目录的列表:
selinux_restore_dirs:
- /srv/www
selinux_ports变量取应当具有特定SELinux类型的端口的列表作为值。
---
- hosts: 192.168.101.210
tasks:
block:
- include_role:
name: selinux
rescue:
- name: Check for failure for other reasons than required reboot
fail:
when: not selinux_reboot_required
- name: Restart managed host
reboot:
- name: Reapply SELinux role to complete changes
include_role:
name: selinux
vars:
port: 82
selinux_state: enforcing
selinux_ports:
- ports: '82'
setype: 'http_port_t'
proto: 'tcp'
state: 'present'
tasks:
- name: config httpd
template:
src: /etc/ansible/files/httpd.j2
dest: /etc/httpd/conf/httpd.conf
- name: selinux role
include_role:
name: selinux
- name: service httpd
service:
name: httpd
state: restarted
enabled: yes
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命令创建新角色所需的所有子目录和文件。此外,也可以通过命令行实用程序来自动执行新角色创建过程。
3.2.1 使用Galaxy创建角色框架
ansible-galaxy命令行工具可用于管理Ansible角色,包括新角色的创建。用户可以运行ansible-galaxy init来创建新角色的目录结构。指定角色的名称作为命令的参数,该命令在当前工作目录中为新角色创建子目录。
[root@localhost roles]# ansible-galaxy init httpd
- Role httpd was created successfully
[root@localhost roles]# tree httpd/
httpd/
├── 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.2.2 使用mkdir创建角色框架
[root@localhost roles]# mkdir jtluo/{defaults,files,handlers,meta,tasks,templates,tests,vars} -p
[root@localhost roles]# ls jtluo/
defaults files handlers meta tasks templates tests vars
[root@localhost roles]# tree jtluo
jtluo
├── defaults
├── files
├── handlers
├── meta
├── tasks
├── templates
├── tests
└── vars
8 directories, 0 file
3.3 定义角色内容
创建目录结构后,用户必须编写角色的内容。tasks/main.yml任务文件是一个不错的起点,它是由角色运行的主要任务列表。
下列tasks/main.yml文件管理受管主机上的/etc/httpd/conf/httpd.conf文件。它使用template模块将名为configure.j2的模板部署到受管主机上。因为template模块是在角色任务而非playbook任务内配置的,所以从角色的templates子目录检索configuer.j2模板
[root@localhost tasks]# cat main.yml
---
# tasks file for httpd #关闭防火墙
- name: stop firewalld
service:
name: firewalld.service
state: stopped
enabled: no
- name: Temporary stop selinux #临时关闭selinux
shell: setenforce 0
- name: install package #下载依赖包
yum:
name: "{{ item }}"
state: present
loop:
"{{ packages }}"
- name: decompression apr-1.7.0.tar.gz #将压缩包解压到受管主机
unarchive:
src: apr-1.7.0.tar.gz
dest: /opt/
- name: decompression apr-util-1.6.1.tar.gz
unarchive:
src: apr-util-1.6.1.tar.gz
dest: /opt/
- name: decompression httpd-2.4.48.tar.gz
unarchive:
src: httpd-2.4.48.tar.gz
dest: /opt/
- name: lineinfile #修改配置文件
lineinfile:
path: /opt/apr-1.7.0/configure
line: $RM "$cfgfile"
state: absent
- name: Compile and install apr-1.7.0.tar.gz #编译安装
shell: cd /opt/apr-1.7.0 && ./configure --prefix=/usr/local/apr && make && make install
- name: compile and install apr-util-1.6.1
shell: cd /opt/apr-util-1.6.1 && ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr && make && make install
- name: complie an install httpd-2.4.48
shell: cd /opt/httpd-2.4.48 && ./configure --prefix=/usr/local/httpd --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-util/ && make && make install
- name: start apachectl
shell: /usr/local/httpd/bin/apachectl start
[root@localhost roles]# tree httpd #查看角色结构
httpd
├── configure
├── defaults
│ └── main.yml
├── files
│ ├── apr-1.7.0.tar.gz
│ ├── apr-util-1.6.1.tar.gz
│ └── httpd-2.4.48.tar.gz
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── README.md
├── tasks
│ └── main.yml
├── templates
│ └── configure.j2
├── tests
│ ├── inventory
│ └── test.yml
└── vars
└── main.yml
3.4 角色内容开发的推荐做法
角色允许以模块化方式编写playbook。为了最大限度地提高新开发角色的效率,请考虑在角色开发中采用以下推荐做法:
- 在角色自己的版本控制存储库中维护每个角色。Ansible很适合使用基于git的存储库。
- 角色存储库中不应存储敏感信息,如密码或SSH密钥。敏感值应以变量的形式进行参数化,-其默认值应不敏感。使用角色的playbook负责通过Ansible Vault变量文件、环境变量或其他ansible-playbook选项定义敏感变量。
- 使用ansible-galaxy init启动角色,然后删除不需要的任何目录和文件。
- 创建并维护README.md和meta/main.yml文件,以记录用户的角色的用途、作者和用法。
- 让角色侧重于特定的用途或功能。可以编写多个角色,而不是让一个角色承担许多任务。
- 经常重用和重构角色。避免为边缘配置创建新的角色。如果现有角色能够完成大部分的所需配置,请重构现有角色以集成新的配置方案。使用集成和回归测试技术来确保角色提供所需的新功能,并且不对现有的playbook造成问题。
3.5 定义角色依赖项
角色依赖项使得角色可以将其他角色作为依赖项包含在内。例如,一个定义文档服务器的角色可能依赖于另一个安装和配置web服务器的角色。依赖关系在角色目录层次结构中的meta/main.yml文件内定义。
[root@localhost httpd]# cat meta/main.yml
galaxy_info:
author: your name
description: your role description
company: your company (optional)
# If the issue tracker for your role is not on github, uncomment the
# next line and provide a value
# issue_tracker_url: http://example.com/issue/tracker
# Choose a valid license ID from https://spdx.org - some suggested licenses:
# - BSD-3-Clause (default)
# - MIT
# - GPL-2.0-or-later
# - GPL-3.0-only
# - Apache-2.0
# - CC-BY-4.0
license: license (GPL-2.0-or-later, MIT, etc)
min_ansible_version: 2.9
# If this a Container Enabled role, provide the minimum Ansible Container version.
# min_ansible_container_version:
#
# Provide a list of supported platforms, and for each platform a list of versions.
# If you don't wish to enumerate all versions for a particular platform, use 'all'.
# To view available platforms and versions (or releases), visit:
# https://galaxy.ansible.com/api/v1/platforms/
#
# platforms:
# - name: Fedora
# versions:
# - all
# - 25
# - name: SomePlatform
# versions:
# - all
# - 1.0
# - 7
# - 99.99
galaxy_tags: []
# List tags for your role here, one per line. A tag is a keyword that describes
# and categorizes the role. Users find roles by searching for tags. Be sure to
# remove the '[]' above, if you add tags to this list.
#
# NOTE: A tag is limited to a single word comprised of alphanumeric characters.
# Maximum 20 tags per role.
dependencies: []
# List your role dependencies here, one per line. Be sure to remove the '[]' above,
# if you add dependencies to this list.
默认情况下,角色仅作为依赖项添加到playbook中一次。若有其他角色也将它作为依赖项列出,它不会再次运行。此行为可以被覆盖,将meta/main.yml文件中的allow_duplicates变量设置为yes即可。
限制角色对其他角色的依赖。依赖项使得维护角色变得更加困难,尤其是当它具有许多复杂的依赖项时
3.6 在playbook中使用角色
要访问角色,可在play的roles:部分引用它。下列playbook引用了httpd角色。由于没有指定变量,因此将使用默认变量值应用该角色。
执行该playbook时,因为角色而执行的任务可以通过角色名称前缀来加以识别。
[root@localhost ansible]# cat playbook/httpd.yml #在playbook中使用角色
---
- name:
hosts: 192.168.101.120
roles:
- httpd
[root@localhost ansible]# ansible-playbook playbook/httpd.yml #执行角色
3.7 通过变量更改角色的行为
编写良好的角色利用默认变量来改变角色行为,使之与相关的配置场景相符。这有助于让角色变得更为通用,可在各种不同的上下文中重复利用。
如果通过以下方式定义了相同的变量,则角色的defaults目录中定义的变量的值将被覆盖:
- 在清单文件中定义,作为主机变量或组变量
- 在playbook项目的group_vars或host_vars目录下的YAML文件中定义
- 作为变量嵌套在play的vars关键字中定义
- 在play的roles关键字中包含该角色时作为变量定义
3.8 角色优先级
角色 | 等级 |
---|---|
在playbook中内嵌角色 | 1 |
角色目录中的vars/main.yml中 | 2 |
playbook中vars定义的变量 | 3 |
主机变量、主机组变量 | 4 |
角色目录中的defaults/main.yml文件中定义 | 5 |
在play中使用角色变量时,变量的优先顺序可能会让人困惑。
-
几乎任何其他变量都会覆盖角色的默认变量,如清单变量、play、vars变量,以及内嵌的角色参数等
-
较少的变量可以覆盖角色的vars目录中定义的变量。事实、通过include_vars加载的变量、注册的变量和角色参数是其中一些具备这种能力的变量。清单变量和playvars无此能力。这非常重要,因为它有助于避免用户的play意外改变角色的内部功能。
-
不过,正如上述示例中最后一个所示,作为角色参数内嵌声明的变量具有非常高的优先级。它们可以覆盖角色的vars目录中定义的变量。如果某一角色参数的名称与playvars或角色vars中设置的变量或者清单变量或playbook变量的名称相同,该角色参数将覆盖另一个变量。
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帮助
通过Ansible Galaxy网站主页上的Documenttaion标签,可以进入描述如何使用Ansible Galaxy的页面。其中包含了介绍如何从Ansible Galaxy下载和使用角色的内容。该页面也提供关于如何开发角色并上传到Ansible Galaxy的说明。
4.3 浏览Ansible Galaxy中的角色
通过Ansible Galaxy网站主页上左侧的Search标签,用户可以访问关于Ansible Galaxy上发布的角色的信息。用户可以使用标记通过角色的名称或通过其他角色属性来搜索Ansible角色。结果按照Best Match分数降序排列,此分数依据角色质量、角色受欢迎程度和搜索条件计算而得。
4.4 Ansible Galaxy命令行工具
4.4.1 从命令行搜索角色
ansible-galaxy search子命令在Ansible Galaxy中搜索角色。如果以参数形式指定了字符串,则可用于按照关键字在Ansible Galaxy中搜索角色。用户可以使用–author、–platforms和–galaxy-tags选项来缩小搜索结果的范围。也可以将这些选项用作主要的搜索键。例如,命令ansible-galaxy search --author robertdebock将显示由用户robertdebock提交的所有角色。
#显示了包含redis并且适用于企业Linux(EL)平台的角色的名称
[root@localhost ansible]# ansible-galaxy search 'redis' --platforms EL
Found 235 roles matching your search:
Name Description
---- -----------
0x0i.consul Consul - a service discovery, mesh and co>
0x0i.grafana Grafana - an analytics and monitoring obs>
0x5a17ed.ansible_role_netbox Installs and configures NetBox, a DCIM su>
1it.sudo Ansible role for managing sudoers
adfinis-sygroup.redis Ansible role for Redis
AerisCloud.librato Install and configure the Librato Agent
AerisCloud.redis Installs redis on a server
AlbanAndrieu.java Manage Java installation
alikins.php_pecl PHP PECL extension installation.
alikins.php_redis PhpRedis support for Linux
ansible-galaxy info子命令显示与角色相关的更多详细信息。Ansible Galaxy从多个位置获取这一信息,包括角色的meta/main.yml文件及其GigHub存储库。
[root@localhost ansible]# ansible-galaxy role info robertdebock.httpd
Role: robertdebock.httpd
description: Install and configure httpd on your system.
active: True
commit: 9fc0e5c1f38873f26c1d896d7db1424b2e07181b
commit_message: 404 is also good.
commit_url: https://api.github.com/repos/robertdebock/ansible-role-httpd/git/commi>
company: none
created: 2017-11-10T16:04:25.981866Z
download_count: 141065
forks_count: 11
github_branch: master
github_repo: ansible-role-httpd
github_user: robertdebock
id: 21855
imported: 2021-08-02T02:10:26.984862-04:00
is_valid: True
issue_tracker_url: https://github.com/robertdebock/ansible-role-httpd/issues
license: Apache-2.0
min_ansible_version: 2.10
modified: 2021-08-02T06:10:26.994045Z
open_issues_count: 1
path: ('/root/.ansible/roles', '/usr/share/ansible/roles', '/etc/ansible/roles')
role_type: ANS
stargazers_count: 6
travis_status_url:
4.5 从Ansible Galaxy安装角色
ansible-galaxy install子命令从Ansible Galaxy下载角色,并将它安装到控制节点本地。
默认情况下,角色安装到用户的roles_path下的第一个可写目录中。根据为Ansible设置的默认roles_path,角色通常将安装到用户的~/.ansible/roles目录。默认的roles_path可能会被用户当前Ansible配置文件或环境变量ANSIBLE_ROLES_PATH覆盖,这将影响ansible-galaxy的行为。
用户可以通过使用-p DIRECTORY选项,指定具体的目录来安装角色。
#ansible-galaxy安装角色robertdebock.httpd
#ansible galaxy 默认安装位置
[root@localhost ansible]# ansible-galaxy role install robertdebock.httpd
- downloading role 'httpd', owned by robertdebock
- downloading role from https://github.com/robertdebock/ansible-role-httpd/archive/7.0.0.tar.gz
- extracting robertdebock.httpd to /root/.ansible/roles/robertdebock.httpd
- robertdebock.httpd (7.0.0) was installed successfully
[root@localhost ansible]# cd /root/.ansible/roles/
[root@localhost roles]# ls
robertdebock.httpd
#指定安装位置
[root@localhost ansible]# ansible-galaxy role install robertdebock.httpd -p /etc/ansible/playbook/roles/
- downloading role 'httpd', owned by robertdebock
- downloading role from https://github.com/robertdebock/ansible-role-httpd/archive/7.0.0.tar.gz
- extracting robertdebock.httpd to /etc/ansible/playbook/roles/robertdebock.httpd
- robertdebock.httpd (7.0.0) was installed successfully
[root@localhost ansible]# cd playbook/roles/
[root@localhost roles]# ls
httpd httpd.tar.gz robertdebock.httpd
4.6 使用要求文件安装角色
可以使用ansible-galaxy,根据某一文本文件中的定义来安装一个角色列表。例如,如果用户的一个playbook需要安装特定的角色,可以在项目目录中创建一个roles/requirements.yml文件来指定所需的角色。此文件充当playbook项目的依赖项清单,使得playbook的开发和调试能与任何支持角色分开进行。
重要
应当在requirements.yml文件中指定角色版本,特别是生产环境中的playbook。
如果不指定版本,将会获取角色的最新版本。如果作者对角色做出了更改,并与用户的playbook不兼容,这可能会造成自动化失败或其他问题。
src属性指定角色的来源,本例中为来自Ansible Galaxy的robertdebock.httpd角色。version属性是可选的,指定要安装的角色版本,本例中为7.0.0。
[root@localhost roles]# cat robertdebock.yml #使用文件安装robertdebock.httpd
- src: robertdebock.httpd
version: "7.0.0"
[root@localhost roles]# ansible-galaxy role install -r robertdebock.yml
- downloading role 'httpd', owned by robertdebock
- downloading role from https://github.com/robertdebock/ansible-role-httpd/archive/7.0.0.tar.gz
- extracting robertdebock.httpd to /root/.ansible/roles/robertdebock.httpd
- robertdebock.httpd (7.0.0) was installed successfully
[root@localhost roles]# ls
httpd httpd.tar.gz robertdebock.yml
重要
应当在requirements.yml文件中指定角色版本,特别是生产环境中的playbook。
如果不指定版本,将会获取角色的最新版本。如果作者对角色做出了更改,并与用户的playbook不兼容,这可能会造成自动化失败或其他问题。
若要使用角色文件来安装角色,可使用-r REQUIREMENTS-FILE选项:
ansible-galaxy install -r roles/requirements.yml -p roles
用户可以使用ansible-galaxy来安装不在Ansible Galaxy中的角色。可以在私有的Git存储库或Web服务器上托管自有的专用或内部角色。下例演示了如何利用各种远程来源配置要求文件。
[root@localhost project]# cat roles/requirements.yml
# from Ansible Galaxy, using the latest version
- src: geerlingguy.redis
# from Ansible Galaxy, overriding the name and using a specific version
- src: geerlingguy.redis
version: "1.5.0"
name: redis_prod
# from any Git-based repository, using HTTPS
- src: https://gitlab.com/guardianproject-ops/ansible-nginx-acme.git
scm: git
version: 56e00a54
name: nginx-acme
# from any Git-based repository, using SSH
- src: git@gitlab.com:guardianproject-ops/ansible-nginx-acme.git
scm: git
version: master
name: nginx-acme-ssh
# from a role tar ball, given a URL
# supports 'http', 'https', or 'file' protocols
- src: file:///opt/local/roles/myrole.tar
name: myrole
src关键字指定Ansible Galaxy角色名称。如果角色没有托管在Ansible Galaxy中,则src关键字将指明角色的URL。
如果角色托管在来源控制存储库中,则需要使用scm属性。ansible-galaxy命令能够从基于git或mercurial的软件存储库下载和安装角色。基于Git的存储库要求scm值为git,而托管在Mercurial存储库中的角色则要求值为hg。如果角色托管在Ansible Galaxy中,或者以tar存档形式托管在Web服务器上,则省略scm关键字。
name关键字用于覆盖角色的本地名称。version关键字用于指定角色的版本。version关键字可以是与来自角色的软件存储库的分支、标记或提交哈希对应的任何值。
4.7 管理下载的角色
ansible-galaxy命令也可管理本地的角色,如位于playbook项目的roles目录中的角色。ansible-galaxy list子命令列出本地找到的角色。
[root@localhost .ansible]# ansible-galaxy role list
# /root/.ansible/roles
- robertdebock.httpd, 7.0.0
# /usr/share/ansible/roles
- linux-system-roles.certificate, (unknown version)
- linux-system-roles.crypto_policies, (unknown version)
- linux-system-roles.ha_cluster, (unknown version)
- linux-system-roles.kdump, (unknown version)
- linux-system-roles.kernel_settings, (unknown version)
- linux-system-roles.logging, (unknown version)
- linux-system-roles.metrics, (unknown version)
- linux-system-roles.nbde_client, (unknown version)
- linux-system-roles.nbde_server, (unknown version)
- linux-system-roles.network, (unknown version)
·······略
- rhel-system-roles.timesync, (unknown version)
- rhel-system-roles.tlog, (unknown version)
- rhel-system-roles.vpn, (unknown version)
# /etc/ansible/roles
- timesync, (unknown version)
- selinux, (unknown version)
- lp66, (unknown version)
4.8 删除角色
使用ansible-galaxy remove子命令本地删除角色
[root@localhost .ansible]# ansible-galaxy remove robertdebock.httpd
- successfully removed robertdebock.httpd
[root@localhost .ansible]# ansible-galaxy role list |grep robertdebock.httpd #查看
[root@localhost .ansible]#
在playbook中使用下载并安装的角色的方式与任何其他角色都一样。在roles部分中利用其下载的角色名称来加以引用。如果角色不在项目的roles目录中,则将检查roles_path来查看角色是否安装在了其中一个目录中,将使用第一个匹配项。以下use-role.ymlplaybook引用了redis_prod和geerlingguy.redis角色:
[root@localhost project]# cat use-role.yml
---
- name: use redis_prod for prod machines
hosts: redis_prod_servers
remote_user: devops
become: True
roles:
- redis_prod
- name: use geerlingguy.redis for Dev machines
hosts: redis_dev_servers
remote_user: devops
become: True
roles:
- geerlingguy.redis
此playbook使不同版本的geerlingguy.redis角色应用到生产和开发服务器。借助这种方式可以对角色更改进行系统化测试和集成,然后再部署到生产服务器上。如果角色的近期更改造成了问题,则借助版本控制来开发角色,就能回滚到过去某一个稳定的角色版本。