Ansible Playbook Roles and Include Statements

huhahapz

　　New in version 1.2.
　　现在你已经了解了任务和处理程序，组织你的剧本的最好方式是什么？ 简单的答案是使用角色！ 角色是基于已知文件结构自动加载某些vars_files，任务和处理程序的方法。 按角色分组内容还可以轻松地与其他用户共享角色。
　　角色只是围绕'include'指令自动化，如上所述，除了对引用文件的搜索路径处理进行一些改进之外，真的不包含太多额外的魔法。 但是，这可以是一件大事！
　　示例项目结构：
　　

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
　　这为每个角色“x”指定了以下行为：
　　

• 如果roles/ x / tasks / main.yml存在，其中列出的任务将添加到play中
  
• 如果roles/ x /处理程序/ main.yml存在，列出的处理程序将被添加到play中
  
• 如果roles/ x / vars / main.yml存在，其中列出的变量将被添加到play中
  
• 如果roles / x / defaults / main.yml存在，其中列出的变量将被添加到play中
  
• 如果roles / x / meta / main.yml存在，其中列出的任何角色依赖将被添加到角色列表（1.3和更高版本）
  
• 任何副本，脚本，模板或包含任务（在角色中）都可以引用roles/ x / {文件，模板，任务} /（目录取决于任务）中的文件，而不必相对或绝对地路径
  

　　在Ansys 1.4及更高版本中，您可以配置一个roles_path来搜索角色。 使用它来检查所有常见角色到一个位置，并在多个playbook项目之间轻松分享它们。 有关如何在ansible.cfg中进行设置的详细信息，请参阅配置文件 。
　　如果任何文件不存在，它们将被忽略。 例如，一个没有'vars /'子目录的角色是可以的。
　　请注意，您仍然可以在不使用角色的情况下将任务，vars_files和处理程序“松散”列入剧本，但角色是一个很好的组织功能，并被强烈推荐。 如果剧本中有松散的东西，首先评估角色。
　　此外，如果您希望参数化角色，通过添加变量，您可以这样做：
　　

---　　

　　
- hosts: webservers
　　roles:
　　- common
　　- { role: foo_app_instance, dir: '/opt/a',  app_port: 5000 }
　　- { role: foo_app_instance, dir: '/opt/b',  app_port: 5001 }
　　虽然这可能不是您经常应该做的事情，但您也可以有条件地使用如下角色：
　　

---　　

　　
- hosts: webservers
　　roles:
　　- { role: some_role, when: "ansible_os_family == 'RedHat'" }
　　这通过将条件应用于角色中的每个任务来起作用。 条件稍后将在文档中介绍。
　　

最后，您可能希望为您指定的角色分配标签。 你可以这样内联：　　

---　　

　　
- hosts: webservers
　　roles:
　　- { role: foo, tags: ["bar", "baz"] }
　　请注意，此标记将使用指定的标记标记该角色中的所有任务 ，覆盖角色中指定的任何标记。 如果您发现自己构建了许多标签的角色，并且希望在不同时间调用角色的子集，那么您应该考虑将该角色分解为多个角色。
　　如果play仍然有“task”部分，这些任务在应用角色后执行。
　　

　　如果要在应用角色之后定义某些任务发生在AND之前，您可以执行以下操作：
　　

---　　

　　
- hosts: webservers
　　

　　pre_tasks:
　　- shell: echo 'hello'
　　

　　roles:
　　- { role: some_role }
　　

　　tasks:
　　- shell: echo 'still busy'
　　

　　post_tasks:
　　- shell: echo 'goodbye'
　　

Role Default Variables
　　1.3版新功能
　　角色默认变量允许您为include或依赖的角色设置默认变量（见下文）。 要创建默认值，只需在您的角色目录中添加一个defaults / main.yml文件。
　　这些变量将具有可用的任何变量的最低优先级，并且可以容易地被任何其他变量覆盖，包括库存变量。

Role Dependencies
　　1.3版新功能
　　角色相关性允许您在使用角色时自动拉入其他角色。 角色依赖关系存储在包含在角色目录中的meta / main.yml文件中。 此文件应包含要在指定角色之前插入的角色和参数列表，例如role / myapp / meta / main.yml中的以下内容 ：
　　

---　　
dependencies:
　　- { role: common, some_parameter: 3 }
　　- { role: apache, apache_port: 80 }
　　- { role: postgres, dbname: blarg, other_parameter: 12 }
　　角色依赖也可以指定为完整路径，就像顶级角色一样：
　　

---　　
dependencies:
　　- { role: '/path/to/common/roles/foo', x: 1 }
　　角色依赖关系还可以从源代码控制repos或tar文件（通过galaxy ）使用逗号分隔格式的路径，可选版本（标签，提交，分支等）和可选的友好角色名称（尝试导出角色名称从repo名称或归档文件名）。 通过命令行或通过require.yml传递给ansible-galaxy。
　　角色依赖性始终在包含它们的角色之前执行，并且是递归的。 默认情况下，角色也只能作为依赖关系添加一次 - 如果另一个角色也将其列为依赖关系，则不会再次运行。 可以通过向meta / main.yml文件添加allow_duplicates ：yes来覆盖此行为。
　　例如，名为“car”的角色可以向其依赖关系添加名为“wheel”的角色，如下所示：
　　

---　　
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
　　

Embedding Modules and Plugins In Roles
　　这是一个与大多数用户不相关的高级主题。
　　这是一个与大多数用户不相关的高级主题。
　　如果您编写自定义模块（请参阅开发模块 ）或插件（请参阅开发插件 ），则可能希望将其作为角色的一部分进行分发。 一般来说，Ansible作为一个项目非常有兴趣将高质量的模块引入到可插拔的核心中，所以这不应该是规范，但很容易做到。
　　一个很好的例子是，如果您在一家名为AcmeWidgets的公司工作，并写了一个内部模块，帮助您配置内部软件，并希望组织中的其他人轻松使用此模块，但您不想告诉大家如何配置其可执行库路径。
　　除了角色的“任务”和“处理程序”结构之外，还添加一个名为“library”的目录。 在这个'库'目录中，直接在其中包含模块。
　　假设你有这个：
　　

roles/　　my_custom_modules/
　　library/
　　module1
　　module2
　　该模块将可用于角色本身以及此角色之后调用的任何角色，如下所示：
　　

- hosts: webservers　　roles:
　　- my_custom_modules
　　- some_other_role_using_my_custom_modules
　　- yet_another_role_using_my_custom_modules
　　在某些限制下，还可以使用Ansible核心分发中的模块进行修改，例如在生产版本发布之前使用模块的开发版本。 然而，这并不总是可取的，因为API签名可能在核心组件中发生变化，但并不总是保证工作。
　　对于核心模块来说，它可以是一个方便的补丁，但是如果你有这个好的理由。 自然，该项目倾向于通过拉动请求将贡献引导回github。
　　

　　可以使用相同的机制将插件嵌入和分配到角色中，并使用相同的模式。 例如，对于过滤器插件：
　　

roles/　　my_custom_filter/
　　filter_plugins
　　filter1
　　filter2
　　然后可以在模板或jinja模板中使用任何角色“my_custom_filter”