Playbook 角色(Roles) 和 Include 语句

tasks:
 - { include: wordpress.yml, wp_user: timmy, ssh_keys: [ ‘keys/one.txt‘, ‘keys/two.txt‘ ] }

使用上述任意一种语法格式传递变量给 include files 之后，这些变量就可以在 include 包含的文件中使用了。 关于变量的详细使用方法请查看 Variables 。变量可以这样去引用:

{{ wp_user }}

(除了显式传递的参数，所有在 vars section 中定义的变量也可在这里使用)

从 1.0 版开始，Ansible 支持另一种传递变量到 include files 的语法，这种语法支持结构化的变量:

tasks:

  - include: wordpress.yml
    vars:
        wp_user: timmy
        some_list_variable:
          - alpha
          - beta
          - gamma

在 Playbooks 中可使用 include 包含其他 playbook.

Include 语句也可以用在 ‘handlers’ section 中，比如，你希望定义一个重启 apache 的 handler， 你只需要定义一次，然后便可在所有的 playbook 中使用这个 handler。你可以创建一个 handlers.yml 文件如下:

---
# this might be in a file like handlers/handlers.yml
- name: restart apache
  service: name=apache state=restarted

然后在你的主 playbook 文件中，在一个 play 的最后使用 include 包含 handlers.yml:

handlers:
  - include: handlers/handlers.yml

Include 语句可以和其他非 include 的 tasks 和 handlers 混合使用。

Include 语句也可用来将一个 playbook 文件导入另一个 playbook 文件。这种方式允许你定义一个 顶层的 playbook，这个顶层 playbook 由其他 playbook 所组成。

举个例子:

- name: this is a play at the top level of a file
  hosts: all
  remote_user: root

  tasks:

  - name: say hi
    tags: foo
    shell: echo "hi..."

- include: load_balancers.yml
- include: webservers.yml
- include: dbservers.yml

注意：当你在 playbook 中引用其他 playbook 时，不能使用变量替换。

Roles

你现在已经学过 tasks 和 handlers，那怎样组织 playbook 才是最好的方式呢？简单的回答就是：使用 roles ! Roles 基于一个已知的文件结构，去自动的加载某些 vars_files，tasks 以及 handlers。基于 roles 对内容进行分组，使得我们可以容易地与其他用户分享 roles 。

一个项目的结构如下:

site.yml
webservers.yml
fooservers.yml
roles/
   common/
     files/
     templates/
     tasks/
     handlers/
     vars/
     defaults/
     meta/
   webservers/
     files/
     templates/
     tasks/
     handlers/
     vars/
     defaults/
     meta/

一个 playbook 如下:

---
- hosts: webservers
  roles:
     - common
     - webservers

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

• 如果 roles/x/tasks/main.yml 存在, 其中列出的 tasks 将被添加到 play 中
• 如果 roles/x/handlers/main.yml 存在, 其中列出的 handlers 将被添加到 play 中
• 如果 roles/x/vars/main.yml 存在, 其中列出的 variables 将被添加到 play 中
• 如果 roles/x/meta/main.yml 存在, 其中列出的 “角色依赖” 将被添加到 roles 列表中 (1.3 and later)
• 所有 copy tasks 可以引用 roles/x/files/ 中的文件，不需要指明文件的路径。
• 所有 script tasks 可以引用 roles/x/files/ 中的脚本，不需要指明文件的路径。
• 所有 template tasks 可以引用 roles/x/templates/ 中的文件，不需要指明文件的路径。
• 所有 include tasks 可以引用 roles/x/tasks/ 中的文件，不需要指明文件的路径。

在 Ansible 1.4 及之后版本，你可以为”角色”的搜索设定 roles_path 配置项。使用这个配置项将所有的 common 角色 check out 到一个位置，以便在多个 playbook 项目中可方便的共享使用它们。查看 Ansible的配置文件 详细了解设置这个配置项的细节，该配置项是在 ansible.cfg 中配置。

如果 roles 目录下有文件不存在，这些文件将被忽略。比如 roles 目录下面缺少了 ‘vars/’ 目录，这也没关系。

注意：你仍然可以在 playbook 中松散地列出 tasks，vars_files 以及 handlers，这种方式仍然可用，但 roles 是一种很好的具有组织性的功能特性，我们强烈建议使用它。如果你在 playbook 中同时使用 roles 和 tasks，vars_files 或者 handlers，roles 将优先执行。

而且，如果你愿意，也可以使用参数化的 roles，这种方式通过添加变量来实现，比如:

---

- hosts: webservers
  roles:
    - common
    - { role: foo_app_instance, dir: ‘/opt/a‘,  port: 5000 }
    - { role: foo_app_instance, dir: ‘/opt/b‘,  port: 5001 }

当一些事情不需要频繁去做时，你也可以为 roles 设置触发条件，像这样:

