Okay,
so we have a user called Gina that is using Ansible, and
she wants to configure three managed servers and wants
these servers to run a web service.
So she has written a script called webservers.yml. So in Ansible,
the equivalent of a script is called a Playbook.
So we have a Playbook now that describes which hosts, in some
cases Ansible calls this remote servers, to configure an ordered
list of tasks to perform on those hosts.
So in our examples, the hosts are Ubuntu, Rocky1, and Rocky2, and then we
have the tasks that need to be performed on these hosts.
So what will happen then is that the Ansible controller,
which could be a laptop, will generate a Python script and will
install the necessary packages for this web service.
It will then copy the script to the managed hosts, which will be Ubuntu,
Rocky1, and Rocky2, and then it will execute the script on Ubuntu, Rocky1,
and Rocky2. It will then wait for the script to complete execution on all
the hosts, and then Ansible will move to the next task in the list and go
through the same steps.
So it's important to note the following that Ansible runs
each task in parallel across all hosts.
Ansible waits until all hosts have completed a task
before moving to the next task.
Ansible runs a task in the order that you specify them.
So to run Playbooks,
we have the Ansible Playbook command, and this can be used with several
flags that can help you test the sanity of your Playbooks before you
actually execute the Playbook. For example,
we can do a dry test run or only run on specific parts of the
Playbooks by using tags, and tags are really good for Playbook
development if you have a really large Playbook. And you know that
certain parts of the Playbook are 100% working,
you can put tags on the things that you think are not working and
you can start running and testing the Playbooks just on the
sections that you think are not working.
So Ansible will make SSH connections in parallel to the managed host.
It will then execute the first task in the list on
all the three hosts simultaneously.
So except for Windows hosts,
Ansible uses the SSH protocol to communicate with the managed host.
So this SSH service is normally integrated within the
operating system authentication stack.
This is really good for Ansible, as it enables you to take advantage of
things like Kerberos to improve authentication security.
So,
Ansible uses the same authentication methods that you're already familiar with,
such as SSH keys are normally the easiest way to proceed, and they
remove the need for a user to input authentication passwords every
time they want to run a Playbook.
So Ansible uses SSH to manage hosts and it establishes an SSH
connection could actually take a lot of time.
So we have several optimization features that we can use here.
So because SSH protocol runs on top of the TCP protocol,
you can make a connection to the remote host with SSH.
Unfortunately, you need to make a new TCP connection.
However,
you don't want to open up a new SSH connection for every single activity.
So here we have things like Control Master,
which allows multiple simultaneous SSH connections with
remote hosts using one network connection.
We also have what's known as Control Persist,
also known as multiplexing,
that keeps the connection open for a number of seconds. Pipelining
allows more commands to use simultaneous SSH connections.
So if you recall how Ansible executes the tasks,
it generates a Python script based on the module that's been
invoked. It then copies this Python script to the managed host, and
then finally, it executes the Python script.
So the pipelining optimization will execute the Python scripts by
piping it to the SSH sessions instead of copying it.
So here we're using one SSH session instead of two.
So all of these options can be configured in the main sort of
configuration file for Ansible, which is the ansible.cfg, and we'll be
looking at this in most of the demos. And there will be a section here
with a bracket's SSH connection, and it's here that you can specify
these optimizations to more fine‑tune your Ansible connectivity to the
managed hosts. Also,
just a final note, and commonly a pretty insecure way, many use
passphrase‑less SSH keys to connect to remote hosts.
A lot of people also have Become=true as a standard setting; however,
just keep in mind when using these convenient methods,
if someone gets into your account,
all of your machines are wide open, so really don't configure
passphrase‑less solutions as standard, and when using ssh‑keygen
to generate your public and private keys,
it prompts for a password, and we always just press Enter.
So in production environments, passphrase‑less security is not a safe way.
Just on a final note on privilege escalation,
Ansible uses existing privilege escalation systems to execute tasks with root
privileges or with another user's permission. Because this feature allows you
to become another user different from the user that's logged into the machine,
we call this become, and the become keyword uses existing privilege escalation
tools, like sudo or su.
So privilege escalation is used to install software or make
changes to configuration files and performs other tasks
that require admin privileges.
So if you need to install a package, you need to be root, and if you
want to install through Ansible, you need to be root, and this is
what privilege escalation is all about.
So with privilege escalation, we can, for example, sudo into the
hosts, and this is done with the Become:yes parameter.