In this video, we are going to discuss how Ansible works. So once you have Ansible installed, you are going to need to become acquainted with the key components of how Ansible works. And the graphic on this slide is showing the relationship between all the main pieces of Ansible, which first starts with the user who writes the Ansible playbook. So playbooks are written in YAML, which stands for Yet Another Markup Language, and those are going to invoke Ansible modules in things called tasks, which get executed sequentially in order from top to bottom. 

Those modules are essentially executable bits of code that are pushed out to your target machines. However, we don't need to understand the underlying code of these modules to get them to work, we just need to be able to pass the correct arguments to our playbook. Those modules are going to be used to act against our inventory, which consists of hosts and groups. 

So in this example we have two hosts in the web group and one host in the db group, listed by an arbitrary FQDN, but they can always be listed by a host name or by IP address as well. So where is that inventory coming from? It actually doesn't matter as Ansible plays nice with a bunch of different inventory providers, the only thing that matters is that we have a host to manage. Once we have that we can push out the playbook that uses modules that acts against that inventory. 

So it all kind of comes back to that inventory we are managing. There are also various Python APIs that Ansible users can utilize for extending Ansible's connection types. Since SSH is not the only one, surprisingly. So we also have plugin support for callback plugins, filter, and other lookup type use cases. So if you are interested in those options you can check out docs.ansible.com for our developing plugins doc as well as our document on the python API.

Ok. So we talked a bit about modules already in the previous couple of slides but I did want to point out some commonly used modules that you may see out there and examples quite a fair amount. So typically you are going to see a lot of package management modules being used like apt and yum. Also lots of file modules used like copy and file, and there are tons more out there as well; like I mentioned before, we have over 450 modules. So these are just a subset of what you are going to see. And if you want to see all of them, you can actually check out the exhaustive module index at docs.ansible.com, which is really handy, it breaks it down by module type and then you can go into each individual module page and look at the arguments that you can pass to each module. 

Additionally, there's a special group of modules in the module index called command modules, which are basically “run command” modules. So, to start with, we have the command in shell modules, which go hand in hand, and these are super useful because you can basically execute commands on your remote nodes as if you are actually there. So really the only big difference is that command is not processed through the shell, so certain variables and redirect options are not going to work; if you need those, use the shell module instead.

We also have the script module which is great if you have homegrown scripts that you need to push out to your remote machines or if you are targeting Windows hosts and you need to put out PowerShell scripts. And lastly, we also have the raw module. So what this module does is it basically just issues a pure ssh command. It's going to bypass the python module mechanism entirely so it's useful if you are talking to a machine that doesn't have python or if you are talking to a machine that has a very old version of python and you need to install the requisite python packages in order to start using Ansible normally. A good use case for the raw module is for Windows; you can wrap your PowerShell commands in a raw invocation, and then go from there.

So look out for our next video where we are going to take these run command modules and transition them into an ad hoc command.