Okay.
Now to run the playbook, we'll use ansible‑playbook.
This is, again, one of the Ansible CLI commands.
And the name of the playbook is test_pb.yml.
Now there's additional things, parameters, that we can add.
We know that we can do ansible playbook ‑‑help.
So you can read up on that syntax.
And we could actually use the i parameter if we had a custom inventory.
I don't want to over teach and oversell.
In the meantime, let's just run this playbook.
This is a very important screen what we're seeing because this is the
console output from the ansible‑playbook command.
And it's going to give us these separators here that, for each play,
in this case one play with multiple tasks.
I think I misspoke a few minutes ago when I said there are three plays.
There is just the one play.
I don't know what I was thinking.
But for each task, notice that first gathering facts.
This is where Ansible is gathering metadata about how these machines are set up.
In particular,
a fatal error occurred when Ansible tried to contact my node1 machine.
So this is important for us to have.
And the fact that this seems to be be doing some work,
particularly on my control1 node, but failing elsewhere
might lead you to start biting your nails.
No, the Ansible system,
the Ansible configuration management system, is idempotent.
If you're familiar with how Azure Resource Manager or Bicep
deployment templates work in the Microsoft Azure cloud,
it's the same idea.
So there's no harm in us iteratively tweaking that playbook and
rerunning ansible‑playbook because any machines that are already
in the desired state will be untouched.
You see. So that's actually fine.
Ansible definitely lives out a lot of the promises
of DevOps in terms of fail fast, fix fast,
that sort of thing.
Okay, so eventually, we get this play recap or the summary where we can see
at a glance. I guess there's some color coding going on.
But frankly,
I'm color blind, so it's not helpful to me. But I hope it's helpful to you.
So our control machine had seven ok events,
three items were changed, everything zero. That's looking good.
And we saw that node1 is in a problem state here, unreachable.
So we can see each of those steps completing.
And I'll bet you if we open up a PowerShell console on my host machine,
if I do a get‑service on spooler, yeah, it stopped.
Sure enough.
And the idea is if I were to now start the service, that service would start.
But the beauty of Ansible is that you may have the
playbooks running on a schedule.
So the idea is the longest the machine or a host will be out of
compliance will be until the next time you run the playbook and
it performs remediation for you.
We'll pick up on this in the next module.