So this next section, we're going to dive into ansible variables. Now we already saw variables within our inventory. That's a great place for variables. We're gonna kinda look at them, can kinda see the different types of variables. We'll look at the debug module. Then we're finally going to cover what we call ansible facts, which are huge part of ansible across all the major domains, we use ansible facts and network automation all the time is just as important regardless of the domain. So for this example, we're going to show a, a fairly simple variable example. We have vars defined in this play. So we'll kind of start out here is we have our stanza or a play within the playbook name variable playbook test, host localhost. There's always an implicit localhost available for you to run playbooks as long as it's not needing to connect to something.

So here we have vars defined in our play. This is not super common in production, but it's very common and kind of Hello World examples like this. Because I don't want people to judge me too much for having my bars right in my playbook. But this is great way to kind of put it all on one slide and make it easy to read. We have three variables, var 1, which is awesome, var2, which is ansible is, and finally, var three, which is actually a combination of the other two variables. To unpack a variable. Even within the playbook, we use ginger and the syntax for that variable is a double curly brackets. So we do parentheses, double curly brackets, var2 and curly brackets. And then we'll unpack of R2. And it will say Ansible is than VR1. Awesome.

Now the last thing here is the task is we actually need to print the task out somewhere. So in this case, the debug modules is really good for just kind of checking variables. You don't need to print variables, but it's very common to print variables or see kind of what facts you've gathered or print whatever you want to terminal. You could also use it just kinda like a print statement. Like if anyone's a C program are out there. Debug statement just executes locally and can print whatever you want to the screen. So in this case, it's going to print out ansible is awesome, which it is, let's, let's give a round of applause. Principle today. So ansible facts, they're just variables. It's that easy. Whoever they're coming from, whatever we're talking to. So it could be a localhost, it could be managed nodes that we're trying to automate against. And basically there's a built-in module for Linux called this, the setup module. And this module collect a bunch of facts around that system and network world.

We have each platform, so like Cisco, IOS, we have a IOS facts module, and so on and so forth is there's facts for every conceivable system out there. In most of our partners kind of like to extend those facts and they're continually updating them so you can get more and more structured data about the system. So with that, let's show a practical example again and what facts look like. So I'm back on Visual Studio Code connected to my red Hat Enterprise Linux box. So really quickly I'm going to do a really simple own little ad hoc command to facts about my local system. Since the control node in this case is also Red Hat Enterprise Linux, this is just really easy way to see like what facts look like.

So it's literally everything under the sun, like it's the IP addresses on the box. The architecture of the box, you can see it's X86, has the date, time of ansible running on. It has, let's see down here the distribution that this box is Red Hat, where it's grabbing information that it's, it's a dot for the DNS servers and it goes on and on and on and on. It like this information could be used to audit. Audit your network will confer a vulnerability that's like a hardware vulnerability. And I'm gonna grab serial numbers. You could grab all the boxes that have a certain ship and make sure you patch them. You could check your uptime and see if any servers rebooting overnight and kind of graph that out.

So the facts can be used in a variety of different ways. And they are extensible, meaning you can change like what facts are gathering and gather more or less depending on like how many machines are running on. So facts are super important. And again, they're important across all domain types. So here I have a playbook. Playbook is one task, it is the debug task. And by default we gather facts. I could change this to gather facts, true, but that's the default. So if I do this, it's going to give me that same exact behavior. But just to be kind of more implicit, I'll save that. And what I'm gonna do here is I'm going to run this with Navigator again. And I'm going to run this facts playbook. And you just saw how many fact that collects. But this time we're only going to print out two facts with the debug module. And we'll just do standard off because we don't really need the interactive mode for one host.

You can see the warnings because I'm on that we haven't released it as a time of our recording. And you can see really quickly here is I have three nodes and it says, Hey, this node 1 dot example.com uses this IP address. This notice is this IP address in this node uses this IP address. And this is insanely important. You can do all kinds of really, really cool things. With this. You can create dynamic documentation. So this entire website I used is just grabbing facts from a network device, just putting them into HTML tables. So this becomes really cool where I can actually take those facts and learn stuff about a system. If you're a developer, environments could figure out what's installed those developer environments, how much they're being logged into. 

Whatever facts you're gathering are probably important in some use case and you can customize it into kind of a little dynamic documentation here. So back to the example. We have a second kind of playbook here. It's doing something a little bit different. So in this case, we have a copy module. Now before when we created the webs are just kinda like created it with a static file. But let's say we had two different web servers. So basically I can do a switch statement by using a variable like is this product, product production, is it development? And I kinda have group bars in host bars. So just like it wasn't inventory, my group bars for the web group are using stage dev and my host bars for node two are prot.

Now host bars always be grouped bar. So that's why the easiest rule Ansible to remember. So if I have a variable defined for my host that's more specific. So if I have the same variable defined upper level, it gets be pretty much like any other functioning tool out there. And it kinda reminds me of CSS where the most recent thing and CSS will be the winner. So when we do this, we want to run navigator, run and deploy. Or in mods tended out. And see the node one actually was the only one that worked. Because we didn't, we didn't install HTTPD on the other notes. So this is a very good example of how we didn't actually set these two up in the previous example. And this is what it will look like with the red. It says fatal. And if we run this again, it won't work because HTTPD, he's not on there, but I'm going to show another tool which is verbose mode or dash B. And I'll kind of give us a little bit more information about why it failed. There. It's because I know just thinking about it, what we just showed is it's not we don't have httpd actually installed on that system. And here we know that no two is prod, but the other one should be dead. So if we curl node 1, we get death, which is what we expected. So kinda showed a couple of different things in this examples, we showed how Ansible will work for a particular device, but it can fail for other ones. And you can actually change that behavior and strategy. But the default behavior will always be like this. They'll continue through. But if there was a task after this task, only node 1, we're continuing through and we can see that the web server was set up, but it did it just use the group far, not the node bar. And that concludes this section.