So with that, let's move into managing automation. We're kind of moving automation into production. We're kind of what you'll see people refer to as like operationalizing automation. So let's start with automation controller. So automation controller is the evolution of Ansible Tower. It just does a lot more so that kind of called for a name change. There's a lot of people we are kind of getting confused with what tower was and what it wasn't, what was the product and the product for Red Hat is the Ansible Automation Platform. We talked about like Ansible core and upstream Ansible community. So automation controller is just one component of the Ansible Automation Platform, which is the product, you see like the logo in the bottom, right? So like navigator that we've been using on the command-line, that's also part of the product, meaning I can open support cases on it.

So when we think product, it's not just controller. So what is controller, what it does ? and anatomy of an automation job. We'll kind of dive into what automation controller is? So it fits right here. It's a self-hosted component. So it says On-premises here, but you could also host it in a public cloud or cloud anywhere within your organization. It runs on RHEL 8 or OCP, so we can containerize it now with Ansible Automation Platform 2 and later. So you can run it on Linux or you can run it on container. That's important to remember because a lot of people think that it requires them to have OCP and that is not the case. You either need Red Hat Enterprise Linux or OpenShift compute platform, not both. You see Automation hub here because there's a cloud service on console.redhat.com.

We can also have private Automation hub. So it kind of just two pieces, that's why it's split here. So Automation controller is kind of how we see operators kind of controlling their automation and it includes a web user interface. So we can actually see like a little breakdown of the web user interface, kind of little stylized, but it is a UI or web UI. I don't like the term GUI for whatever reason now, that one's been aged out. It also includes an API, so there's a browsable API. So this is how automation controller and the Ansible Automation Platform in general interacts with other IT gear. So when people have like a ticketing system, like service now, it can automatically talk to the API on automation controller and kick-off automation.

So you don't necessarily have to use the web UI. In fact, the more people move to using the API, a lot of times the less time they use the UI. So it just depends on the organization and how they are operationalizing their automation. Maybe they prefer the automation controller UI. Maybe they have their own existing ticketing system, either way we plug in really easy. Some of the enterprise features we're talking about a Role-based access control. Who gets to run automation on what inventory? It's push-button. So, when you hear this term push-button in IT, kind of a marketing term, it means like I just press a button in the web UI and it will kick off automation for me.

It also creates and solves a problem a lot of people wouldn't think about is when they run automation controller, it forces a paradigm shift on how they're doing Ansible and automation in general. And what I mean by that is when I have two or more users using automation, a lot of times they start by running automation on their laptops. So if I'm running automation and my friend Jim's running automation, we can start automating over each other and causing problems. Just because you automate something, it just means you're doing those tasks faster and more consistent. But if you're not doing them in a single location, it's kind of audible. You are creating a new problem which is like I can automate my change and someone automate their change over it. And we're not really agreeing to what the automation should be.

There's no single source of truth. So automation controller kind by defacto the way it exist, it's kind of a future, it creates a central logging system. And we can kind of output these logs to any like existing tool out there including Splunk. So there's also workflows. Workflows, we include a visualizer and we'll kind of show that upcoming in one of the examples. The visualizer allows us to drag and drop automation jobs, which kind of revert to playbooks. And we'll kind of dive into what automation job is and why it's different than a playbook? So I talked about push button, I talked about the API, the Role-based access control. It kind of just emphasizes a bit more as we can integrate with RADIUS and TACACS.

So when you have existing enterprise authentication methods, you don't need to reinvent the wheel with automation controller. We just kind of sync to your existing roles, then you can map that to different teams and organizations within automation controller to say like, hey, my network team can only automate my network here. My infrastructure Linux team can only automate my infrastructure team. You can even Geo walk it. So you could have like a Japan team and a Brazil team and South Africa team. It's very kind of robust Role-based access control.

We also have, in addition, like kind of TACACS, some RADIUS already, is we can also integrate with existing tools. So when we have integrations with like Slack, is you can have jobs automatically Slack with a notification. So that job, you don't need to necessarily write the playbook for it, as you just kind of press a trigger switch on an automation job and it'll take care of it for you. We talked about centralized logging. I just wanted to emphasize that again. It's super important to have kind of not only a single source of truth for like, what is my inventory, where're my variables? But I got to run automation in a structured way, otherwise end up automating over myself. And then workflows again, we'll kind of elaborate more, so there's no need to read the slides here.

