Deep dive a little bit more, just so we know what we're talking about here as we dive in automation controller, inventories and credentials. So can the inventory is a direct mapping of what we saw with the INI inventory when we looked at it earlier. So your inventory in controller doesn't really have a concept of what you were doing on command-line, but you can import that same inventory. So if it was in a GitHub repo, you can just import that as a source. There's even an AWS managed command, like a command you can type on the command-line to import an INI or YAML file as your inventory. So all the same inventory attributes like Hosts, the Groups, Inventory-specific data, all that's exactly the same. It's just the idea of we are developing playbooks. It's kind of like a developer account, it's not the same as controller.

We are going to import the inventory. And the inventory is just one piece of the automation job. And the ideas that I have multiple, dozens of inventories on my automation controller. And then I attach different automation jobs to run on different inventories using different credentials. So that makes my playbooks much more reusable, so I can use them over and over again on different Inventory types. One more thing, the static versus dynamic sources. Think it's static type is like a Git Repo. Dynamic source could be like AWS EC2, where I'm loading dynamic inventory and what's active and filtering on it. Credentials, we talked about credentials a bunch. This again can sync to centralized management outside of automation controller.

So you can store it in here. We can store tokens, we can store SSH keys, we can store that and encrypt them to US government standards, is actually in use by the military. But it's really, really common. It's more common actually for someone to use an outside enterprise credential management system. So that's why we kind of integrate with that. And I want to make sure I touch on that. The other thing, and you see this in the screenshot, is we need credentials even to talk to other Red Hat stuff. So whether it's registry. redhat.io to grab execution environments, or it's another automation controller because we can actually automate controller itself. Or we could have controller installed on entire other controller and another data center. There's, attributes and there's credentials for that as well. So we have credentials, we have inventories. Now we need a project.

So a project. We talked about this before, but again, I want to emphasize, as this is how we manage Ansible Playbooks, as we're going to put them inside of like a Git Repo and SCM tool. And we're going to sync that with a project inside of automation controller. Can you use a flat file? Yes. Can you use a directory on that machine? Yes. Is it common? No, it's not common. It's very, very common to use Git. I would say 99% plus are probably using Git. And of that a huge chunk are using GitLab and GitHub again, that is really, really common. So if you have some knowledge on GitLab or GitHub, this is just a natural easy step as you just throw your playbook into a Git Repo, then you can sync that project into automation controller.

Job Templates, this is how we tie them together. So we take the project, the credential and the inventory, and we attach them to a job template. We name that job template and then we delegate it where we want to run it. So we're going to walk through this. You can see it. But that's why I showed that anatomy of a job, as a job template needs all 3 of those pieces. In fact, you can't create it without those pieces, they have little red asterisk stars, meaning that they required. So unless you understand those 3 pieces, a job template doesn't really make sense. You also realize that a playbook doesn't really equate exactly to an automation job.

So when we look at our playbooks where I had like hosts: node1, that doesn't make a lot of sense for a job template because we're assigning the inventory. So as people move towards using automation controller, and generally try to get them away from using the groups or hosts within the playbook itself and just putting all. Because that way the playbook, we can specify what groups and host we want to in automation controller. And you can always do that on the command-line, anyway. There's a limit or command - l for navigator and the ansible-playbook. So as you move in to more operationalized kind of automation, I kind of get away from like host: node1 or node2 or even a group because it makes that playbook less useful outside of that particular inventory. Like we're not talking about 1 inventory with a 100 servers, we're talking about like 25 inventories across my enterprise. And that playbook might be reused on all of them. And you might have different host names all over the place.

So to see job templates, we're going to click on Templates and the resources menu. I'll dive into this, executing a job template. there's a little rocket button, which I will show. So it's a little rocketship button. It's been interesting, This one has been kept over the years. I think it's cool. I certain like funny things get removed here and there as Red Hat kind of moves Ansible up and up and more mature. But the rocketship stays and I really like that. When we create a new job template, there's a little button here, and again, I'll show this again. So I'm not going to hover too much on this slide. But you can create what's called a job template or a workflow template, which we'll cover what a workflow is, in a little bit.