---

- hosts: webservers
  roles:
    - { role: some_role, when: "ansible_os_family == ‘RedHat‘" }

它的工作方式是：将条件子句应用到 role 中的每一个 task 上。关于”条件子句”的讨论参见本文档后面的章节。

最后，你可能希望给 roles 分配指定的 tags。比如:

---

- hosts: webservers
  roles:
    - { role: foo, tags: ["bar", "baz"] }

如果 play 仍然包含有 ‘tasks’ section，这些 tasks 将在所有 roles 应用完成之后才被执行。

如果你希望定义一些 tasks，让它们在 roles 之前以及之后执行，你可以这样做:

---

- hosts: webservers

  pre_tasks:
    - shell: echo ‘hello‘

  roles:
    - { role: some_role }

  tasks:
    - shell: echo ‘still busy‘

  post_tasks:
    - shell: echo ‘goodbye‘

角色默认变量(Role Default Variables)

角色默认变量允许你为 included roles 或者 dependent roles(见下) 设置默认变量。要创建默认变量，只需在 roles 目录下添加 defaults/main.yml 文件。这些变量在所有可用变量中拥有最低优先级，可能被其他地方定义的变量(包括 inventory 中的变量)所覆盖。

角色依赖(Role Dependencies)

“角色依赖” 使你可以自动地将其他 roles 拉取到现在使用的 role 中。”角色依赖” 保存在 roles 目录下的 meta/main.yml 文件中。这个文件应包含一列 roles 和 为之指定的参数，下面是在 roles/myapp/meta/main.yml 文件中的示例:

---
dependencies:
  - { role: common, some_parameter: 3 }
  - { role: apache, port: 80 }
  - { role: postgres, dbname: blarg, other_parameter: 12 }

“角色依赖” 可以通过绝对路径指定，如同顶级角色的设置:

---
dependencies:
   - { role: ‘/path/to/common/roles/foo‘, x: 1 }

“角色依赖” 也可以通过源码控制仓库或者 tar 文件指定，使用逗号分隔：路径、一个可选的版本（tag, commit, branch 等等）、一个可选友好角色名（尝试从源码仓库名或者归档文件名中派生出角色名）:

---
dependencies:
  - { role: ‘git+http://git.example.com/repos/role-foo,v1.1,foo‘ }
  - { role: ‘/path/to/tar/file.tgz,,friendly-name‘ }

“角色依赖” 总是在 role （包含”角色依赖”的role）之前执行，并且是递归地执行。默认情况下，作为 “角色依赖” 被添加的 role 只能被添加一次，如果另一个 role 将一个相同的角色列为 “角色依赖” 的对象，它不会被重复执行。但这种默认的行为可被修改，通过添加 allow_duplicates: yes 到meta/main.yml 文件中。 比如，一个 role 名为 ‘car’，它可以添加名为 ‘wheel’ 的 role 到它的 “角色依赖” 中:

---
dependencies:
- { role: wheel, n: 1 }
- { role: wheel, n: 2 }
- { role: wheel, n: 3 }
- { role: wheel, n: 4 }

wheel 角色的 meta/main.yml 文件包含如下内容:

---
allow_duplicates: yes
dependencies:
- { role: tire }
- { role: brake }

最终的执行顺序是这样的:

tire(n=1)
brake(n=1)
wheel(n=1)
tire(n=2)
brake(n=2)
wheel(n=2)
...
car

在 Roles 中嵌入模块

这是一个高级话题，应该只有少数的 Ansible 用户关心这一话题。

If you write a custom module (see Developing Modules) you may wish to distribute it as part of a role. Generally speaking, Ansible as a project is very interested in taking high-quality modules into ansible core for inclusion, so this shouldn’t be the norm, but it’s quite easy to do.

A good example for this is if you worked at a company called AcmeWidgets, and wrote an internal module that helped configure your internal software, and you wanted other people in your organization to easily use this module – but you didn’t want to tell everyone how to configure their Ansible library path.

Alongside the ‘tasks’ and ‘handlers’ structure of a role, add a directory named ‘library’. In this ‘library’ directory, then include the module directly inside of it.

Assuming you had this:

roles/
   my_custom_modules/
       library/
          module1
          module2

The module will be usable in the role itself, as well as any roles that are called after this role, as follows:

- hosts: webservers
  roles:
    - my_custom_modules
    - some_other_role_using_my_custom_modules
    - yet_another_role_using_my_custom_modules

This can also be used, with some limitations, to modify modules in Ansible’s core distribution, such as to use development versions of modules before they are released in production releases. This is not always advisable as API signatures may change in core components, however, and is not always guaranteed to work. It can be a handy way of carrying a patch against a core module, however, should you have good reason for this. Naturally the project prefers that contributions be directed back to github whenever possible via a pull request.