Ansible Tags

For long playbooks, it is useful to be able to run subsets of the tasks in the playbook. To do this, tags can be set on specific resources as a text label. Tagging a resource only requires that the tags keyword be used, followed by a list of tags to apply. When plays are tagged, the –tags option can be used with ansible-playbook to filter the playbook to only execute specific tagged plays.

Tags are available for the following resources:

  • In playbooks, each task can be tagged, using the tags keyword:

  • When a task file is included in a playbook, the task can be tagged, allowing administrators to set a global tag for the include statement:

Note
When tagging a role or an include statement, all tasks they define are also tagged.

Important

When roles or include statements are tagged, the tag is not a way to exclude some of the tagged tasks the included files contain. Tags in this context are a way to apply a global tag to all tasks.

 

Managing tagged resources
When a tag has been applied to a resource, the ansible-playbook command can be used with the –tags or –skip-tags argument to either execute the tagged resources, or prevent the tagged resources from being included in the play. The following playbook contains two tasks. The first one is tagged with the production tag, the other one does not have any tag associated with it:

To only run the first task, the –tags argument can be used:

Because the –tags option was specified, the playbook only ran one task, the task tagged with the production tag. To skip the first task and only run the second task, the –skip-tags option can be used:

 

Special tags
Ansible has a special tag that can be assigned in a playbook: always. This tag causes the task to always be executed even if the –skip-tags option is used, unless explicitly skipped with –skip-tags always.

There are three special tags that can be used from the command-line with the –tags option:
1. The tagged keyword is used to run any tagged resource.
2. The untagged keyword does the opposite of the tagged keyword by excluding all tagged resources from the play.
3. The all keyword allows administrators to include all tasks in the play. This is the default behavior of the command line.

 

Example 1. Selectively Run Specific Tasks In Playbooks Using Tags

The playbook has two tasks. First copy inde html to the managedhost1 and is tagged as webdeploy. Second copy sql script to the managedhost2 and is tagged as dbdeploy.

You can run only first or only second tasks using a tags:

And second task:

You can even use --skip-tags parameter to only run plays and tasks whose tags do not match these values.

 

Example 2.

Create the prepare_db.yml task file and define a task that installs the required services for the database. Tag the task as dev, and have it notify the start_db handler.  Define a second task to retrieve the database configuration file if the dev tag is active in the execution environment, and that restarts that database service. The task will use a conditional to ensure the configuration file path is defined. Define a third task to retrieve a different database configuration file if the prod tag is active in the execution environment, and that restarts the database service. Like the previous task, this task will use a conditional to ensure that the configuration file path is defined.  Define a task that sets the Message of The Day for the managed host. Tag the task with the dev task. Repeat the previous step but change both the tag as well as the command (dev to prod).

When completed, the task file should read as follows:

In the project directory, create the main playbook, playbook.yml for servers in the databases group. The playbook will define the variables required by the task file upon import. Define the first task that includes the task file; the task file will use a conditional to ensure the managed host is in the group databases. Define the two handlers the task file requires, start_db and restart_db.

When completed, the playbook should read as follows:

Run the playbook, applying the dev tag using the –tags option.

Notice the configuration file that has been retrieved (my.cnf.small).

Run an ad hoc command to display the /etc/motd file on servera.

Run the playbook again, this time skipping the tasks tagged as dev:

Run an ad hoc command to display the /etc/motd file on servera.

 

Example 3.

In the project directory, create the configure_mail.yml task file. The task file contains instructions to install the required packages for the mail server, as well as instructions to retrieve the configuration files for the mail server.
Create the first task that uses the yum module to install the postfix package. Notify the start_postfix handler, and tag the task as server using the tags keyword. Add a task that installs the dovecot package using the yum module. It should notify the start_dovecot handler. Tag the task as client. Define a task that uses the get_url module to retrieve the Postfix configuration file.
Notify the restart_postfix handler and tag the task as server.

When completed, the task file should read as follows:

Create a playbook file named playbook.yml. Define the playbook for all hosts. Define the task that includes the task file configure_mail.yml using the include module. Add a conditional to only run the task for the hosts in the mailservers group. Define the three handlers the task file requires: start_postfix, start_dovecot, and restart_postfix. Define start_postfix handler to start the mail server. Define the start_dovecot handler to start the mail client.  Define the restart_postfix handler that restarts the mail server.

When completed, the playbook should read as follows:

Run the playbook, only applying the server tagged tasks using the –tags option. Notice how only the start_postfix handler gets triggered.

Run an ad hoc command to ensure the postfix package has been successfully installed.

Run the playbook again, but this time skip the tasks tagged with the server tag. The play will install the dovecot package, because the task is tagged with the client tag, and it will trigger the start_dovecot handler.

Run an ad hoc command to ensure the dovecot package has been successfully installed.