So let's continue with our journey on playbook modularity. And
as playbooks get bigger and more complex,
it's common practice to use modularity and not just by using roles, but
by also using includes and imports. Roles do have a similar function, but
imports and includes have better structure.
So you can have includes and imports for roles, plays, tasks, and variables.
So the include is a dynamic process, an Ansible processes that
included file contents. At the moment, this include is reached.
The use case is for conditionality. You only want to run it when
certain conditions are true.
So for the process of import, we have various ways such as include tasks.
This could be another playbook.
They are processed as encountered during the playbook execution and are
dynamic most notably when using the when statement.
We also have import tasks.
It looks the same,
but all import statements are pre processed at the time the
playbooks are parsed, and these are known to be static.
So we can also import playbooks.
You could actually have a playbook that doesn't have any task, and it can go
directly into the import playbook of another playbook.
So if you have large playbooks, it may be useful to run only specific
parts instead of running the entire playbook. Here,
we can use Ansible tags.
Ansible allows you to add one or more tags to a task or even a play.
You can add tasks to tasks in playbooks, in task files or within a role.
So consider a tag to be like a label that can be used in the
playbook to identify specific playbook elements.
This then allows you to run specific parts of the
playbook and not all of the playbook.
So as I mentioned in the first module, tags are really useful in
playbook development to skip parts that have proved to be working okay.
So let's say you're in the middle of playbook development and we have
several teams that are working on the different playbook elements. So
some of the parts of the playbooks will be known to be working while
others are not.
So we could have a pretty big playbook here with over 100 lines.
So you could have a number of sections with tags, and these tags can
be used to test different parts of the playbook.
Then we can use the ‑t tag names. That will tell Ansible only
to run plays and tasks with certain tags.
We also have the ‑skip tags. That can flag to Ansible to
skip plays or tasks with certain tags.
So we can run everything, but a particular part of the playbook. Keep in mind,
by default, all tasks are assigned to the default tag of all.
We also have what's known as start at task.
This command module can get Ansible to start on a specific task.
You can also run multiple tasks such as installing NGINX and restarting NGINX.
So we can use tags to execute our skip selected tasks.
It really is a two‑step process.
We add the tags to our tasks,
either individually or with tag inheritance from a block, play, role or import.
Then you can either select or skip tags when you run your playbook.
You can add tags to a single task or even include.
You could also add tags to multiple tasks by defining them
at a block, play, role or import level.
The keyword tags addresses all of these use cases and gives you a lot of
flexibility in how you can apply tags for your environment.
You can also apply tags to dynamic includes in a playbook.