ansible-管理大项目

1.利用主机模式选择主机

1.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
tes

要演示如何解析主机模式，我们将执行Ansible Playbook的playbook.yml，使用不同的主机模式来以此示例清单中受管主机的不同子集作为目标。

1.2 受管主机

最基本的主机模式是单一受管主机名称列在清单中。这将指定该主机是清单中ansible命令要执行操作的唯一主机。

在该playbook运行时，第一个Gathering Facts任务应在与主机模式匹配的所有受管主机上运行。此任务期间的故障可能导致受管主机从play中移除。

如果清单中明确列出了IP地址，而不是主机名，则可以将其用作主机模式。如果IP地址未列在清单中，我们就无法用它来指定主机，即使该IP地址会在DNS中解析到这个主机名。
注意：
在清单中通过IP地址引用受管主机存在一个问题，那就是难以记住play或临时命令所针对的主机使用了哪个IP地址。但是，如果没有可解析的主机名，我们可能必须按IP地址指定主机以进行连接。
可以通过设置ansible_host主机变量，在清单中将某一别名指向特定的IP地址，演示如下：

[root@king ansible]# vim ansible.cfg   //自定义清单文件位置,在配置文件中写绝对路径
#inventory      = /etc/ansible/hosts
inventory       =/etc/ansible/file
[root@king ansible]# vim file 

test1 ansible_password=admin123
web1 ansible_password=admin
[root@king ansible]# mkdir host_vars //创建主机变量目录
[root@king ansible]# cd host_vars/
[root@king hosts_vars]# vim test1

ansible_host: 192.168.120.130
[root@king hosts_vars]# vim web1

ansible_host: 192.168.120.131
[root@king ansible]# tree
.
├── ！
├── ansible.cfg
├── file
├── hosts
├── host_vars
│   ├── test1
│   └── web1
└── roles

2 directories, 6 files
[root@king ansible]# ansible all -m ping
test1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}
web1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}
此时可以ping通说明文件配置没有问题。

1.3 使用组指定主机

当组名称用作主机模式时，它指定Ansible将对属于该组的成员的主机执行操作。

[root@king ansible]# vim file 

test1 ansible_password=admin123
[web]
web1 ansible_password=admin
[root@king ansible]# cd /root/playbook/
[root@king playbook]# vim play.yml 

---
- hosts: web
  tasks:
    - name: web test
      command: ping 192.168.120.130
[root@king playbook]# ansible-playbook --syntax-check play.yml 

playbook: play.yml
[root@king playbook]# ansible-playbook -C play.yml
PLAY [web] ***********************************************************************************

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

TASK [web test] ******************************************************************************
changed: [web1]

PLAY RECAP ***********************************************************************************
web1                       : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

记住，有一个名为all的特别组，它匹配清单中的所有受管主机。

---
- hosts: all

还有一个名为ungrouped的特别组，它包括清单中不属于任何其他组的所有单独存在的受管主机：

---
- hosts: ungrouped


[root@king playbook]# ansible ungrouped --list-hosts //不属于任何组里的单独存在的主机
  hosts (1):
    test1

1.4 使用通配符匹配多个主机

若要达成与all主机模式相同的目标，另一种方法是使用*通配符，它将匹配任意字符串。如果主机模式只是带引号的星号，则清单中的所有主机都将匹配。

[root@king playbook]# vim play.yml 

---
- hosts: '*'
  tasks:
    - name: web test
      ping:
[root@king playbook]# ansible-playbook --syntax-check play.yml 

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

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

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

TASK [web test] ******************************************************************************
ok: [test1]
ok: [web1]

PLAY RECAP ***********************************************************************************
test1                      : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignor

也可使用*字符匹配包含特定子字符串的受管主机或组。
例如，以下通配符主机模式匹配以.example.com结尾的所有清单名称：

---
- hosts: '*.example.com'

以下示例使用通配符主机模式来匹配开头为192.168.2.的主机或主机组的名称：

---
- hosts: '192.168.2.*'

以下示例使用通配符主机模式来匹配开头为datacenter的主机或主机组的名称：

