Let's talk about why you should use tags in your Ansible playbooks. For starters, I'll lecture you a bit about tags in the Ansible language and then show you how we use them in a real-life scenario.
Ansible is a great automation and configuration tool, built with simplicity and idempotency in mind. And like all in this world, it comes with a price tag: Ansible language is simple, not to say minimalistic in terms of the control structures. Of course, you immediately refute me and say that you can do all that in Ansible, and you would be correct. Ansible has its ways to compensate for missing constructs and develop some quite sophisticated scenarios.
Plus, Ansible gives you tags, another unique and quite powerful way to control the execution. You can put a label or labels on tasks, roles, and plays. The tag value could be any valid string. Just keep in mind there are few reserved words - always and never and I do not recommend use words tagged and untagged for tags as well. Let's use a small example to illustrate how it looks like:
Now, let's see how we tags alter the playbook outcome.
# Run all tasks and plays in the book ansible-playbook system-start.yml # Start all systems ansible-playbook system-start.yml --tags start # Start HTTP Server only ansible-playbook system-start.yml --tags http,start # Same as previous ansible-playbook system-start.yml --skip-tags database
Special usage tags:
- always - Ansible always executes the task, regardless of the specified tags in --tags and --skip-tags arguments.
- never - Engine will skip the task, ignoring the --tags and --skip-tags arguments.
- untagged - Not a tag, but with -- tags untagged, Ansible will execute all tasks with no tags.
- tagged - Opposite to the previous one. With --tags tagged, the engine picks a task if it has any tag.
Special tags (especially never) are pretty handy when you have something that you execute only on a special occasion. For example, I have an Oracle WebLogic configuration play with the tasks like this:
In the example above, play "Drop RCU Domain" will never be executed until I say so. It assures me that I wouldn't drop all my database artifacts by chance. Now, if I decide to re-create my WebLogic domain, I run this playbook with tags:
There are more fine details on using tags with roles or imported tasks, but you already have a general idea of how valuable tags for your projects. One more tag-related tip:
- --list-tags - List all tags from the playbook. Quite useful to understand what you can specify for the play.
- --list-tasks - the command itself shows you the list of tasks in the playbook, but in combination with --tags or --skip-tags, it gives you a heads up on what Ansible will execute from your playbook.
One of the most common playbooks we run - is the control playbooks. They are designed to start/stop or restart a specific system, with all sequences and validations we need. To add some flexibility, I created separate plays to manage domain components individually. You don't need to know all the WebLogic domain details to understand this example, but the precedence of commands is important for the result, and you can't bring up the next component without the previous one.
Let me show the playbook structure, and then we discuss how to use it.
Now, let see how I use playbooks
# Restart Domain ansible-playbook wls-domain-ctl.yml # Stop Domain ansible-playbook wls-domain-ctl.yml --tags stop # Start Domain. ansible-playbook wls-domain-ctl.yml --tags start # Start AdminServer only ansible-playbook wls-domain-ctl.yml --tags nm-start,admin-start,stop
Properly arranged plays give you the most common control activity for the information system - restart. As a bonus, if the system was down, it will be started if you run playbook as is.
Every play bears a start or stop tag, so if I want to bring down the domain for the maintenance, I use only one tag for it.
If I need to start only the Admin Server, I make sure that the domain went down and specify component-branded tags for the start sequence. This command also illustrates that I can list tags in any order; Ansible will select and execute tasks in the playbook precedence order.