So unlike the use of ad hoc commands,
playbooks allow you to run multiple modules with
conditionals and other processing.
This really does open up automation to you.
So in the playbook we have hosts and variables, then we can have tasks to run.
Playbooks are written in YAML and indentations used to identify the
relationship between parent and child objects.
These are specified as key‑value pairs.
Items that are children are indented more than parents.
If a specific module argument can have multiple values,
these values start with a hyphen, and these are known as arrays.
So relationships are defined using indentations,
with spaces and not tabs; and task properties are defined using key‑value pairs.
So in this demo,
we're going to create a playbook with single tasks and multitasks,
we'll also have a playbook with multiple plays,
and we'll finally demonstrate how to disable fact gathering.
The following is a minimal play header where we specify a name,
the host that a play runs on, and the task that needs to be executed.
Here notice the child and parent relationship by using indentation.
So in this playbook we have two tasks where we install a package,
and then we start and enable the package.
The package is httpd, and the state will be latest and started.
To run a playbook, we issue the ansible‑playbook command.
You can see that we're running the playbook and also performing fact gathering.
But in this playbook we're not using facts for these playbooks,
so we could disable this if we wanted to.
Facts can be used as variables in your playbooks,
but if you're not going to use them,
you may want to disable the process of fact gathering
to speed up the playbook execution.
You can, however, also have a fact cache; although,
this may have some drawbacks.
First it completes task one and then it completes task two.
But as you can see, the Ubuntu host has failed,
and you should know why this has as Ubuntu only supports Apache and not HTTPD.
So let us quickly edit the playbook and run this only on the Ubuntu host.
So we now have two tasks, but we're only running on one host.
And notice the change status that we have.
So what might have been useful,
if I ran a dry run on the first playbook where the
play failed in the Ubuntu host,
we could have done this by issuing a capital C argument.
This is a great way to test playbooks before you run them.
By composing a playbook of multiple plays,
it's possible to orchestrate multi‑machine deployments.
So we can have multiple plays in the same playbook to run on different hosts.
Notice the indentation of the second play is
actually the same as the first play.
Different target hosts will need different plays.
So we have multiple plays.
The play is an array _____ item in the playbook,
and every play starts with a hyphen.
So we have the hosts and the task in the play header,
and this is what we need for a minimal play.
In our case, we're not going to use any variables,
and we're also not going to use anything from the fact gathering,
so we can disable fact gathering if you want to.
So keep in mind, if you're running a playbook on a local host,
you might not need fact gathering or privilege escalation.
In this case, we could have the become equals false.
So notice here, we're using Booleans.
So the Boolean you can have different ways of saying the same thing.
We can have no and true and false, also upper or lowercase.
In our case, we're going to have gather facts equals no.
So keep in mind that facts are discovered variables.
We also have magic variables.
These are system variables that exist by default.