---
- hosts: 'datacenter*'

重点：

通配符主机模式匹配所有清单名称、主机和主机组。它们不区别名称是DNS名、IP地址还是组，这可能会导致一些意外的匹配。
例如，根据示例清单，比较上一示例中指定datacenter主机模式的结果和data主机模式的结果：

---
- hosts: 'data*'

重点：
一些在主机模式中使用的字符对shell也有意义。通过ansible使用主机模式从命令行运行临时命令时，这可能会有问题。建议大家在命令行中使用单引号括起使用的主机模式，防止它们被shell意外扩展。
类似的，如果在Ansible Playbook中使用了任何特殊通配符或列表字符，必须将主机模式放在单引号里，确保能够正确解析主机模式。

1.5 列表

可以通过逻辑列表来引用清单中的多个条目。主机模式的逗号分隔列表匹配符合任何这些主机模式的所有主机。

如果提供受管主机的逗号分隔列表，则所有这些受管主机都将是目标：

[root@king playbook]# vim play.yml 

---
- hosts: test1,web1,192.168.132
  tasks:
    - name: web test
      ping:

如果提供组的逗号分隔列表，则属于任何这些组的所有主机都将是目标：

---
- hosts: test,web
  tasks:
    - name: web test
      ping:

也可以混合使用受管主机、主机组和通配符，如下所示：

---
- hosts: 'test1,web,local*'  //含有特殊通配符必须加单引号所有括起来
  tasks:
    - name: web test
      ping:

注意：
也可以用冒号（:）取代逗号。不过，逗号是首选的分隔符，特别是将IPv6地址用作受管主机名称时。

如果列表中的某一项以与符号（&）开头，则主机必须与该项匹配才能匹配主机模式。它的工作方式类似于逻辑AND。(&使用只和邻近的主机才生效,如果,是在&前后都有就只和&前面主机匹配)
例如，根据我们的示例清单，以下主机模式将匹配test组中同时也属于web组的受控主机：

---
- hosts: 'test,&web'  //test组中并且也属于runtime组中的受管主机,如果有则执行ping
  tasks:
    - name: web test
      ping:

通过在主机模式的前面使用感叹号（!）表示从列表中排除匹配某一模式的主机或组。它的工作方式类似于逻辑NOT。
根据示例清单，以下示例匹配test,web组中定义的所有主机，但test1主机除外：

---
- hosts: 'test,web,!test1'  
  tasks:
    - name: web test
      ping:

联用特殊通配符和列表字符使用：
[属于test组和web组共有的主机,除了主机web1,192.168.130.段的所有主机——都执行ping]

---
- hosts: '&test,web,!web1,192.168.130.*'
  tasks:
    - name: web test
      ping:

2. 管理动态清单

2.1 动态生成清单

前面我们用到的静态清单编写比较容易，对于管理小型基础架构而言也很方便。不过，如果要操作许多台计算机，或者在计算机更替非常快的环境中工作，可能难以让静态清单文件保持最新状态。

大多数大型IT环境中没有系统来跟踪可用的主机以及它们的组织方式。例如，可能有外部目录服务通过Zabbix等监控系统维护，或者位于FreeIPA或Active Directory服务器上。Cobbler等安装服务器或红帽卫星等管理服务可能跟踪部署的裸机系统。类似地，Amazon Web ServicesEC2或OpenStack部署等云服务，或者基于Vmware或红帽虚拟化的虚拟机基础架构可能是有关那些更替的实例和虚拟机的信息来源。

Ansible支持动态清单脚本，这些脚本在每当Ansible执行时从这些类型的来源检索当前的信息，使清单能够实时得到更新。这些脚本是可以执行的程序，能够从一些外部来源收集信息，并以JSON格式输出清单。

动态清单脚本的使用方式与静态清单文本文件一样。清单的位置可以直接在当前的ansible.cfg文件中指定，或者通过-i选项指定。如果清单文件可以执行，则它将被视为动态清单程序，Ansible会尝试运行它来生成清单。如果文件不可执行，则它将被视为静态清单。

