Variables can account for differences between your target hosts.
So by using variables,
we can use abstraction in our playbook, and you can define
variables in several ways. So variables allow you to remove
site‑specific information from your playbooks. Variable precedence
is the order in which the same variable will override, and there
are several levels of precedence.
So if you're setting variables in your inventory,
other variables higher up in the presentation there,
such as the playbook, will override them. Then we have Ansible
modules. Modules are considered to be the workhorse of Ansible,
along with plugins. Each module does one job well, and this is to
ensure the desired state.
So we have simple tasks, and with tasks, we are telling the modules to do
something specific, such as install packages and then check that the
package is present on the target machines that are listed in your Ansible
inventory. So we have loads of different modules to use, and most of them
are idempotent. Modules can also be better managed with the use of
Ansible collections.
We have normal tasks that run sequentially, and then we have
handler tasks that only run on a notification.
Handlers are run only once at the end of the play regardless
of how many times they have been triggered, and there needs
to be a change in the state, such as pushed out a config file for the first time.
So playbooks, at a basic level, are a list of tasks. Tasks
string together to form a desired state, and we know this
desired state is done with modules.
So we may have a vars section to play where we are
setting‑site specific information.
For example, you can set the HTTP port and the max client connection
for a playbook installing and starting Apache.
In this case, when considering variable preference, we're defining
variables right in the play, so the variable precedence chain is
directly in the playbook. We could also define these variables in
inventory or an extra var runtime or in Ansible Tower via surveys, and
we will look at this very soon.
We also need to specify a connecting user and any privilege
escalation methods that may be needed to perform the tasks on
the target hosts in your inventory.
So in Ansible, we need to do what's known as become. So
here we have the correct privileges to become and carry
out the necessary Ansible tasks.
So before we get into the first demo, I would just like to introduce you to
some of the Ansible Tower basics, so to reach out to managed machines that
are listed in your inventory which can be static,
manually updated, or dynamic, which is dynamically updated.
Ansible Tower has a similar approach to manage machines that it
does with the Ansible Core and the CLI version.
So we first need to identify the managed machines, and this is done on the
Tower host, and we set up the etc hostname resolving our DNS.
This lets a Tower host find the machines. And a good way to test
this is to ping the hostname of the target host.
So on the managed host,
we need to make sure we have SSHD running, and it must be
able to accept incoming connections.
So there may be some firewall rules that you need to
adhere. Also, on the managed host,
there needs to be a user account with sudo privileges.
In these demos, I have set up a user, and I've called this pluralsight1.
It would also be best if you set up a password, even for a
demo environment, and optionally SSH keys.