Now, whilst our ad‑hoc commands are very good for quick configuration,
they're not good for repeatable configuration.
Imagine trying to remember everything that we've done from the command line,
but by making use of playbooks,
we can record the desired state and replay it in a reliable manner.
So we're going to do this moving into our Ansible directory and
creating our playbook. We'll see more on creating our playbook later,
but our playbook contains a list of plays. Within a play, we're going
to have a list of tasks. Here,
we've got just one task. We're running our package module, ensuring that the
package tree is installed. And when we're ready to execute it, by running
our playbooks, we use the ansible‑playbook command, and we can check the
integrity of the file in various ways.
We can run our ansible‑playbook command against the playbook.yml to
check its syntax. We can run it, but with ‑C, so this is a check
operation, so it doesn't actually do anything, and we can even go
through list tasks that would run again.
We're not actually doing anything, but it's a way of seeing
what tasks we've got inside of our playbook.
But if we do want to execute it, then it's as simple as this, because all
of the complexity is inside of the playbook itself.
So we're going to dive out to our command line now where
we're going to write our YAML Ansible playbooks. We're
going to create the playbook, test the playbook, and then execute our playbook.
We're back working on the command line, and I'm in that Ansible
working directory. Remember that's important so we pick up the
correct configuration file and inventory.
We're going to create then our playbook. I'm just going to call it
playbook.yml, but obviously, the name doesn't matter,
but being descriptive helps.
The three dashes is the header information.
We can then have a list of plays.
The names for the plays ideally should be descriptive,
but this is just a demonstration. List items always start with a dash. We can
specify the hosts that we want to operate on, and again,
I'm going to use that same built‑in group, all. We can elevate our
privileges with become, and then we have a list of tasks.
So we set up our tasks and colon. Now the default spacing is eight spaces
in Ubuntu. I'm happy to leave it at that just for the defaults, but
normally I would be using two spaces, but to show we're part of the tasks,
our task name is then indented below tasks.
Again, using a descriptive name,
lining up with a name, we specify the module we want to use, in
this case it's going to be package, and then indenting inside of
package, we're putting up then our name of the package to be true
and then the desired state, which we want to be present.
As I say,
I'm just using the default of Vim, but ideally, I think we
would just use two spaces, but this will still work. The key
is we don't want to be using tabs.
We can always check on that, and if we go through and save our file, we can
check it with cat, and cat ‑vet is always a quick way to check.
We can see the non‑printing characters, so the dollars at the
end of the line, but what we don't want is a Ctrl+I,
indicating that we've added an indent.
Having created the playbook,
we can execute it with the ansible‑playbook command. Put in the
playbook name, but if we want to double check,
we can go through and check our syntax and run the command
‑‑syntax‑check. No output like this is good.
It's showing that it's good to go. If we
up‑arrow‑key, having done our syntax check,
we can go through and specify that we need to authenticate using our SSH
password. I'd say ideally we would use keys. Instead of doing the syntax
check now, we can use the uppercase C to provide a check operation, and we
need to authenticate to our remote systems.
We're actually checking their current state, and we're
indicating what we would do. Now, of course then, tree is
installed so we wouldn't manage anything.
We'd just come back okay. So we don't do anything,
but we just say what would happen. And when we're finally ready to run,
we can then just remove the ‑C from the end and execute it. And we can
then go through and see we get a built‑in task running,
Gathering Facts, so that's just collecting variables about
our system, and then our task executes.
And again, we can see that we're meeting the required state,
so there was no need to install anything.
But we can just build up our playbook and run it any time we want to ensure our systems are configured the way that they should be.