Let's move into Ansible basics. So, we've talked about inventory, we showed a quick example. You can have multiple systems in an inventory, doesn't have to be one type. In fact, we encourage kind of grouping them by type. So even in a network inventory, I might have a grouping for Cisco IOS and I might have a grouping for Arista so that I can run automation for the specific groups. Just for them, like if you have like a CVE or some vulnerability that comes out, allows you a lot of granularity to have multiple types of groups than there. Inventory is usually file based. I think that's most typical for what I'm seeing. However, there's a lot of like that. The larger the organization, the more likely they are going to use a giant database. In fact, I probably say a third of our customers use something like service now as their actual inventory. But there's just as many people using like a Git repo as their inventory.

So what's really nice with Ansible is how flexible we are as long as we get that inventory in from some system, It's fairly easy. And then you can have variables for each group or even a host within your inventory. And the way I like to recommend it is when we have variables in inventory, I prefer them to be only variables that we use to connect to the devices. So think of like the username passwords, obviously encrypted would be good examples and network devices, we need the Ansible network OS. We need to know what type of platform we're connecting to? We need to know if we're using SSH or if we're using an API.

So usually I like to restrict the variables, but that's more of a best practice or recommended practice than it is a rule. You could put all the variables if you want in an inventory, but I tend to prefer putting my variables into a group vars or host vars directory. And I prefer putting variables that are in inventory that are just specific on how to connect to that device. So here's another example of an inventory. You can see here that there's actually IP addresses. That's fine. Ansible, will kind of use the system at the control node system that it's on. So it will default using DNS, if you don't put a DNS name in there, you can also put a name and Ansible, and then you can use ansible_ host and then set an IP for it so you could pin an IP, but still have a human-readable name where you're not relying on DNS but you could also just rely on DNS. So we allow kind of the ability to use fully qualified domain names, IP addresses, or kind of a mix of both, depending on what you want to do.

As a network engineer, I tend to pin everything with an IP address that I can and put a name on it. Just because I've been burned so many times by DNS that I just, I like having some control outside of the DNS, that really depends on your situation and what you're trying to set up there. So here's another example of an inventory. It's an INI styled inventory. There's two groups here, the app1srv. You can see here, just like I talked about, pinning a host to particular IP address when we use the ansible_host, we can pin this to particular IP address. If we don't have that, like in the group web, webserver01, it's going to default to using DNS. So it's going to use DNS for webserver01 and if it can't find it, it will just say that the host is not working for that particular play. And here's an example of group variables, web:vars, that allows us to define variables for the group web.

So any host that's underneath that group web will have access to these variables, the apache_listen_port 8080 and the apache_ root_path is /var/www/ mywebdocs. So these are variables that I can use within my playbook for templates or whatever else I want to use. Again, I would tend not to do that in situations like this, unless its variables I'm using to connect to the device. But if it's a short playbook, this is totally legit. It's a normal way that you'll see all the time. And finally, there's an implicit group that's always included called 'all'. So you'll see there's not actually a group defined 'all' because everything's already in it. But if we do all:vars, we can actually set like for example, these are great examples of variables we use to connect to the device, the ansible_user, and the ssh_private_key.

So this is what we need to actually connect to anything within this group. And we're assuming here that they're all using the same key. So this is a very good example of a basic INI file inventory. So, for this slide, I want to talk about groups and the hierarchy of groups. So you can have infinite groups and Ansible. I'm sure there's some upper limit where it just wouldn't work, but I've never had it. So as a group nashville and a group atlanta. Now, what I want to show here is the south:children. That children is a keyword. That means everything in the group south will include atlanta, nashville, and then it can actually include, it doesn't have to just be other groups. In this case, it's hsvapp05 that shows that particular host.

So when I run a playbook on the group south, it's going to run it on all 5, our hosts here. So the bnaapp 01, 02, atlanta appo 03, 04, and then finally that hsvapp05 that was included in there. So you can create as many groups as you want. You can create groups that contain groups by using that colon children. And those groups that contain groups can actually contain hosts as well. So there's also a basic Configuration File for Ansible that allows you to set a lot of these knobs. It can be in multiple locations with different precedence. It's called the ansible.cfg file, we'll kind of show that in the practical example of what that file looks like and kind of go through some knobs on it.

Another thing I want to mention is how with the ease of use for Ansible is that every command line tool, including Ansible, Ansible playbook, Ansible Navigator, has the help command. In fact, it's a little bit idiot proof. I like that for myself, is if you forget to do -- help, it'll just do it by default, where it will show you all the available commands, the syntax for those commands, kind of examples of how to use them. This is a very nice thing to have when you don't want to kind of cycle back and forth between the documentation and cutting and pasting like the exact command you want. As a big reason I got, so involved with Ansible is how easy it was to figure out like what I was supposed to type or what options and knobs were available to me.

So with the next section, we're going to move into playbook basics.