In this video, we are going to talk about ad hoc commands. So I'd like to transition right into ad hoc commands from the run command modules because oftentimes you are going to utilize command and shell to issue one-off commands to your hosts, and this is essentially what ad hoc commands are: they are just quick checks that you don't necessarily want to save for later.

So the examples on this slide are pretty typical. Our first example is just checking whether we have connectivity with the host by issuing the ping command, and if that was successful it would return a pong. In our second example, you can see that we are issuing a command to check the uptime on the two servers in my web group using the command module. And lastly, my last ad hoc command example I am just gathering some facts against my local machine which would yield the following output and this is basically just a small sample of what's gathered.

So you can see here I have my Ansible fact tree, which is just showing the first dictionary of ansible_default_ipv4 and the various things that come along with that. So ad hoc commands and modules are always going to come back to the inventory that we are managing, and inventory again, it consists of hosts, groups, we have inventory specific data or variables, and then whether that inventory is coming from a static or dynamic source. And note in this case that hosts has actually been expanded to include network devices and containers and pretty much anything that is network addressable.

So let's take a look at some examples. This is a static inventory example, it's free form listed by IP address, nothing crazy, but if I clean that up a bit I am going to get this host file, which is INI any format, and it's separated now into groups. So I have a control group, a web group, and an haproxy group, and we also have some inventory specific data where we're defining ansible_host for each of these different nodes and then we have a vars section defined for all the hosts where I am setting my connection information as well as my path to the private key file that I am using for authentication.

So now that we have looked at an inventory example, I'd like to demonstrate some ad hoc commands against my target machines. So I am just going to transition over to my terminal window. So if I list the directories, the contents of my lamp_haproxy directory here, you can see that I have a hosts file already in here and if I cat that, this is in the same format as the example slide that I showed just a couple of slides ago, basically just a simple INI formatted hosts file. I have three servers in here listed by IP address and they are in three separate groups.

So I have the webservers group, the dbservers group, and the lbservers group. And I don't have any variables to find because I am going to keep that for my ad hoc command as well as the basic playbooks when I get to that a bit later. So to start off with my ad hoc command, I am going to use the ansible command and then I am going to decide which host I actually want to target.

So I go to ansible all because I want to target all of them, and then I am going to pass the inventory flag (-i) for inventory, and I am going to specify my hosts file, which is hosts. Then I am going to pass the connecting user, which is a vagrant, because these are vagrant machines, and then I am going to pass the module, so dash m (–m) for module, and then I am going to test with a ping to see whether or not I have connectivity against these machines.

And I run that and I got a pong back on all of them. Successful. I love seeing green. So that's a pretty basic example of an ad hoc command but it's one that I usually use regularly because when you bring up machines for the first time you want to make sure that you can actually talk to them because it's no use running a playbook against a host that you can't connect to anyway.

So that's the first step. The next ad hoc command that I typically run is gathering facts, and I showed you an example of gathering facts against a local host but now I am going to show you an example of running an ad hoc command against the target machines. So I am going to start off the same syntax and now the only thing that I am doing differently is I am passing a different module name, which is setup. 

So I am going to run this and I get a response instantaneously and you can see there's lots more information that's returned here than in the local host example that I showed in the slide.

So if I scroll up a little bit you can see, so here is our ansible_fact tree again that we are getting all these JSON dictionary output here and you get things like your ipv4 addresses, you get a date time on your target machine, you also get the devices that are associated, but what I find to be most useful is this section right here, so the information about the machine itself. So we have got our distribution, our major version, and the distribution version. And so this allows you the opportunity to target mixed inventory by using conditional statements. 

So if I had RHEL7 and CentOS 7 I can decide which of the distributions I want to target by doing a “when ansible distribution is equal to RedHat or CentOS”.

So really really handy to gather facts about machines because these can all be utilized as variables inside your playbook. Okay. So another example that I can utilize for ad hoc commands is installing packages. And this isn't necessarily something that you'd want to use as an ad hoc command but I just want to show that the possibility is there for you to do it and if you only need to install the package one time on a machine that's never going to change, it might be a good thing to use an ad hoc command for it so I want to show you that syntax. 

So we start off the exact same way except this time I am only going to target the webservers group, and still passing that – i (dash i) flag for inventory, still passing the connecting user, except now I am going to pass a different module name because I want to install a package; I'm going to use a package manager and I am going to use the yum module for that. So –m yum, but I actually have to tell the yum module what to do, I can't just run it like this as I did with ping in setup because those modules don't take arguments, you just run them, but the yum module does take arguments. 

So for that I would pass –a (dash a) for arguments, and then I am going to enclose this in quotes, and let's say that I want to install Apache so I am going to pass the package name of httpd and then I want to make sure that it's present on the machine, I will close out my quotes and then I am going to add a –b (dash b) at the end because I am connecting to the machine as the vagrant user, but the vagrant user does not have permission to install the apache package, so I have to escalate, after I connect, to the root user, because the default privilege escalation user name is root, so I am going to escalate to root, root has permission to install Apache, so this should work successfully. So I will run this and it usually takes a minute or so and all that lovely globby output indicates that it was complete and it was successful. 

So if I scroll up a little bit here you can see the “changed”: true message and it only happening against the one machine because remember I am only targeting the webservers group, so there's the “changed”: true and you can see here's the whole output indicating that they are going to grab the package and install it and there's the complete message at the end.

Now one of the principles of Ansible is that it is idempotent; and I know this is one of those big words that, I am still not sure if I am pronouncing it correctly but I am going with it, I am sticking with it, but basically what it means is, is that I can run this exact same command again and it's not going to attempt to install Apache twice. So if I just do up on this, rerun I get a “changed”: false message this time because Apache is already installed. 

Now conversely I can actually roll back this package; uninstall pretty simply. 

I am just going to change this to absent in my command and then I can re-run, and the removal is actually much quicker than the install, so you can see here's the removed output and then there's the “changed”: true and again just like with the install the removal is also idempotent so I can just re-run this again and then I get a message that “apache is not installed” which makes sense because I just removed it.

So that concludes my demonstration of ad hoc commands. Look out for the next video where I am going to get into some other components of playbooks and talk about an introduction there.