So we're going to show some playbook basics and kind of reiterate some information that we told you, but we just want to do a little bit deeper dive before we show a practical example. We're talking about plays, task and modules and then finally, playbook runs and some of the color you'll see. Hopefully, people understand that the color I'll elaborate on this, most likely 1 in 10 of people are colorblind, but there are ways that the colors don't matter. We always make sure that there's programmatic outputs for people when they look at Ansible. Looking back at that example, again, this is a play, the YAML file's identified by these triple dashes at the top to make it a valid YAML file. This YAML file could be called playbook .yml or yaml. There's a little bit of a religious debate between the .yml and .yaml. And I'm on the camp of I don't care, which usually frustrates people even more, but both are valid YAML file for Ansible.

So the play is this whole stanza. So we could actually have multiple plays in one playbook file. We'll look back at a task. A task has a one-to-one correlation with a module. So again here in this example, now it's the yum module. For this task, the name is encouraged but not required. And it kind of sub-documents that what we're trying to do with this task. And then this module has 2 module parameters, name and state. And this is telling us to install httpd to latest. Yep, the module's the yum, for this one would be template, this one would be service. Now talking about colors. It says the most important colors of Ansible are obviously green, yellow and red.

A green means that wherever you're trying to check, no change was made. Meaning like if you're trying to change a file or check if httpd was already installed, it'll just go green; yellow or it should show yellow on your screen. It's middle one is yellow for people that are color-blind. A task executed as expected, but it made a change, meaning it changed the end system. And then finally the red one means this task failed to execute successfully. It could be a connectivity problem to that particular device or it could be that the task failed and was unable to do what you told it to do. And I'll kind of elaborate when we do an example of why these colors kind of equate to state and why if you're colorblind, there's ways around that as well. Because I realized that not everyone can see these colors. In fact, my team ever it has, a color blind individual.

The last kind of thing before I show a practical example is showing automation controller. We'll kind of circle back to this, unlike the later section, but learning how this looks and how to interpret playbook runs, we can actually see this in automation controller. And you'll see that each host, hopefully in the screenshot you can see, it's on a per host basis. So like one host could fail here or change and the other ones could be fine. And it kind of gives you a play recap at the end. So it'll tell you what it's doing for those tasks and it'll show you how many devices are under, are being automated and kind of spread those out.

So with that, I'm going to show a Practical Example. I am on a control node and as you can see, it's real Linux. It's a real demonstration, if you will, because you can see if I type nothing commands, it will get mad at me. This is actually a 8.4 RHEL box. This is all running on AWS and a lab that we build out on the technical marketing team. Specifically, I want to show a couple of things on here. The first one is with Ansible Automation Platform 2.0. There's a new command-line tool called Ansible navigator. And when I press Enter here, it's going to give me what we call a TUI or text-based user interface. And I can actually see what's being the version, et cetera, of everything that I have.

Now, everything is getting packaged into what we call an execution environment, instead of just being installed on the control node. But it's all kind of abstracted from the user so we can give it to you very easy. So if I type images, it's going to collect all the images that are on this particular node. This one has 2 execution environments. And if I click execution environment, that's the green there on line 0, I can just type 0. It will give me a bunch of options and I can see what version of Ansible is installed. Which version of Ansible core has installed more specifically? It takes a second, the first time it runs. This is a brand new machine. It will tell me all the different collections that are installed. So you can see it has Amazon AWS, has a controller collection. So we can actually automate automation controller itself. It has some network collections, cisco, arista, free-range routing, ibm qradar, some Red Hat collections.

I think what's really important is it's actually running Ansible core 2.11. So this is ansible 2.11. If you were using upstream ansible project, what they do is it's very similar to this. Instead of a container environment, they would bundle Ansible core and a bunch of collections that are community supported collections versus Red Hat supported collections. So, what else can we do in there? We can look at what Python packages are installed. We can look at operating system packages, if any? It doesn't look like there's any on this one. We can look at the general information was last we looked at. So let's escape out of here. You can see this is what the TUI looks like. There's a bunch of different options in here. We can also look at the configuration for navigator itself. So this will tell you all Ansible configuration files, whether it's using the default or it's being configured. And it'll go option by option. You can kind of sort that in there. And we can obviously quit out of here and the TUI.

