具有不尊重标签的标签的可选角色，而是扮演所有定义的任务

Question

这是我的攻略：

- name: Install MySQL with replication
  hosts: mysql-master:mysql-slave
  user: root
  sudo: false
  roles:
    - common
    - admin-users
    - generic-directories
    - { role: iptables, tags: [ 'mysql-iptables'] }
    - mysql

我有不同端口的ip表任务，我想根据服务器组运行任务。

我已经根据组标记了iptables任务。当我运行实战手册而不是播放标记的任务时，它将遍历iptables角色中定义的所有任务。

如果我做错了什么，请让我知道。

Answer 1

在实践中，角色不应该包含仅由您使用的代码/配置。尝试开发角色，例如，如果您要发布它们，这样做将创建更多通用/有用的角色

对于iptable角色，您最终想要的是打开端口/更改防火墙配置。角色应包含允许在行动手册中进行配置的任务：

---
- name: iptables | Open ports
  command: 'open port {{item.protocol}} {{item.port}} 
  with_items: 'iptable_conf'
  tags:
   - iptables

然后你的行动手册

- name: Install MySQL with replication
  hosts: mysql-master:mysql-slave
  user: root
  sudo: false
  vars:
    - iptables_conf: 
       - {protocol: tcp, port: 3307}
       - {protocol: tcp, port: 3306}
  roles:
    - common
    - admin-users
    - generic-directories
    - iptables
    - mysql

Answer 2

希望你一直都喜欢独断专行的软件：https://github.com/ansible/ansible/issues/3283。

如果我没看错的话，您正在体验一项功能，该角色中的所有内容都会为您标记，并且您的CLI标记规范随后会匹配所有这些任务。我讨厌这个功能。这太愚蠢了。当你最初接触Ansible标签时，“应用程序”与“选择”对标签的影响是一个显而易见的第一个问题。它应该有一个更灵活的答案，或者至少在文档中点头。

我会建议一种不同的方式来组织多功能的iptables角色。首先，如果它包装的任务数量非常少，请考虑不使用该角色。我建议角色对你有意义，而不是模块适配器。因此，sql角色也许可以在单独的任务文件中处理特定于sql的规则。

否则，一个角色参数，然后可用于动态加载变量(例如防火墙规则列表)。这就是它的样子，去掉了：

攻略：

---
- hosts: loc
  roles:
    - { role: does-too-much, focus_on: 'specific-kind' }

角色任务/main.yml：

---
 - include_vars: "{{ focus_on }}.yml"
 - debug:
     msg: "ok - {{ item }}"
   with_items: stuff

变量vars/specific-kind.yml：

---
stuff:
 - b
 - c