When we create that job template, this is where we assign all those fields. So the name, the type of job template, and so on and so forth. So with that, let me go ahead and show you the real thing rather than screenshots and let's dive in. So we're back on automation controller web UI.

Now we're going to create a job template. So we're going to look at Credentials first. I've already set this up because I preset it up because this is all running on public cloud infrastructure. I kind of threw this credential in here. So this is on AWS EC2, so the user is ec2, the SSH Private Key , SSH Private Key is Encrypted, meaning I can't see it once it's in here. There's no way to unlock it until it's running a job. So users can't actually see it. So you can have 1 user enter the SSH Private Key, another one can get access to it and see who's allowed to use that SSH key. So you could have an SSH key, I give to another user to run an automation job, but other users can't use it. So you can give kind of access to a particular credential for people to use on their automation or you can lock it down so other people can't run on that particular inventory.

Another thing that we've already set up, again is the Inventory. So in here we can see all the different Hosts. The ones we want to talk about are node1, node2, and node3, which are 3 RHEL 8 Linux servers. We actually dive into one of them. We can see that ansible_host IP is in here and see that no facts have been run yet. You can actually cache the facts. And you can also notice little toggle button for YAML or JSON. So we have 2 pieces in here. We need the last piece. We need to think a project, which I am going to add the project in here, sean's project, execution environment, we're going to use the Default in here. The Default execution environment, which includes all supported content. We're going to use Git. You see the choices here, Manual, Git, Subversion, Insights, Remote Archive. So this is the most common by far.

We're going to drop the URL, so in here, there's a GitHub Repo name, we'll call it workshop-examples, which we put a bunch of examples in here. Now this is open source, so we don't need a credential. So you can actually have a credential to access Git as well, so if it's a private GitHub Repo for example, you could have it locked down but still access it as long as you have the credential. Now you can also lock like point to a specific branch tag or commit or rest back. I'm not doing that, I'm just pulling the latest. So these are optional and you'll see like little red asterisk means this is required versus optional. Click the question mark, it'll give you examples of what it's looking for? And then here, these are kind of different little toggle switches. So for example, if you know you're updating your Git project over time, you could have it automatically Update the Revision on Launch.

So each time you run the job template, it's going to sink that project back down. And there's kind of examples of what each of these 2 read in the web UI. So I'm going to go ahead and save that. Now what's really cool is, as soon as they save that, it's actually using Ansible under the hood. It's actually running a job to sync that project and it's already synced. So it gives me the start time and the end time. And you can see this is kind of the auditing I talked about where we have a central logging of everything and I can actually zoom into that, in the web UI. I can download the output in here, where I can just kind of like look around and click on particular tasks and see like what it's doing? So it's saying here load repository version, whatever. Look at the JSON Output and look around, it's kind of like navigator.

So now we have all 3 pieces. We have a project, we have credentials, we have inventories. So now we're going to create a job template and I'm just looking on the other screen to make sure I have the exact things I want to type in here. I'm not missing anything. So when I click Add for job template, I have 2 options; Add job template or Add workflow template. So to make a workflow template, we need job templates. So that's why we teach job templates. first, as workflows include multiple job templates or job templates are like the single smallest unit we use with an automation controller. So we're going to go ahead and make a new job template. We're going to copy the easy example, building a web server to install Apache, we can add an optional description. This is just for us humans. They don't really care about it. The robots and automation controller. It's just like sean's example for ansible essentials. We can put a sentence in there whatever.