清单位置可以在ansible.cfg配置文件中通过inventory参数进行配置。默认情况下，它被配置为/etc/ansible/hosts。

2.2 开源社区脚本

开源社区向Ansible项目贡献了大量现有的动态清单脚本。它们没有包含在ansible软件包中。这些脚本可从Ansible GigHub网站（https://github.com/ansible/ansible/tree/devel/examples）获取。

2.3 编写动态清单程序

如果使用的目录系统或基础架构没有动态清单脚本，我们可以编写自定义清单程序。可以使用任何编程语言编写自定义程序，但传递适当的选项时必须以JSON格式返回清单信息。

ansible-inventory命令是学习如何以JSON格式编写Ansible清单的有用工具。

要以JSON格式显示清单文件的内容，请运行ansible-inventory --list命令。可以使用-i选项指定要处理的清单文件的位置，或仅使用当前Ansible配置设置的默认清单。

ansible-inventory --list -i +指定清单文件

[root@king ~]# ansible-inventory --list -i file
{
    "_meta": {
        "hostvars": {}
    },
    "all": {
        "children": [
            "ungrouped"
        ]
    }
}

以下示例演示了如何使用ansible-inventory命令来处理INI样式的清单文件并以JSON格式输出。

[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能够运行它。

在传递–list选项时，脚本必须显示清单中所有主机和组的JSON编码散列/字典。
注意
通过–host hostname选项调用时，该脚本必须显示指定主机的变量的JSON散列/字典。如果不提供任何变量，则可能显示空白的JSON散列或字典。
另外，如果–list选项返回名为_meta的顶级元素，则可以在一次脚本调用中返回所有主机变量，从而提升脚本性能。此时，不会进行–host调用。

有关详细信息，请参见部署动态清单来源[https://docs.ansible.com/ansible/latest/dev_guide/developing_inventory.html]。
ansible使用这个动态清单来管理主机：

ansible all -i inventory.py -m ping
ansible 192.168.120.129 -i inventory.py -m ping

注意
清单文件的解析顺序不是由文档指定的。目前，如果存在多个清单文件，它们会按照字母顺序进行解析。如果一个清单源依赖于另一个清单源的信息，则它们的加载顺序可能会确定清单文件是按预期工作还是引发错误。因此，务必要确保所有文件都自相一致，从而避免意外的错误。

Ansible会自动忽略清单目录中以特定后缀结尾的文件。这可以通过在Ansible配置文件中的inventory_ignore_extensions指令来控制。有关更多信息，请参阅Ansible官方文档。

[root@king ~]# vim /etc/ansible/ansible.cfg
#inventory_ignore_extensions = ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo

使用动态清单：https://docs.ansible.com/ansible/latest/user_guide/intro_dynamic_inventory.html
开发动态清单：https://docs.ansible.com/ansible/latest/dev_guide/developing_inventory.html

3. 配置并行

3.1 使用forks在ansible中配置并行

forks(分叉 )
当Ansible处理playbook时，会按顺序运行每个play。确定play的主机列表之后，Ansible将按顺序运行每个任务。通常，所有主机必须在任何主机在play中启动下一个任务之前成功完成任务。

理论上，Ansible可以同时连接到play中的所有主机以执行每项任务。这非常适用于小型主机列表。但如果该play以数百台主机为目标，则可能会给控制节点带来沉重负担。
Ansible所进行的最大同时连接数由Ansible配置文件中的forks参数控制。默认情况下设为5，这可通过以下方式之一来验证。

过滤出默认的forks是多少(两种方式)：
[root@king ~]# grep forks /etc/ansible/ansible.cfg 
#forks          = 5

[root@king ~]# ansible-config dump|grep -i forks
DEFAULT_FORKS(default) = 5

例如，假设Ansible控制节点配置了5个forks的默认值，并且play具有10个受管主机。Ansible将在前5个受管主机上执行play中的第一个任务，然后在其他5个受管主机上对第一个任务执行第二轮。在所有受管主机上执行第一个任务后，Ansible将继续一次在5受管主机的组中的所有受管主机上执行下一个任务。Ansible将依次对每个任务执行此操作，直到play结束。

forks的默认值设置得非常保守。如果你的控制节点正在管理Linux主机，则大多数任务将在受管主机上运行，并且控制节点的负载较少。在这种情况下，通常可以将forks的值设置得更高，可能接近100，然后性能就会提高。

如果playbook在控制节点上运行很多代码，则应明智地提高forks限值。如果使用Ansible管理网络路由器和交换机，则大多数模块在控制节点上运行而不是在网络设备上运行。由于这会增加控制节点上的负载，因此其支持forks数量增加的能力将显著低于仅管理Linux主机的控制节点。

可以从命令行覆盖Ansible配置文件中forks的默认设置。ansible和ansible-playbook命令均提供-f或–forks选项以指定要使用的forks数量。

3.2 管理滚动更新

通常，当Ansible运行play时，它会确保所有受管主机在启动任何主机进行下一个任务之前已完成每个任务。在所有受管主机完成所有任务后，将运行任何通知的处理程序。

但是，在所有主机上运行所有任务可能会导致意外行为。例如，如果play更新负载均衡Web服务器集群，则可能需要在进行更新时让每个Web服务器停止服务。如果所有服务器都在同一个play中更新，则它们可能全部同时停止服务。

避免此问题的一种方法是使用serial关键字，通过play批量运行主机。在下一批次启动之前，每批主机将在整个play中运行。

在下面的示例中，Ansible一次在两个受管主机上执行play，直至所有受管主机都已更新。Ansible首先在前两个受管主机上执行play中的任务。如果这两个主机中的任何一个或两个都通知了处理程序，则Ansible将根据这两个主机的需要运行处理程序。在这两个受管主机上执行完play时，Ansible会在接下来的两个受管主机上重复该过程。Ansible继续以这种方式运行play，直到所有受管主机都已更新。

- name: Rolling update
  hosts: webservers
  serial: 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或以上。

forks：规定forks执行的主机数后，都会逐一执行完第一个任务后接着执行下一个任务，直至所有主机执行完，但如果中途有主机报错，将所有主机任务停止进行。
serial：规定serial执行主机数后，当所有任务在规定主机数执行完后，接着执行会进行下面的主机，直至完成，但如果中途有主机服务报错，就造成有一部分服务器会不可用，使服务降级而不是中断

4. 包含和导入文件

4.1 管理大型playbook

如果playbook很长或很复杂，我们可以将其分成较小的文件以便于管理。可采用模块化方式将多个playbook组合为一个主要playbook，或者将文件中的任务列表插入play。这样可以更轻松地在不同项目中重用play或任务序列。

分写为多个playbook，并把多个playbook组合为一个整体，再去执行，
如果有报错就可知道是哪一个playbook问题方便排错。简单分写如下：
[root@king playbook]# mkdir playbook
[root@king playbook]# vim install.yml
---
- hosts: test1
  tasks:
    - name: install httpd
      yum:
        name: httpd
        state: present
[root@king playbook]# ls /tmp/
httpd.conf
[root@king playbook]# vim config.yml

---
- hosts: test1
  tasks:
    - name: config file
      template:
        src: /tmp/httpd.conf
        dest: /etc/http/conf/
       notify:      
         - restart httpd   //处理程序的名称
  handlers:       // handlers关键字表示处理程序任务列表的开头
    - name: restart httpd    //此任务名称必须和notify指定处理程序的名称一致
      service:
        name: httpd
        state: restarted
[root@king playbook]# tree
.
├── ！
├── files
├── playbook
│   ├── config.yml
│   └── install.yml
└── play.yml
组合到一起步骤如下👇

Ansible可以使用两种操作将内容带入playbook。可以包含内容，也可以导入内容。

4.2 导入playbook文件

导入内容：是一个静态操作。在运行开始之前，Ansible在最初解析playbook时预处理导入的内容。

import_playbook指令允许将包含play列表的外部文件导入playbook。换句话说，可以把一个或多个额外playbook导入到主playbook中。

由于导入的内容是一个完整的playbook，因此import_playbook功能只能在playbook的顶层使用，不能在play内使用。如果导入多个playbook，则将按顺序导入并运行它们。

导入两个额外playbook的主playbook的简单示例如下所示：

导入方式添加：
[root@king playbook]# pwd
/root/playbook/playbook
[root@king playbook]# vim main.yml  //导入到主playbook文件中。

- name: 导入_install
  import_playbook: install.yml
  
- name: 导入_config
  import_playbook: config.yml
[root@king playbook]# ansible-playbook --syntax-check main.yml  //语法检查(连带检查还有另外两个额外的playbook)

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

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

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

TASK [install httpd] *************************************************************************
ok: [test1]

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

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

TASK [config file] ***************************************************************************
changed: [test1]

RUNNING HANDLER [restart httpd] **************************************************************
changed: [test1]

PLAY RECAP ***********************************************************************************
test1                      : ok=5    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

还可以直接在导入的playbook在主playbook中交替执行play，如果由新任务需要加入，此时可以直接在主playbook中添加新的playbook任务此时不需要写开头（—）直接写hosts就可以，也可以再次单独写一个playbook导入到主playbook中：

[root@king playbook]# cat main.yml 
- name: 导入_install
  import_playbook: install.yml

- hosts: test1
  tasks:
    - name: start service
      service:
        name: httpd
        state: started

- name: 导入_config
  import_playbook: config.yml
[root@king playbook]# ansible-playbook --syntax-check main.yml 

playbook: main.yml
[root@king playbook]# ansible-playbook -C main.yml  //测试执行过程

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

TASK [Gathering Facts] ***********************************************************************
ok: [test1]
①
TASK [install httpd] *************************************************************************
ok: [test1]
②
PLAY [test1] *********************************************************************************

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

TASK [start service] *************************************************************************
changed: [test1]
③
PLAY [test1] *********************************************************************************

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

TASK [config file] ***************************************************************************
changed: [test1]

RUNNING HANDLER [restart httpd] **************************************************************
changed: [test1]

PLAY RECAP ***********************************************************************************
test1                      : ok=7    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

由上面演示可知，在主playbook中任务执行是按照从上至下的顺序来执行的play任务。

导入还有另外一种语句用法 import_tacks：

[root@king playbook]# vim main.yml
---
- name: Install server
  hosts: test1     //该导入主playbook需要在其指定主机，额外的playbook中不需要指定主机
  tasks:
 - import_tasks: install.yml

导入任务文件时，在解析该playbook时将直接插入该文件中的任务。由于import_tasks在解析playbook时静态导入任务，因此对其工作方式有一些影响。不好之处：

• 使用import_tasks功能时，导入时设置的when等条件语句将应用于导入的每个任务
• 无法将循环用于import_tasks功能
• 如果使用变量来指定要导入的文件的名称，则将无法使用主机或组清单变量

4.3 包含任务文件

包含内容：是一个动态操作。在playbook运行期间，Ansible会在内容到达时处理所包含的内容。

可以使用include_tasks功能将任务文件动态导入playbook内的play中，此时不需要在分任务playbook中指定主机，因为要把分任务文件包含到主playbook列表中，此中已包含指定执行主机。

[root@king playbook]# pwd
/root/playbook/playbook
[root@king playbook]# vim config.yml

- name: configure httpd
  template:
    src: /tmp/httpd.conf
    dest: /etc/httpd/conf/
[root@king playbook]# vim service.yml

- name: enable httpd
  service:
    name: httpd
    enabled: yes
[root@king playbook]# vim main.yml

---
- hosts: test1
  tasks:
    - include_tasks: config.yml
    - include_tasks: service.yml
[root@king playbook]# vim main.yml
[root@king playbook]# ansible-playbook --syntax-check main.yml 

playbook: main.yml

在play运行并且这部分play到达前，include_tasks功能不会处理playbook中的内容。Playbook内容的处理顺序会影响包含任务功能的工作方式。

• 使用include_tasks功能时，包含时设置的when等条件语句将确定任务是否包含在play中
• 如果运行ansible-playbook --list-tasks以列出playbook中的任务，则不会显示已包含任务文件中的任务。将显示包含任务文件的任务。相比之下，import_tasks功能不会列出导入任务文件的任务，而列出已导入任务文件中的各个任务

只显示包含了几个任务：
[root@king playbook]# ansible-playbook --list-tasks main.yml
playbook: main.yml

  play #1 (test1): test1	TAGS: []
    tasks:
      include_tasks	TAGS: []
      include_tasks	TAGS: []

列出已导入任务文件中的各个任务名称是什么：
[root@king playbook]# ansible-playbook --list-tasks main2.yml 

playbook: main2.yml

  play #1 (test1): test1	TAGS: []
    tasks:
      configure httpd	TAGS: []
      enable httpd	TAGS: []

• 不能使用ansible-playbook --start-at-task从已包含任务文件中的任务开始执行playbook
• 不能使用notify语句触发已包含任务文件中的处理程序名称。可以在包含整个任务文件的主playbook
• 中触发处理程序，在这种情况下，已包含文件中的所有任务都将运行

4.4任务文件的用例

请参考下面的示例，在这些情景中将任务组作为与playbook独立的外部文件来管理或许有所帮助：

• 如果新服务器需要全面配置，则管理员可以创建不同的任务集合，分别用于创建用户、安装软件包、配置服务、配置特权、设置对共享文件系统的访问权限、强化服务器、安装安全更新，以及安装监控代理等。每一任务集合可通过单独的自包含任务文件进行管理
• 如果服务器由开发人员、系统管理员和数据库管理员统一管理，则每个组织可以编写自己的任务文件，再由系统经理进行审核和集成
• 如果服务器要求特定的配置，它可以整合为按照某一条件来执行的一组任务。换句话说，仅在满足特定标准时才包含任务
• 如果一组服务器需要运行某一项/组任务，则它/它们可以仅在属于特定主机组的服务器上运行

4.5管理任务文件

为方便管理，可以创建专门用于任务文件的目录，并将所有任务文件保存在该目录中。然后playbook就可以从该目录包含或导入任务文件。这样就可以构建复杂的playbook，同时简化其结构和组件的管理。

4.5 为外部play和任务定义变量

使用Ansible的导入和包含功能将外部文件中的play或任务合并到playbook中极大地增强了在Ansible环境中重用任务和playbook的能力。为了最大限度地提高重用可能性，这些任务和play文件应尽可能通用。变量可用于参数化play和任务元素，以扩大任务和play的应用范围。
例如，以下任务文件将安装Web服务所需的软件包，然后启用并启动必要的服务。

---     
- hosts: test1
  tasks:
    - name: install httpd
      yum:
        name: httpd
        state: present
    - name: start httpd
      service:
        name: httpd
        state: start
        enabled: yes

如果如下例所示对软件包和服务元素进行参数化，则任务文件也可用于安装和管理其他软件及其服务，而不仅仅用于Web服务。随后，在将任务文件合并到一个playbook中时，定义用于执行该任务的变量，如下所示：

[root@king playbook]# vim install.yml
[root@king playbook]# vim service.yml
[root@king playbook]# cat install.yml 
- name: install "{{ package }}"
  yum:
    name: "{{ package }}"
    state: present

[root@king playbook]# cat service.yml 
- name: start "{{ service }}"
  service:
    name: "{{ service}}"
    state: started
    enabled: yes
[root@king playbook]# vim main.yml

---
- hosts: test1
  vars:
    package: httpd
    service: httpd
  tasks：
    - include_tasks: install.yml
    - include_tasks: servcie.yml
[root@king playbook]# ansible-playbook --syntax-check main.yml 

playbook: main.yml

Ansible使传递的变量可用于从外部文件导入的任务。

使用相同的技术使play文件更具有可重用性。

---
- hosts: test1
  vars:
    package: postfix
    service: postfix
  tasks:
    - include_tasks: install.yml
    - include_tasks: servcie.yml
[root@king playbook]# ansible-playbook --syntax-check main.yml 

playbook: main.yml