CentOS

Using Tags in Ansible Playbook

Tags are basically metadata that are attached to the tasks, roles, plays, etc. Using tags has a big advantage in saving time on and simplifying the running and debugging jobs of playbooks. It also makes the playbook more organized and robust.

What Will We Cover?

In this guide, we will see how to use the tags with Ansible playbooks. We also see some basic examples to demonstrate the tags in action wherever necessary.

What Will You Need?

As our previous labs, we need to have the following requirements to perform the examples shown in this tutorial:

1. You should have an installed Ansible on the controller node (Ubuntu 20.04 in our case).

2. You should have a basic knowledge about what the purpose of Ansible is and how to write a playbook (and of course you need to know what a playbook is).

If you are just starting to learn Ansible, we suggest that you first learn Vagrant and how to set up a basic local testing environment using Vagrant. Once you set up a basic lab consisting of one controller node and two target nodes, you are all set to perform these examples.

Need of Tags in Ansible

In many cases, you may want to run a specific part of a playbook instead of executing the entire playbook. This is very handy in cases where the playbook is very large. In such cases, tags are used to run or skip a task in a playbook. This is done in a two-step approach:

1. Add the desired tags to the target tasks.

2. Run or skip the tasks on the basis of the tags options.

A tag can be defined for a task, block, role, or for an entire play. The “tags” keyword is used for defining a tag as we will soon see in the subsequent examples.

Working with Tags

1. Starting with the Basic Example

In its most basic form, a single task can have one or more tags. Similarly, a common tag can be linked to more than one task. For example, consider the following playbook:

---

- hosts: all

gather_facts: yes

become: true

tasks:

- name: Update the system repository information (‘apt-get update’)

ansible.builtin.apt:

update_cache: yes

tags: ubuntu

- name: Run the equivalent of ‘apt-get dist-upgrade’ to upgrade the system as a separate step

ansible.builtin.apt:

upgrade: dist

tags: [ ubuntu, distup ]

- name: Install the apache web server and ntp program

ansible.builtin.apt:

name:

- apache2

- ntp

state: present

tags:

- ntp

- webservers

- ubuntu

- name: Restart apache

ansible.builtin.service:

name: apache2

state: restarted

tags:

- ubuntu

- RestartApache

There are four tasks in the given playbook:

1. The first task has only one tag, while the others have more than one.

2. The “ubuntu” tag is a common one and is linked with all the four tasks.

Using a tag for multiple tasks (tag reuse) executes all the tasks linked with that tag. For this, the “—tags” flag is specified at the command line.

Suppose we have already run the previous playbook once and when we want to only restart the apache service and do nothing with the other tasks. In this case, we have to run the playbook (our my-playbook.yml) in the following manner:

$ ansible-playbook myplaybook.yml -i /path/to/inventory/file --tags RestartApache

2. Skipping a Tag in a Playbook

In cases where you want to skip a task from execution, Ansible provides you with the “–skip-tags” parameter. The rest of the playbook normally runs. In the previous example, let us ignore the task of upgrading the system (task:2). For this, the “ansible-playbook” command is modified as:

$ ansible-playbook myplaybook.yml -i /path/to/inventory/file --skip-tags distup

3. The ‘always’ and ‘never’ Tags

Ansible has two reserved tags for two specific purposes. These are the ‘never’ and ‘always’ tags. The purpose of the ‘always’ tag is to always run the task it is linked with. The ‘never’ tag is opposite of the ‘always’ tag which skips the task it is linked with. The following example demonstrates this:

---

- hosts: all

gather_facts: yes

become: true

tasks:

- name: The Ansible 'always' tag example

debug:

msg: "I will be always shown here"

tags:

- always

- name: The Ansible 'never' tag example

debug:

msg: "I will never shown up until you specifically allow me"

tags:

- never

In the previous playbook, the first task is set to always run while the second is set to never run.

In case we want to skip the task tagged with “always”, we have to explicitly specify this behavior on the command line as “–skip-tags always”. In the previous playbook, we can skip the first task as:

$ ansible-playbook myplaybook.yml -i /path/to/inventory/file --skip-tags always

Similarly, a task with the “never” tag will never run unless it is tagged as “–tags never”. The second task can be executed as:

$ ansible-playbook myplaybook.yml -i /path/to/inventory/file --tags never

Conclusion

It is very critical to develop a well-structured playbook for imparting flexibility in the automation process. Like many other ways, Ansible provides tags to achieve this feature.

Similar Posts