- In this video, I'm going to explain ad-hoc commands.
In an ad-hoc command,
Ansible modules are used to perform specific tasks
on managed hosts.
An ad-hoc commands are perfect
for running one task on a managed host.
Some common use cases, are for initial host set up
for instance, that is something that we have already covered
in the first lesson of this course.
Or for checking configuration on hosts,
if you want to find out
if a specific configuration is present,
ad-hoc commands are the way to go.
Also ad-hoc commands are a perfect way to learn
how easy Ansible really is.
The opposite of the ad-hoc commands is the playbook.
The playbook is the way to implement more complex
tasks, where dependency relations have to be managed.
You may find for instance,
that an ad-hoc command to start your web service
is going to fill because the web service is not there.
That is the use case for creating a playbook,
and the playbook is taking care
of creating the entire desired state.
In ad-hoc commands modules are used.
An Ansible module is a python script
that will be executed on a managed host.
And there are over 3000 modules available in Ansible.
Modules can be offered as such which was pre Ansible 2.10
or as a part of an Ansible collection,
which you will find an Ansible two 2.10 and later.
Now, how do we run these ad-hoc commands?
Well, you use the Ansible commands
to run the ad-hoc commands.
And while running the Ansible commands,
an inventory must be present,
you must specify which hosts to address.
You will also use a -m option to address
specific module, a -a for the module arguments.
An example for instance
is Ansible - i inventory windows,
which is addressing a host
with the name windows- m ansible.windows.win_ping,
which is the Ansible collection name
of the module that you are going to use,
to ping the windows host.
Or ansible- i inventory all which is addressing all hosts,
- m ansible.builtin.command-a reboot,
which is going to use the command module,
and this command module,
as it is executing arbitrary Linux commands
is next going to issue the Linux a reboot commands.
Or for instance,
ansible-i inventory rocky1-m ansible.builtin.user,
which is using the user module on the host,
with the name rocky1- a name is anna state is present
which is going to make sure
that this specific user is present.
Let's go check this out,
right, let's run one example,
ansible-i inventory all.
So we are going to run against all host
- m ansible.builtin.command-a reboot.
Well, no, let's do another, -a id.
There we can see that the id command
is giving us some results.
Now, the reason I wanted to do the id
before the reboot is this.
do you see that connection refused connection
refused, reachable through.
Now why is that?
That is because Ansible is running the reboot command,
then it's requesting status information
and it can't because it is rebooting.
So once the hosts are back,
then we can use a command like uptime for instance,
to verify that the hosts have successfully rebooted.
As you can see up zero minutes,
zero minutes, zero minutes.
Another example is ansible-i inventory.
Do we really need minus i inventory?
Let's go check it out,
ansible.cfg as inventory, is inventory
which means that ansible.cfg is going to look for a file
with name inventory in the current directory.
So we can make this comment a little bit shorter,
ansible on rocky-m ansible.builtin.dot.user -a name=anna
state=present,
and oops that's a so called typo.
Let's fix the typo and run it again,
and now we can see it is giving us a change
which means a user anna did not yet exist.
Now, here we have used FQCN
the fully qualified collection names.
How about we just use the module name,
there you can see that on Ansible 2.9
that is perfectly working as well.
The future is collections, but as long
as you are on Ansible 2.9, you will find
that the module names themselves will also work.