ansible-导入包含、角色结构、系统角色

一、导入和包含

虽然可以在一个非常大的文件中编写 playbook (您可能以这种方式开始学习 palybook)，但最终您将希望重用文件并开始组织工作。在Ansible中，有三种方法可以做到这一点: includes, imports, androles。

includes 和imports（在Ansible 2.4版中添加）允许用户将大型playbook拆分成较小的文件，这些文件可以在多个父级playbook中使用，甚至可以在同一Playbook中多次使用。

动态和静态

对于可重用的内容，Ansible有两种操作模式: 动态 和 静态 。
在Ansible 2.0中，引入了动态包含的概念。由于以这种方式实现all include的一些限制，Ansible 2.1中引入了将force include设置为静态的能力。因为include任务被重载，包含了静态和动态语法，而且由于include的默认行为可能会根据任务上设置的其他选项而更改，所以Ansible 2.4引入了include与import的概念。

1.静态导入

使用import_tasks模块来导入tasks文件

使用import_role模块来导入role

tasks:
  - import_tasks: tasks/foo.yml
  - import_role:
      name: example
import_tasks还允许 传递变量


- import_tasks: wordpress.yml wp_user=timmy

- import_tasks: wordpress.yml
  vars:
    wp_user: timmy
    ssh_keys:
      - keys/one.txt
      - keys/two.txt

例子

[root@server ansible]# cat /etc/ansible/playbook/test/yum.yml 
---
- hosts: httpd
  tasks: 
    - name: install
      yum: 
        name: httpd
        state: present
      
[root@server ansible]# cat /etc/ansible/playbook/test/firewalld.yml 
---
- hosts: httpd
  tasks:   
    - name: stop firewalld
      service: 
        name: firewalld
        state: stopped


    - name: 
      shell: 
        setenforce 0
        
[root@server ansible]# cat /etc/ansible/playbook/test/main.yml 
- name: stop firewalld
  import_playbook: firewalld.yml   //导入firewalld

- name: install httpd
  import_playbook: yum.yml        //导入yum

执行
 
[root@server ansible]# ansible-playbook playbook/test/main.yml 

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

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

TASK [stop firewalld] **********************************************************
changed: [192.168.143.20]

TASK [shell] *******************************************************************
changed: [192.168.143.20]

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

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

TASK [install] *****************************************************************
ok: [192.168.143.20]

PLAY RECAP *********************************************************************
192.168.143.20              : ok=5    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
// 查看
 [root@httpd ~]# getenforce 
Permissive

2.动态包含

使用include_tasks模块来包含tasks文件

使用include_role模块来包含role

动态包含可以用作循环引用

- include_tasks: foo.yml param={{item}}
  with_items: # 循环引用3次
   - 1
   - 2
   - 3
- include_role:
    name: example
还可以使用变量引入task文件


- include_tasks: "{{inventory_hostname}}.yml"

2.1变量包含

include_vars 在 task 中动态加载 yaml 或 json 文件类型中的变量

yaml - include_vars: myvars.yml

根据操作系统类型加载变量文件，如果找不到，则为默认值。

- include_vars: "{{ item }}"
  with_first_found:
    - "{{ ansible_distribution }}.yml"
    - "{{ ansible_os_family }}.yml"
    - "default.yml"

3.动态与静态两者的区别

Ansible在Playbook解析时间预处理所有 静态导入 。在执行前导入配置文件，出现错误会立即停止

动态包含 是在运行期间遇到该任务时处理的。在执行时导入配置文件，出现错误不会立即停止
当涉及Ansible任务选项时，例如tags和条件语句when：

对于 动态包含，任务选项将仅在评估动态任务时应用于该任务，而不会复制到子任务。

对于 静态导入，父任务选项将被复制到导入中包含的所有子任务。
使用include* vs.import*有一些优点，也有一些缺点，用户在选择使用它们时应该加以考虑

使用include*语句的主要优点是 循环。 当 循环与包含 一起使用时，将对循环中的 每个项目执行一次包含的task或role 。

与静态导入相比，动态包含的一些限制

你不能使用notify来触发来自动态包含的处理程序名称。

你不能使用–start-at-task在动态包含内的任务开始执行。

仅存在于动态包含内的标记不会显示在-list-tags输出中。

只存在于动态包含内的任务将不会显示在-list-tasks输出中。
与动态包含相比, 静态导入的一些限制

静态导入 不能用循环

当使用目标文件或角色名称的变量时，不能使用主机清单中的 变量

handlers 使用 import 导入的处理程序在被其名称通知时不会被触发，因为import会用导入的任务列表覆盖 handler’s 的指定任务。

二、角色ROLE

角色是基于已知文件结构自动加载某些vars_files，tasks和handlers的方法。 按角色分组的内容还允许与其他用户轻松共享角色。

1.角色目录结构

文件结构如下