So you can also look at the Ansible configuration file, our stdout_callback is yaml. So that's a filter plug-in. We turn some warnings off here as we're kind of developing content. We didn't really want like warning coming out, if we're using an older modular or something and some kind of connection timeouts and stuff. So Ansible configuration file, it's very simple and it also points to our inventory. So navigators, how we kind of drive Ansible automation on the platform. But it's still the same Ansible that people know and love. And it uses the same playbooks that you know and love. So let's show what that looks like? We're going to look at that playbook that we just showed, exact same playbook, stanza is right here. Apache server installed, latest apache installed is yum, httpd and then copy it over.

So now that we've seen the playbook, I'm going to run ansible-navigator, run playbook name, and then to give original Ansible style. And I'll kind of compare these two. I'm going to run stdout, meaning it's going to show the info playbook equivalent with navigator. I thought I turned the WARNING off because we're kind of before release right here. So that's why there's a WARNING. So it gathered facts green. It changed, changed, so the word change will help you if you can actually see the yellow and it changed and got that web server running. So what happens if I re-run the playbook? So if I re-run that playbook again, to look really similar or even the WARNING because I'm on a newest version of Ansible that's not really out yet.

Again, notice something really interesting is it says, ok: node1, node1, node1. And if I run it again, what's going to happen is you're going to be changed. It's, going to know that it already has installed it. So from that point onward, every time we run that particular playbook, it's not going to modify anything. So why is that important? So if we scheduled this playbook in automation controller, it's actually doing more than just installing the web server, it's actually creating a compliance playbook for us. So if someone comes along like my friend Jim comes out and gets on that web server and he uninstalls httpd.

If I have this web server configured so that I'm running this playbook like once a day to audit it, it will revert it back to that state. And this is kind of configuration management, but it's also policy enforcement. If you've ever heard that term, is Ansible, has this concept of idempotency, so it knows what the state of that box should be based on the playbook. It knows that it should have the latest httpd. It should have this version of the index file and it should be up and running. And that playbook is telling you exactly what to do? So if any of those 3 things are not happening, it's going to revert to it. So a very, very simple playbook.

Now, the other thing we can do, we can use that help command that we talked about. We can actually kind of use any playbook command on the navigator as well. So in here, we're going to see something called check. Now this is really interesting. If I run something in check mode, it's not actually going to change it. So if I go over to that host, what was it called? This host? node1 command host node1, I can turn off that service manually, inactive. We can see that it's inactive right here, so I turned it off manually. So if I re-run that playbook in check mode, it's going to look very similar to the first run. And we'll see, we're going to play my bluff because this is real. And you see that only that, that third task said changed node1.

Now what's really cool here is it didn't actually do anything. You can see here it's still inactive. But if I get rid of that check, it's going to actually do it. So it's really interesting with check mode, is check mode allows us to run a playbook in kind of read only mode, is still logging into that device. Don't get me wrong. It's not logging into it, obviously it needs to get some access to it. You can see now it's active and running. Now what's really cool about check mode to me is it helps with the adoption of Ansible automation across an enterprise. Because not everyone's going to be comfortable with automation running everything immediately on day one. There's a culture issue as well. And what we're trying to do is have people start small and think big and check modes are really great little knob. It's available both on the command-line in the upstream project, as well as just in, it's literally a checkbox in automation controller, so that you can kind of audit what the config should do, but it's not going to actually apply configuration.

So this allows you to apply automation in easy steps. As everyone on the team becomes comfortable with automation, then you can kind of move towards actual policy enforcement, which will happen is when I run this again now. It's going to actually know that it's fine. And then we'll check mark and you could have a little automation controller, you see a green and you know, everything's fine and that job runs every hour and now everything is green again. Now the last thing I want to show before the next section is standard mode, is if I run this playbook in the standard mode with navigator, it's actually going to give me kind of a much more high level view. And you can see now it says complete.

Now this is really cool, when you have tons and tons of devices. We kind of already, we're zoomed in. But you can imagine if I had 500 Apache servers, I was installing, navigator kind of puts the, original playbook command kind of like on rockets. It's a much better experience. And it's doing a task-based look at this versus a like a host-based. So we can zoom in, look at the task for this particular host. Then we can zoom in to particular task and we get all the output right there. And it becomes really easy to navigate in navigator. I did not mean to make that puns, so you can groan all you want. But this is really cool. It's just maybe not necessary for like a Hello World example. So that's why I was using the mode stdout. But this is a really cool way to navigate between different tasks using the built-in navigator functionality, the interactive mode. And with that, I'm going to move on to the next section.