ansible 管理大项目
一. 利用主机模式选择主机
1. 引用清单主机
-
主机模式用于指定要作为play或临时命令的目标的主机。在最简单的形式中,清单中受管主机或主机组的名称就是指定该主机或主机组的主机模式。
-
在play中,hosts指定要针对其运行play的受管主机。对于临时命令,以命令行参数形式将主机模式提供给ansible命令。
[root@localhost ~]# cat myinventory
web.example.com
data.example.com
[lab]
labhost1.example.com
labhost2.example.com
[test]
test1.example.com
test2.example.com
[datacenter1]
labhost1.example.com
test1.example.com
[datacenter2]
labhost2.example.com
test2.example.com
[datacenter:children]
datacenter1
datacenter2
[new]
172.16.103.129
172.16.103.130
2. 受管主机
-
最基本的主机模式是单一受管主机名称列在清单中。这将指定该主机是清单中ansible命令要执行操作的唯一主机。
-
在该playbook运行时,第一个Gathering Facts任务应在与主机模式匹配的所有受管主机上运行。此任务期间的故障可能导致受管主机从play中移除。
[root@129a httpd]# ansible-playbook tests.yml
PLAY [all] *********************************************************************
TASK [Gathering Facts] *********************************************************
ok: [130h]
TASK [update] ******************************************************************
changed: [130h]
PLAY RECAP *********************************************************************
130h : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
[root@129a httpd]#
-
可以通过设置ansible_host主机变量,在清单中将某一别名指向特定的IP地址。例如,你的清单中可以有一个名为dummy.example的主机,然后通过创建含有以下主机变量的host_vars/dummy.example文件,将使用该名称的连接指向IP地址172.16.103.129:
ansible_host: 172.16.103.129
3. 使用组指定主机
-
当组名称用作主机模式时,它指定Ansible将对属于该组的成员的主机执行操作。
-
有一个名为all的特别组,它匹配清单中的所有受管主机
-
还有一个名为ungrouped的特别组,它包括清单中不属于任何其他组的所有受管主机:
---
- hosts: lab
---
- hosts: all
---
- hosts: ungrouped
4. 使用通配符匹配多个主机
- 若要达成与all主机模式相同的目标,另一种方法是使用
*
通配符,它将匹配任意字符串。如果主机模式只是带引号的星号,则清单中的所有主机都将匹配。
---
- hosts: '*'
所有主机
---
- hosts: '!test1.example.com,development'
除了test1.example.com以外的主机,
---
- hosts: '*.example.com'
---
- hosts: '192.168.2.*'
---
- hosts: 'datacenter*'
---
- hosts: 'data*'
5. 列表
-
可以通过逻辑列表来引用清单中的多个条目。主机模式的逗号分隔列表匹配符合任何这些主机模式的所有主机
-
提供受管主机的逗号分隔列表
-
提供受管主机的逗号分隔列表
-
混合使用受管主机、主机组和通配符
---
- hosts: labhost1.example.com,test2.example.com,192.168.2.2
---
- hosts: lab,datacenter1
---
- hosts: 'lab,datacenter*,192.168.2.2'
特殊字符用引号引起来
- 也可以用冒号(:)取代逗号。不过,逗号是首选的分隔符,特别是将IPv6地址用作受管主机名称时。
- 如果列表中的某一项以与符号(&)开头,则主机必须与该项匹配才能匹配主机模式。它的工作方式类似于逻辑AND。
---
- hosts: lab,&datacenter1
也可以通过主机模式&lab,datacenter1或datacenter,&lab指定datacenter1组中的计算机只有在同时也属于lab组时才匹配。
---
- hosts: datacenter,!test2.example.com
// !test2.example.com,datacenter
通过在主机模式的前面使用感叹号(!)表示从列表中排除匹配某一模式的主机。它的工作方式类似于逻辑NOT。
---
- hosts: all,!datacenter1
使用匹配测试清单中的所有主机的主机模式,datacenter1组中的受管主机除外
二. 管理动态清单
1. 动态生成清单
-
Ansible支持动态清单脚本,这些脚本在每当Ansible执行时从这些类型的来源检索当前的信息,使清单能够实时得到更新。这些脚本是可以执行的程序,能够从一些外部来源收集信息,并以JSON格式输出清单。
-
动态清单脚本的使用方式与静态清单文本文件一样。清单的位置可以直接在当前的ansible.cfg文件中指定,或者通过**-i**选项指定。如果清单文件可以执行,则它将被视为动态清单程序,Ansible会尝试运行它来生成清单。如果文件不可执行,则它将被视为静态清单。
-
清单位置可以在ansible.cfg配置文件中通过inventory参数进行配置。默认情况下,它被配置为**/etc/ansible/hosts**。
2. 开源社区脚本
- 开源社区向Ansible项目贡献了大量现有的动态清单脚本。它们没有包含在ansible软件包中。这些脚本可从Ansible GigHub网站
3. 编写动态清单程序
-
如果使用的目录系统或基础架构没有动态清单脚本,我们可以编写自定义清单程序。可以使用任何编程语言编写自定义程序,但传递适当的选项时必须以JSON格式返回清单信息。
-
ansible-inventory命令是学习如何以JSON格式编写Ansible清单的有用工具。
-
要以JSON格式显示清单文件的内容,请运行ansible-inventory --list命令。可以使用**-i**选项指定要处理的清单文件的位置,或仅使用当前Ansible配置设置的默认清单。
[root@localhost ~]# cat inventory
workstation1.lab.example.com
[webservers]
web1.lab.example.com
web2.lab.example.com
[databases]
db1.lab.example.com
db2.lab.example.com
[root@localhost ~]# ansible-inventory -i inventory --list
-
要自己编写动态清单脚本,可以通过部署动态清单来源[https://docs.ansible.com/ansible/latest/dev_guide/developing_inventory.html]获得更详细的信息。
-
脚本以适当的解释器行(例如,#!/usr/bin/python)开头并且可以执行,以便Ansible能够运行它。
-
在最简单的形式中,组可以是一个受管主机列表。在这个清单脚本的JSON编码输出示例中,webservers是一个主机组,该组内含web1.lab.example.com和web2.lab.example.com受管主机。databases主机组的成员有db1.lab.example.com和db2.lab.example.com主机。
[root@localhost ~]# ./inventoryscript --list
{
"webservers": ["web1.lab.example.com","web2.lab.example.com"],
"databases": ["db1.lab.example.com","db2.lab.example.com"]
}
-
每个组的值可以是JSON散列/字典,含有由每一受管主机、任何子组和可能设置的任何组变量组成的列表
-
boston组具有两个子组(backup和ipa)、自己的三个受管主机,以及一个组变量集合(example_host: false)。
{
"webservers": [
"web1.lab.example.com",
"web2.lab.example.com"
],
"boston": {
"children": [
"backup",
"ipa"
],
"vars": {
"example_host": false
},
"hosts": [
"server1.demo.example.com",
"server2.demo.example.com",
"server3.demo.example.com",
]
},
"backup": [
"server4.demo.example.com"
],
"ipa": [
"server5.demo.example.com"
],
"_meta": {
"hostvars": {
"server5.demo.example.com": {
"ntpserver": "ntp.demo.example.com",
"dnsserver": "dns.demo.example.com"
}
}
}
}
- 该脚本也支持–host managed-host选项。此选项必须显示由与该主机关联的变量组成的JSON散列/字典,或者空白的JSON散列/字典。
[root@localhost ~]# ./inventoryscript --host server5.demo.example.com
{
"ntpserver": "ntp.demo.example.com",
"dnsserver": "dns.demo.example.com"
}
- 通过–host hostname选项调用时,该脚本必须显示指定主机的变量的JSON散列/字典。如果不提供任何变量,则可能显示空白的JSON散列或字典。
- 如果–list选项返回名为_meta的顶级元素,则可以在一次脚本调用中返回所有主机变量,从而提升脚本性能。此时,不会进行–host调用。
[root@localhost ~]# vim inventory.py
#!/usr/bin/env python
'''
Example custom dynamic inventory script for Ansible, in Python.
'''
import os
import sys
import argparse
try:
import json
except ImportError:
import simplejson as json
class ExampleInventory(object):
def __init__(self):
self.inventory = {}
self.read_cli_args()
# Called with `--list`.
if self.args.list:
self.inventory = self.example_inventory()
# Called with `--host [hostname]`.
elif self.args.host:
# Not implemented, since we return _meta info `--list`.
self.inventory = self.empty_inventory()
# If no groups or vars are present, return empty inventory.
else:
self.inventory = self.empty_inventory()
print json.dumps(self.inventory);
# Example inventory for testing.
def example_inventory(self):
return {
'group': {
'hosts': ['172.16.103.129', '172.16.103.130'],
'vars': {
'ansible_ssh_user': 'root',
'ansible_ssh_pass': '123456',
'example_variable': 'value'
}
},
'_meta': {
'hostvars': {
'172.16.103.129': {
'host_specific_var': 'foo'
},
'172.16.103.130': {
'host_specific_var': 'bar'
}
}
}
}
# Empty inventory for testing.
def empty_inventory(self):
return {'_meta': {'hostvars': {}}}
# Read the command line args passed to the script.
def read_cli_args(self):
parser = argparse.ArgumentParser()
parser.add_argument('--list', action = 'store_true')
parser.add_argument('--host', action = 'store')
self.args = parser.parse_args()
# Get the inventory.
ExampleInventory()
chmod +x inventory.py
./inventory.py --list
./inventory.py --host 172.16.103.129
ansible all -i inventory.py -m ping
ansible 172.16.103.129 -i inventory.py -m ping
4. 管理多个清单
-
Ansible支持在同一运行中使用多个清单。
-
如果清单的位置是一个目录(不论是由**-i选项设置的、是inventory**参数的值,还是以某种其他方式设置的),将组合该目录中包含的所有清单文件(不论是静态还是动态)来确定清单。该目录中的可执行文件将用于检索动态清单,其他文件则被用作静态清单。
-
清单文件不应依赖于其他清单文件或脚本来解析。例如,如果静态清单文件指定某一个组应当是另一个组的子级,则它也需要具有该组的占位符条目,即使该组的所有成员都来自动态清单。(主机和组必须在一个清单文件中)
[cloud-east]
[servers]
test.demo.example.com
[servers:children]
cloud-east
- 清单文件的解析顺序不是由文档指定的。目前,如果存在多个清单文件,它们会按照字母顺序进行解析。如果一个清单源依赖于另一个清单源的信息,则它们的加载顺序可能会确定清单文件是按预期工作还是引发错误。因此,务必要确保所有文件都自相一致,从而避免意外的错误。
- Ansible会忽略清单目录中以特定后缀结尾的文件。这可以通过在Ansible配置文件中的inventory_ignore_extensions指令来控制。
三. 配置并行
- 并行 — 多个任务同时运行
1. 使用分叉(fork,指定批次)在ansible中配置并行
-
当Ansible处理playbook时,会按顺序运行每个play。确定play的主机列表之后,Ansible将按顺序运行每个任务
-
所有主机必须在任何主机在play中启动下一个任务之前成功完成任务。
-
Ansible可以同时连接到play中的所有主机以执行每项任务
-
Ansible所进行的最大同时连接数由Ansible配置文件中的forks参数控制。默认情况下为5
[root@129a httpd]# cat ansible.cfg|grep forks
#forks = 5
[root@129a httpd]#
-
假设Ansible控制节点配置了5个forks的默认值,并且play具有10个受管主机,先将前五个主机把第一个任务运行,依次类推
-
forks的默认值设置得非常保守。如果你的控制节点正在管理Linux主机,则大多数任务将在受管主机上运行,并且控制节点的负载较少。可以将forks的值设置得更高,可能接近100,然后性能就会提高。
-
如果playbook在控制节点上运行很多代码,则应明智地提高forks限值。如果使用Ansible管理网络路由器和交换机,则大多数模块在控制节点上运行而不是在网络设备上运行。由于这会增加控制节点上的负载,因此其支持forks数量增加的能力将显著低于仅管理Linux主机的控制节点。
-
可以从命令行覆盖Ansible配置文件中forks的默认设置。ansible和ansible-playbook命令均提供-f或–forks选项以指定要使用的forks数量,(临时的)
2. 管理滚动更新(serial,指定同时运行多少台)
-
当Ansible运行play时,它会确保所有受管主机在启动任何主机进行下一个任务之前已完成每个任务。
-
在所有受管主机完成所有任务后,将运行任何通知的处理程序。
-
在所有主机上运行所有任务可能会导致意外行为。例如,如果play更新负载均衡Web服务器集群,则可能需要在进行更新时让每个Web服务器停止服务。如果所有服务器都在同一个play中更新,则它们可能全部同时停止服务。
-
避免此问题的一种方法是使用serial关键字,通过play批量运行主机。在下一批次启动之前,每批主机将在整个play中运行。
-
避免此问题的一种方法是使用 serial ( 顺序排列,将串行和并行结合使用)关键字,通过play批量运行主机。在下一批次启动之前,每批主机将在整个play中运行,批次运行。
-
第一批,将所有任务完成,在进行第二批的任务
-
示例:Ansible一次在两个受管主机上执行play,直至所有受管主机都已更新。Ansible首先在前两个受管主机上执行play中的任务。如果这两个主机中的任何一个或两个都通知了处理程序,则Ansible将根据这两个主机的需要运行处理程序。在这两个受管主机上执行完play时,Ansible会在接下来的两个受管主机上重复该过程。Ansible继续以这种方式运行play,直到所有受管主机都已更新。
---
- name: Rolling update
hosts: webservers//组
serial: 2//一批2台
tasks:
- name: latest apache httpd package is installed
yum:
name: httpd
state: latest
notify: restart apache
handlers:
- name: restart apache
service:
name: httpd
state: restarted
-
假设上一示例中的webservers组包含5个Web服务器,它们位于负载均衡器后面。将serial参数设置为2后,play一次将运行两台Web服务器。因此,5台Web服务器中的大多数服务器将始终可用。
-
相反,如果不使用serial关键字,将同时在5台Web服务器上执行play和生成的处理程序。这可能会导致服务中断,因为Web服务将在所有Web服务器上同时重新启动。
-
重要
-
出于某些目的,每批主机算作在主机子集上运行的完整play。这意味着,如果整个批处理失败,play就会失败,这将导致整个playbook运行失败。
-
在设置了serial: 2的上一个场景中,如果出现问题并且处理的前2个主机的play失败,则playbook将中止,其余3个主机将不会通过play运行。这是一个有用的功能,因为只有一部分服务器会不可用,使服务降级而不是中断。
-
serial关键字也可以指定为百分比。此百分比应用于play中的主机总数,以确定滚动更新批处理大小。无论百分比为何,每一工序的主机数始终为1或以上。
四. 包含和导入文件
1. 管理大型playbook
- 如果playbook很长或很复杂,我们可以将其分成较小的文件以便于管理。
- 可采用模块化方式将多个playbook组合为一个主要playbook,或者将文件中的任务列表插入play。
- 可以更轻松地在不同项目中重用play或任务序列。
2. 包含(include)或 导入(import)文件
- Ansible可以使用两种操作将内容带入playbook。可以包含内容,也可以导入内容。
- 包含内容是一个动态操作。在playbook运行期间,Ansible会在内容到达时处理所包含的内容,可以动态的加入内容。
- 导入内容是一个静态操作。在运行开始之前,Ansible在最初解析playbook时预处理导入的内容。
3. 导入playbook,导入playbook要顶层写,就是往左写
-
import_playbook指令允许将包含play列表的外部文件导入playbook。可以把一个或多个额外playbook导入到主playbook中。
-
由于导入的内容是一个完整的playbook,因此import_playbook功能只能在playbook的顶层使用,不能在play内使用。
-
如果导入多个playbook,则将按顺序导入并运行它们。
- name: Prepare the web server
import_playbook: web.yml
- name: Prepare the database server
import_playbook: db.yml
导入playbook
1.
[root@129a httpd]# ls
ansible.cfg files host_vars inventory vars
config.yml group_vars install.yml tests.yml
[root@129a httpd]# cat install.yml
---
- hosts: webservers
gather_facts: no
vars_files:
- vars/httpd
tasks:
- name: Provide the yum source file
copy:
src: files/CentOS-Base.repo
dest: /etc/yum.repos.d/
- name: install apache
dnf:
name: "{{ web }}"
state: latest
[root@129a httpd]#
2.
[root@129a httpd]# vim config.yml
[root@129a httpd]# cat config.yml
- name: install apache
import_playbook: install.yml
- hosts: webservers
gather_facts: no
vars_files:
- vars/httpd
tasks:
- name: Provides web site
copy:
src: files/game
dest: /var/www/html/
- name: config apache
copy:
src: files/httpd-vhosts.conf
dest: /etc/httpd/conf.d/
notify:
- restart apache
- name: run {{ web }}
service:
name: "{{ web }}"
state: started
enabled: yes
- name: close firewalld
service:
name: firewalld
state: stopped
enabled: no
handlers:
- name: restart apache
service:
name: httpd
state: restarted
[root@129a httpd]#
3.测试
[root@129a httpd]# ansible-playbook config.yml -C
PLAY [webservers] **************************************************************
TASK [Provide the yum source file] *********************************************
ok: [130h.example.com]
TASK [install apache] **********************************************************
ok: [130h.example.com]
PLAY [webservers] **************************************************************
TASK [Provides web site] *******************************************************
ok: [130h.example.com]
TASK [config apache] ***********************************************************
ok: [130h.example.com]
TASK [run httpd] ***************************************************************
ok: [130h.example.com]
TASK [close firewalld] *********************************************************
ok: [130h.example.com]
PLAY RECAP *********************************************************************
130h.example.com : ok=6 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
[root@129a httpd]#
4. 可以有多了个
例1
[root@129a httpd]# vim 130h.yml
[root@129a httpd]# cat 130h.yml
- name: install apache for 130h
import_playbook: install.yml
- hosts: webservers
tasks:
- name: config 130h
template:
src:
dest:
例2,导入两个额外playbook的主playbook
- name: Prepare the web server
import_playbook: web.yml
- name: Prepare the database server
import_playbook: db.yml
例3,可以使用导入的playbook在主playbook中交替play。
- name: Play 1
hosts: localhost
tasks:
- debug:
msg: Play 1
- name: Import Playbook
import_playbook: play2.yml
Play 1首先运行,然后运行从play2.ymlplaybook中导入的play
导入playbook要顶层写,就是往左写
4. 导入(import_tasks)和包含(include_tasks)任务
- 可以将任务文件中的任务列表导入或包含在play中。任务文件是包含一个任务平面列表的文件:
[root@localhost ~]# cat webserver_tasks.yml
- name: Installs the httpd package
yum:
name: httpd
state: latest
- name: Starts the httpd service
service:
name: httpd
state: started
4.1 导入任务文件
- 可以使用import_tasks功能将任务文件静态导入playbook内的play中。
- 导入任务文件时,在解析该playbook时将直接插入该文件中的任务。
- Playbook中的import_tasks的位置控制插入任务的位置以及运行多个导入的顺序
---
- name: Install web server
hosts: webservers
tasks:
- import_tasks: webserver_tasks.yml
when: ansible_facts['distribution'] == 'CentOS'
[root@129a httpd]# vim install.yml
[root@129a httpd]# cat install.yml
- name: Provide the yum source file
copy:
src: files/CentOS-Base.repo
dest: /etc/yum.repos.d/
- name: install apache
dnf:
name: "{{ web }}"
state: latest
[root@129a httpd]#
[root@129a httpd]# cat config.yml
- hosts: webservers
gather_facts: no
vars_files:
- vars/httpd
tasks:
- import_tasks: install.yml
- name: Provides web site
copy:
src: files/game
dest: /var/www/html/
- name: config apache
copy:
src: files/httpd-vhosts.conf
dest: /etc/httpd/conf.d/
notify:
- restart apache
- name: run {{ web }}
service:
name: "{{ web }}"
state: started
enabled: yes
- name: close firewalld
service:
name: firewalld
state: stopped
enabled: no
handlers:
- name: restart apache
service:
name: httpd
state: restarted
[root@129a httpd]#
- 导入任务文件时,在解析该playbook时将直接插入该文件中的任务。由于import_tasks在解析playbook时静态导入任务,因此对其工作方式有一些影响。
- 使用import_tasks功能时,导入时设置的when等条件语句将应用于导入的每个任务
- 无法将循环用于import_tasks功能
- 如果使用变量来指定要导入的文件的名称,则将无法使用主机或组清单变量
4.2 包含任务文件(include_tasks)
- 可以使用include_tasks功能将任务文件动态导入playbook内的play中。
---
- name: Install web server
hosts: webservers
tasks:
- include_tasks: webserver_tasks.yml
[root@129a httpd]# vim install.yml
[root@129a httpd]# cat install.yml
- name: Provide the yum source file
copy:
src: files/CentOS-Base.repo
dest: /etc/yum.repos.d/
- name: install apache
dnf:
name: "{{ web }}"
state: latest
[root@129a httpd]#
[root@129a httpd]# cat config.yml
- hosts: webservers
gather_facts: no
vars_files:
- vars/httpd
tasks:
- include_tasks: install.yml
- name: Provides web site
copy:
src: files/game
dest: /var/www/html/
- name: config apache
copy:
src: files/httpd-vhosts.conf
dest: /etc/httpd/conf.d/
notify:
- restart apache
- name: run {{ web }}
service:
name: "{{ web }}"
state: started
enabled: yes
- name: close firewalld
service:
name: firewalld
state: stopped
enabled: no
handlers:
- name: restart apache
service:
name: httpd
state: restarted
[root@129a httpd]#
[root@129a httpd]# ansible-playbook config.yml -C
PLAY [webservers] **************************************************************
TASK [include_tasks] ***********************************************************
included: /opt/httpd/install.yml for 130h.example.com
TASK [Provide the yum source file] *************************
-
在play运行并且这部分play到达前,include_tasks功能不会处理playbook中的内容。Playbook内容的处理顺序会影响包含任务功能的工作方式。
-
使用include_tasks功能时,包含时设置的when等条件语句将确定任务是否包含在play中
-
如果运行ansible-playbook --list-tasks以列出playbook中的任务,则不会显示已包含任务文件中的任务,将显示包含任务文件的任务。相比之下,import_tasks功能不会列出导入任务文件的任务,而列出已导入任务文件中的各个任务
-
1. include_tasks [root@129a httpd]# ansible-playbook --list-tasks config.yml playbook: config.yml play #1 (webservers): webservers TAGS: [] tasks: include_tasks TAGS: [] Provides web site TAGS: [] config apache TAGS: [] run {{ web }} TAGS: [] close firewalld TAGS: [] [root@129a httpd]# 显示的是include——tasks的名称 2. import_tasks [root@129a httpd]# ansible-playbook --list-tasks config.yml playbook: config.yml play #1 (webservers): webservers TAGS: [] tasks: Provide the yum source file TAGS: [] install apache TAGS: [] Provides web site TAGS: [] config apache TAGS: [] run {{ web }} TAGS: [] close firewalld TAGS: [] [root@129a httpd]# import_tasks显示的是被导入文件里面的任务
-
不能使用ansible-playbook --start-at-task从已包含任务文件中的任务开始执行playbook
-
不能使用notify语句触发已包含任务文件中的处理程序名称。可以在包含整个任务文件的主playbook中触发处理程序,在这种情况下,已包含文件中的所有任务都将运行,(包含的任务,handlers不执行,导入的任务执行,只不过导入的任务,需其他的任务完成后才执行)
-
4.3 任务文件的用例
- 在这些情景中将任务组作为与playbook独立的外部文件来管理或许有所帮助:
- 如果新服务器需要全面配置,则管理员可以创建不同的任务集合,分别用于创建用户、安装软件包、配置服务、配置特权、设置对共享文件系统的访问权限、强化服务器、安装安全更新,以及安装监控代理等。每一任务集合可通过单独的自包含任务文件进行管理
- 如果服务器由开发人员、系统管理员和数据库管理员统一管理,则每个组织可以编写自己的任务文件,再由系统经理进行审核和集成
- 如果服务器要求特定的配置,它可以整合为按照某一条件来执行的一组任务。换句话说,仅在满足特定标准时才包含任务
- 如果一组服务器需要运行某一项/组任务,则它/它们可以仅在属于特定主机组的服务器上运行
4.4 管理任务文件
- 为方便管理,可以创建专门用于任务文件的目录,并将所有任务文件保存在该目录中。
- 然后playbook就可以从该目录包含或导入任务文件。就可以构建复杂的playbook,同时简化其结构和组件的管理。
5. 为外部play和任务定义变量
-
使用Ansible的导入和包含功能将外部文件中的play或任务合并到playbook中极大地增强了在Ansible环境中重用任务和playbook的能力。
-
为了最大限度地提高重用可能性,这些任务和play文件应尽可能通用。
-
变量可用于参数化play和任务元素,以扩大任务和play的应用范围。
-
以下任务文件将安装Web服务所需的软件包,然后启用并启动必要的服务。
---
- name: Install the httpd package
yum:
name: httpd
state: latest
- name: Start the httpd service
service:
name: httpd
enabled: True
state: started
- 如下例所示对软件包和服务元素进行参数化,则任务文件也可用于安装和管理其他软件及其服务,而不仅仅用于Web服务。
任务文件:task.yml
---
- name: Install the {{ package }} package
yum:
name: "{{ package }}"
state: latest
- name: Start the {{ service }} service
service:
name: "{{ service }}"
enabled: True
state: started
例如
包:chrony
服务名字:chronyd
- 在将任务文件合并到一个playbook中时,定义用于执行该任务的变量
...output omitted...
tasks:
- name: Import task file and set variables
import_tasks: task.yml
vars:
package: httpd
service: service
import_tasks: task.yml写在tasks后面,只给它使用
-
Ansible使传递的变量可用于从外部文件导入的任务。
-
使用相同的技术使play文件更具有可重用性。将play文件合并到playbook中时,传递变量以用于执行该play
...output omitted...
- name: Import play file and set the variable
import_playbook: play.yml
vars:
package: mariadb
vars变量给play.yml使用