角色必须包含至少一个这样的目录，但是完全可以排除任何没有使用的目录。在使用时，每个目录必须包含一个main.yml文件，其中包含相关内容:

参数	注释
tasks	包含角色要执行的主要任务列表。
handlers	包含处理程序，可以由此角色使用，甚至可以在此角色以外的任何地方使用。
defaults	角色的默认变量
vars	角色的其他变量
files	包含可以通过此角色部署的文件
templates	包含可以通过此角色部署的模板。
meta	为这个角色定义了一些元数据。
library	如果有任何自定义模块，将其放在这里（可选）
filter_plugins	如果有任何自定义过滤器插件，将其放在这里（可选）
group_var/all	如果group_var/all存在，其中列出的变量将被添加到所有的主机组中
group_var/groupname1	如果group_var/groupname1存在，其中列出的变量将被添加到groupname1主机组中
host_vars/hostname1	如果host_vars/hostname1存在，其中列出的变量将被添加到hostname1主机组中

除了特定的文件和目录外，也可以包含自定义的文件和目录，比如下面的为每个操作系统设置一个文件

2.角色使用

在play中使用roles: 来定义使用哪些role

这个 playbook 为一个角色 ‘x’ 指定了如下的行为

如果 roles/x/tasks/main.yml 存在, 其中列出的 tasks 将被添加到 play 中

如果 roles/x/handlers/main.yml 存在, 其中列出的 handlers 将被添加到 play 中

如果 roles/x/vars/main.yml 存在, 其中列出的 变量将被添加到 play 中

如果 roles/ x/defaults/main.yml存在，其中列出的角色默认变量将被添加到play 中

如果 roles/x/meta/main.yml 存在, 其中列出的 “角色依赖” 将被添加到 roles 列表中

所有 copy tasks 可以引用 roles/x/files/ 中的文件，不需要指明文件的全路径。

所有 script tasks 可以引用 roles/x/files/中的脚本，不需要指明文件的全路径。

所有 template tasks 可以引用 roles/x/templates/ 中的文件，不需要指明文件的全路径。

所有 include tasks 可以引用 roles/x/tasks/ 中的文件，不需要指明文件的全路径。如果 roles 目录下有文件不存在，这些文件将被忽略。

当以这种方式使用时，playbook 的执行顺序如下:

pre_tasks 定义的所有任务
到目前触发的handlers任务
roles中列出的每个角色将依次执行。 角色meta/main.yml中定义的任何角色依赖关系都将首先运行，但要遵循标签过滤和条件。
tasks 定义的所有任务
到目前触发的handlers任务
post_tasks 定义的所有任务
到目前触发的handlers任务
例子

vim tasks/main.yml
- debug:
    msg: "This is testing"

---
- hosts: httpd
  roles:
  - xu 

[root@server  ansible]# ansible-playbook testing.yml 

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

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

TASK [xu : debug] *************************************************************
ok: [192.168.143.20] => {
    "msg": "This is testing"
}

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

3.系统角色的使用

3.1 安装RHEL系统角色

yum -y install rhel-system-roles

安装后，RHEL系统角色位于**/usr/share/ansible/roles**目录中：

cd /usr/share/ansible/roles/
[root@server roles]# ls
linux-system-roles.certificate
linux-system-roles.crypto_policies
linux-system-roles.ha_cluster
linux-system-roles.kdump
linux-system-roles.kernel_settings
linux-system-roles.logging
linux-system-roles.metrics
linux-system-roles.nbde_client
linux-system-roles.nbde_server
linux-system-roles.network
linux-system-roles.postfix
linux-system-roles.selinux
linux-system-roles.ssh
linux-system-roles.sshd
linux-system-roles.storage
linux-system-roles.timesync
linux-system-roles.tlog
rhel-system-roles.certificate
rhel-system-roles.crypto_policies
rhel-system-roles.ha_cluster
rhel-system-roles.kdump
rhel-system-roles.kernel_settings
rhel-system-roles.logging
rhel-system-roles.metrics
rhel-system-roles.nbde_client
rhel-system-roles.nbde_server
rhel-system-roles.network
rhel-system-roles.postfix
rhel-system-roles.selinux
rhel-system-roles.ssh
rhel-system-roles.sshd
rhel-system-roles.storage
rhel-system-roles.timesync
rhel-system-roles.tlog

例子
时间同步角色同步

[root@server roles]# cp -a /usr/share/ansible/roles/rhel-system-roles.timesync timesync
[root@server roles]# ls
timesync  xu

---
- hosts: httpd
  vars:
    timesync_ntp_servers:
      - hostname: time2.aliyun.com
        iburst: yes
  roles:
    - timesync

selinux角色

[root@server ansible]# vim testing.yml
---
- hosts: httpd
  vars:
    selinux_policy: targeted
    selinux_state: disabled
  roles:
    - selinux