Then we have what's known as Ansible modules, and these are
considered to be the main workhorse of Ansible. You use modules to
perform various tasks, such as installing a package or restarting a
service or copying a configuration file.
So these Ansible modules cater to a wide range of system admin tasks.
The list has the categories and the kinds of modules that you want.
So there are over something like 3000 modules at the moment.
So you're probably thinking, who's looking after all of these modules?
This is where collections come to play in the more recent versions of
Ansible, and we'll be looking at these in the final module.
So these modules are script, typically written in Python,
that come with packages with Ansible and perform some kind
of action on the managed host.
And Ansible has an extensive list of modules
covering many areas such as networking, cloud computing,
server, config, containerization, and virtualization.
There are many modules to support automation requirements that you may have.
And if no module exists for your specific requirement,
you can actually create a custom module with the extensive
framework of Ansible. So consider each task is like a 1:1
correlation with a module. For example,
a template task will use a template module.
So basically, a module exists to satisfy a need, the need to do a
piece of work on a host. Modules usually, but not always expect
input and will return some type of output, and these modules are
generally written in Python.
Ansible Core is written in Python. Or when you look at modules for Windows,
these are generally written in PowerShell. So you know now
that we've got different types of modules,
for example,
the apt module, which installs or removes packages
using the APT package manager.
We also have the copy module that copies a file from the
local machine to a different host.
The file module sets the attributes in the file and the symlink or directory.
Then we have the service module that starts, stops, or restarts a service.
I find the debug module very useful and use it with
ad hoc commands and in playbooks.
So the debug module is like Ansible's version of the print statement.
Here we're using the debug module to print environment variables and
to see the value of variables, such as facts. You will see this a lot
of the up and coming demos.
So just one point. You can't undo a playbook as there
could be complex dependencies within that playbook, so
there's no default way to undo it.
I guess you could write a playbook to do all the
tasks in the opposite direction,
but there isn't a specific way just to undo a playbook.
Also, idempotency is quite an important topic, and modules strive to be
idempotent. This allows a module to run over and over again without
having a negative impact on the managed host.
So in Ansible, the input could be the form of a command line argument to the
module, and the output is delivered as JSON or to stdout.
So input is generally provided in a key‑value syntax, and it's up to
the module to deconstruct these into usable data.
So most of the modules that you'll be using will be idempotent and safe
to use. This means that you can run Ansible Playbooks multiple times
against the server, and it'll be safe to do.
For example, if you deploy a user that does not exist,
Ansible will create it. And if it does exist,
you run the same playbook. Ansible won't actually do anything, and
you'll see this with a change status of false.
So this really is a big improvement over the basic shell scripting
approach where running a shell script a second time might have a
different or potentially unintended effect.
For instance, if you wanted to power off all your labs for a weekend,
you probably better just do a quick one‑liner in Ansible
without writing a large playbook for this.
So an ad hoc command is good for running one command on a host, and it
uses modules too. They're used for checking configuration in a host and
also good for learning Ansible. So note that Ansible is executable for ad
hoc one‑task executions. And then we have the Ansible Playbook, which is
executable. That will process playbooks. That could be used to orchestrate
multiple tasks.
So the opposite side, we have ad hoc commands. On the other side of the puzzle,
we have playbooks that are used for more complex scenarios and better for use
cases where the dependencies have to be managed.
The playbooks can take care of the entire application deployment,
along with all of its dependencies.