Now, job run, we have 2 options. I showed this early on command line as check mode allows us to run that job. So instead of it being a command-line argument, now we get a toggle box or a dropdown menu rather. So we have Run or Check. So I'm going to put it and run. It can also Prompt on Launch and actually I'll just go ahead and do that, so we can show that. It's Prompt on Launch, we'll watch a little survey that we'll see what that looks like. Now we can attach the pieces items that we kept talking about. Inventory is the Workshop Inventory. You can search, if you have lots of inventory, you can search through them. The Project, we have lots of projects in here. We're going to load sean's project that I just made.

So I have 2 out of 3 execution environment. I'm going to use a Default execution environment built into automation controller. Now Playbook, as soon as I synced this particular project, it's going to give me all the playbooks in here. So I'm going to choose this apache_install. Imagine this, each Git project can have multiple playbooks that are used. And then I can choose them really easily. And if I have more than 3, I guess it's really easy to choose from. You can actually search through by auto completing as I type. A final thing in here is Credentials. Now you'll notice there's no little red asterisk. So credentials are necessarily required because you could have stored it in your project itself. However, that's kind of not a recommended practice per se, right? As most people would use credentials from CyberArk But it happens, it's not too little that we would disable that.

So what they'll usually do is they have it as a host var or a group var. They'll store their credentials kind of like command-line. And they just encrypt that with something like Ansible vault. And then you wouldn't do any credential management in automation controller. However, most people tend to use the credential management in here. I'm just trying to explain why it's not required? So I'm going to click that Workshop Credential, which is storing that SSH key and username for all the devices. And then I'm done. There's a bunch of optional things I can do here. We're not going to cover right now. But we can just kind of go to the bottom and then the blue Save button becomes available and I click Save.

Now I have my brand spanking new job template. Very nice. You'll see here if I click on job template that shows up under here. So I have a bunch of job templates in here. I forgot that I added almost everything into this example. So this is a good example of showing Install Apache, as I can search through and easily find a job template. Now you'll see if I want to change these values, there's actually an Edit mode in Ansible Automation Platform 2, so go back and edit them, I have to click, Edit, I can click cancel. And I can Launch from right here and this button. Or I can launch from outside using my cool little rocket button, I'm so unnecessarily happy about. So let's go ahead up.

There's one other option, so this is actually going to fail. I think it's good to show it failing one. So I did that Prompt on Launch check box. This allows me to kind of like flip between Run and Check right here. It's a little survey that will pop up. It gives me some more knobs for people. So it tells me exactly what it is going to run on. And then I press Launch, gather facts and then it failed. Why did it fail? It tells me exactly why it failed? It says; This command has to be run under the root user. So if I click back on Templates, I kind of sort by apache, I click back in here. I'm going to notice if I click on Edit here, that I am missing this option Privilege Escalation, if unable to run this playbook as an administrator.

So in this particular case, when I try to install Apache or DNF or YUM, it need sudo access to do that. And this is the equivalent of become on the command and the playbook. So you could just leave it in the playbook. But this makes it really easy to toggle it within the web UI. So if I click Save, scroll down and I click Launch, I click Next to launch in run mode, launch one more time to execute. It should work this time. And that's how I know this is live or at least recorded live. It's going to gather facts and you'll see this time and you already know it worked because it went through that second task. So in here we can see it actually ran. You see that same output, we would've seen a navigator. It made sure httpd, was the latest?

So these are the module arguments that we saw. And we also notice that message, Nothing to do because we already installed it when we were on ansible navigator on the command-line. You'll actually see so things not bouncing anymore indicating the job's done. If we scroll down, we'll see that there's a PLAY RECAP, just like we would see with ansible- playbook command. And if we click jobs, I should see that it ran successfully when it completed. And we can always go back to that particular job and see that exact output. We don't lose that just because that jobs already done executing. So now you've seen how to create a job, tying together credentials, projects, and inventories. How to execute that job and how to add privilege escalation to that particular job. So with that, let's move on to another cool feature. We're going to talk more about different enterprise features we can do with automation controller.