So, Anatomy of an Automation Job. We have playbooks, what we encourage customers to do is use source control management or SCM. Most of the time this is Git and I swear 80% of the time it's GitLab or GitHub. So you will see those use and examples the most common, but it's really common with organizations. The larger they get is they have their own GET, they have Stash, they have something where they're storing it. So we call this a Project, where we store Playbooks. So on automation controller, you'll literally see a button called Projects that I will show shortly. You would sync this to wherever you're storing your playbooks in a Git repo.

We also need a Credential. We're going to separate Credentials out from the Project and this allows us to have different credentials for different kind of inventories and gear. So we also don't want to reinvent the wheel. Now credentials can be stored in automation controller. We also have a Ansible Vault, a way to encrypt variables. But what we see a lot of times, as organizations already have enterprise approved features or credential management and most of the time that CYBERARK and Vault. And we fully support the integrations with those on automation controller. So you can pull your credentials from those 2 sources. It's probably supported in your subscription.

So that's part 2 out of 3 and the final part is inventory. We need to know the IP address information, the username, if the credential doesn't have it stored for whatever reason, how to connect to the device? So we're using API, we're using SSH or using something else. And we see a lot of different examples here. I put a bunch of different examples here on the right. 3 of them are networking examples. Again, because my background is network engineering netbox, Infoblox, they're big kind of IPAM solutions DEVICE42, again another network heavy one, GitHub. I also see people, I should've put this one up here as service now. Even though it's an ITSM tool, people kind of use it as like a CMDB, a database for inventory. So that's really common. And really we just need any device that can output inventory.

So we also could use public Cloud APIs. So it's really common to use Azure, GCP and Amazon where we can dynamically load whatever is running and whatever zone or territory that you have and then that is inventory. So it can be a bunch of different places. And again, we don't want to reinvent the wheel. You could have your inventory literally just be a flat file in GitHub repo. That can be your inventory, it can be that simple. And there are organizations that do that in production. But I honestly, I don't know what's winning right now. I see lots of different inventory choices, so we just make sure that we work with all of them right now. And these seem to be the biggest ones that I see.

So we kind of go from there and all these sync into this kind of circle is called an automation job. So when we look at job templates or jobs, they always need a Credential, they need a Project and they need an Inventory. Otherwise they can't run. So let's look at automation controller and explore the web UI and kind of dive into some examples. Right! Here is the controller web UI. I'll show it in a second. I'll show the API as well. So I'm going to login by default unless you set it otherwise, the default username is admin, type in my password that I set up when I installed it. You actually install it with the Ansible playbook. That's super cool. I think it is. We drink our own champagne.

So default into the Dashboard. We can see here, I've run some jobs earlier today. We can actually click on the Jobs tab and see some playbooks that had been run. We can look at the Dashboard, we can see the Hosts, we can see Inventories which we'll show a little bit later, but I want to also show kind of the User Details. This is the admin, kind of setup by default. There's no Organizations in here, so it's just the default Organization. We can also click About here. So we'll have this little funny guy saying that we're on Ansible Automation Platform 4.0.0. It probably should say 2.0.0 but sometimes the numbering is a little bit odd with controller versus the platform itself because it's one component again.

So we can click the graphic here. It always takes us back to the front. And we have like the little hamburger menu to get to the menu here. Now, before I dive into all this cool stuff over here, remember I talked about those 3 components, Templates or job templates, Credentials, Projects, Inventories. And then there's a new breakdown onto, which is Hosts. So we actually look at host in here. So we can see our node1, node2, node 3. The other thing I want to show is the API. We're not going to dive into the API for this training. But I think it's important to know it exists at the very least. So I'm already logged in, so I can already see the API, but everything is a browsable API here.

So the same thing we just looked at. So we just looked at hosts. I can click hosts, I just Ctrl+F to find it and then it'll give me a break down and JSON here of every single thing. So, whether it's getting information from automation controller, like auditing controller, or kicking off jobs, anything in here is completely browsable. So I think it's important, at least know this exist and then like you do more hardcore training. You can kind of figure out all the little cool things you can do here. But I just want to make sure we covered. So with that, I'm going to switch back to slides just for a second. We're going to talk about a little bit more deep dive on credentials, inventories and we're going to talk about building a job template. And then we're going to go ahead and do it.