Now the anatomy of the Ansible Playbook.
The top‑level elements are the plays,
and you could have one or n number of plays within a playbook.
We're subject to the same YAML rules as we always are.
Within each play, you have one or more tasks.
Within those tasks,
you're going to invoke your module and what it is within
that module that you're activating.
Jinja syntax is used for variable interpolation,
so notice that we've got double quoted double curlies
we can put in a variable in there.
And then at runtime, Ansible will resolve those variables.
Conditional logic, again,
thanks to the Jinja templating engine where we could have a
particular task step do one thing or the other depending
upon the state of the system.
Speaking of state,
there's a technique in Ansible Playbooks where you can capture the output.
It's actually up in the middle of the slide.
If you look under that first task where it says notify restart service,
what that's actually doing is capturing the console output from
that operation and storing it in a variable that you now can invoke
by using, as you can, see a reference to that object. That's under
a section called Handlers.
This is the basics. It gets more complex than this.
But hopefully you're thinking, wow,
this is a lot simpler than I thought. That I swear is the main theme of Ansible,
an elegant, thoughtfully designed, cross‑platform,
free, and open source configuration management engine.