Enhancing Ansible Playbooks with Tags

Problem

Managing large Ansible playbooks can be cumbersome and time-consuming, especially when executing the entire playbook for development or regular operations. This inefficiency is particularly noticeable during development, where rapid testing of specific playbook parts is necessary, or in production, where operations may demand varying execution frequencies.

Solution

Enhance the flexibility and manageability of your playbooks by implementing a structured and meaningful tagging scheme for Ansible roles and tasks. By adopting a well-defined tagging approach, you can efficiently handle common setup and configuration stages pertinent to deployment processes.

Tagging Scheme

Consider adopting the following tagging strategy for task execution timing and operational levels:

Additional specific module tags or customized tags can be included as per unique requirements.

The advantages of a clear tagging scheme include:

• Flexibility: Seamlessly run specific segments of deployment or maintenance processes.
• Maintainability: Simplify the understanding and upkeep of playbooks with clear tags.
• Reusability: Adapt roles for various operational requirements without modifying the role itself.

Example and Implementation

1. In the tasks/main.yml file of the c2platform.core.secrets  role, note that tasks are tagged with the special Ansible tag always. This ensures that essential secrets, such as passwords in Ansible Vault , are always available. Another role using the always tag is the Ansible Certificates / CA role c2platform.core.cacerts2  , where it ensures the execution of “facts” tasks (e.g., in tasks/certs.yml).

2. Review the files tasks/main.yml and tasks/main_base.yml of the Ansible Windows role c2platform.wincore.win  . In main.yml, all tasks are tagged with install, system, and win.

   ---
   - name: Include Windows system installation tasks (install, system, win)
     ansible.builtin.import_tasks: main_base.yml
     tags: [install, system, win]
   

3. In the Ansible FME Flow role c2platform.gis.fme_flow  in the file tasks/main.yml, the following code is found:

   - name: Include role win
     ansible.builtin.import_role:
       name: c2platform.wincore.win
       tasks_from: main_base
     vars:
       win_resources: "{{ fme_flow_win_resources }}"
       win_resources_types: "{{ fme_flow_win_resources_types }}"
       win_resource_groups_disabled: "{{ fme_flow_win_resource_groups_disabled }}"
     tags: [config, application, fme_flow]
   

   The code incorporates the Windows role into the FME Flow role and tags all tasks with config, application, and fme_flow. Note the use of import_role. Using include_role instead of import_role results in different behavior regarding task tagging.

   Consider this simple FME play:

   - name: FME
     hosts: fme
   
     roles:
       - { role: c2platform.wincore.win }
       - { role: c2platform.gis.java }
       - { role: c2platform.gis.fme_flow }
   

   This play includes the Windows role directly as c2platform.wincore.win and indirectly via c2platform.gis.fme_flow with different tags.

For implementation examples and further guidance, please refer to the Linux tagging example Using Tags with the Linux Play or for a more comprehensive example see Accelerating Ansible Provisioning with FME Flow using Ansible Tags . For additional reference and information about Ansible tags see Tags — Ansible Community Documentation 

Footnotes