The course is part of these learning paths
This course looks at the Ansible Automation Platform. We'll look at how it works, looking at all the components like modules, tasks, and playbooks. We're going to show Ansible commands and how to use the command line tool, Ansible Navigator. You'll also learn about variables, templates and playbook basics.
Then we'll move on to the automation controller, the web UI and API, and you'll learn where it fits in and who would be using it. We'll also take a look at some enterprise features like Role-based Access Control and workflows.
Learning Objectives
- Learn the basics of Ansible including its components including modules, tasks, and playbooks
- Understand Ansible commands and how to use Ansible navigator
- Learn how to use variables and templates
- Use Ansible's web UI and API, known as Automation Controller
- Learn how to build a job template
- Understand how to use Role-based Access Control and workflows
Intended Audience
This course is intended for anyone who wants to learn more about the Ansible Automation Platform in order to operationalize and put their Ansible workloads into production.
Prerequisites
To get the most out of this course, you should have some knowledge of Linux or Red Hat Enterprise Linux. Existing knowledge of Ansible would be beneficial but not essential.
Finally, for this class, I want to discuss workflows, using the workflow visualizer. And what that means is, understanding convergence and divergence, which I think is one of the more complicated things, if we use these words. Especially convergence and divergence sounds more complicated than what it is, but let's dive in and it'll make a lot of sense. So workflows allow us to combine multiple automation jobs into a single visual representation. It kind of goes bigger than that though, as we can actually execute a certain job if one job fails and another job, if it is successful. So we can start building entire workflow based on the conditions of previous jobs. And we can also run jobs in parallel with each other.
These job templates are nodes within a workflow, could actually be other workflows. So we can have a workflow that's just setting up Network automation, a workflow for my security automation, a workflow for my web server. And I can dive in kind of infinitely. I wouldn't do more than one or two but it's important to remember that these workflows are just a very human look at how to run automation. They can be treated in a programmatic fashion just like a job template. So I can schedule workflow to run every hour or once a day. I can do an API programmatic call to a workflow just like I can a job template. So this allows me to divide my automation into smaller succinct jobs versus having like one giant playbook that does everything. Because I can tie them together with a workflow and it gives me a lot more control in decreases the complexity.
So instead of having like very complicated playbook logic to run like, run this task if this task fails, then run this task if it's successful. That could be very complicated within like an Ansible playbook. Instead, we can represent that with a workflow. When we add a new template again, the way we'll look at this is instead of add job template, we're going to add a workflow template. It's an option on the job templates are the templates form. So that's why this menu item is not call job templates because it also includes workflow templates. So it's kind of ambiguously named templates, but that's why there's two different types of templates in there.
When we create the workflow, automatically it's going to launch us into that visualizer. There's also a tab for that visualizer. And that Workflow Visualizer with Ansible Automation Platform 2 and later is now going to have kind of like a very wizard approach to building it out. So it's a much easier experience for customers that might have used Ansible tower and previous versions is now it's really clear what to do and where to click. Where before that visualizer might have had just a few rough edges, but it's that same functionality and the same goals kind of remain. So when we start a job template there's always a blue line. This indicates that this will always be run.
There's an option like when we started this job workflow always run this job. If this job succeeds, a green line indicates if the previous job succeeds, run this job. If the jobs are above and below each other, this means that they run in parallel. This could or could not make sense depending on your use case, right? Like if you're configuring 5 templates on the same box, in the same file and you try to do them in parallel, that doesn't make a lot of sense. It may work depending on how the timing works. But like this usually makes more sense when each job template is a different inventory, or at least configuring something different on that server. And then if these job templates fail, there's a red line, this is called convergence. This line will converge back and it says Restore Network Config for this particular example. That means like hey, these jobs failed, so restore back to a point before these two jobs started.
So this is a way, this could be an alert, like you could set up indication with some sort of ticketing system that you had to say like, hey, there's a problem with automation job XYZ. This is what happens. You could have it kind of auto remediate and say like, hey, this failed, revert back to this configuration or this backup. Or usually when this fails, here's the 5 things to try. So it allows a lot more functionality and I only show four job templates on here for succinctness to show like how it fits on a slide. But in a real production use case, this could be 50 different nodes that you can zoom in and out with the scroll wheel and kind of build the orchestration that your production use case does. And again, we're concentrating on kind of automation for holistic IT, where one of these job nodes could actually be a workflow that breaks apart, that could just be the network.
So what's really cool is if I had my network team, my infrastructure team, my whatever team, they could provide a workflow with other teams and then an Automation Architect at a higher level could stitch together these workflows to create overall orchestration where they're concentrating on business outcomes like deploy this new service versus concentrating on that domain specialty like, configure this new access list for security, for example. And that's why workflows, I think, are such a killer feature and I use them all the time, is that it's just, a really easy way for people to visualize it. And as a network engineer, in my past life, I'm a very visual person. So seeing automation jobs and a visual top-down, it's kind of like a native cool factor for someone like me.
So with that, let's go configure a workflow and look at some of the knobs and buttons. We are back in automation controller web UI. I'm going to create a couple different projects here. So we're going to create a Webops Git Repo. We're going to use Default execution environment. I'm going to use Git. We're going to use the same examples here, workshop-examples. I'm going to do Clean, Update Revision on Launch. And Delete. Delete is the local repository, is entirely deleted and cleaned each time. We're going to save this. That's automatically sinking. So if I click on Jobs, you actually see it's sinking there.
So I'm going to create yet another Project. And this one's going to call Webdev Git Repo. I'm going to make the Default organization, a Default execution environment. This one will be Git, this one, I missed something. I'll fix that in a second. The URL is here, Clean, Delete, Update and Revision. Just to make sure that I don't cling to each time I run a job. The one thing I forgot was the branch on the last one. So this branch is going to be webdev. So if we go back to the examples in here, you'll see that there's a webdev and webops branch if you want to navigate yourself. In here, this one's webdev and the other one, webops. The branch is webops. And the reason we're doing 2 projects here is we want to make sure we understand that the job templates nodes within a workflow can be completely different projects. And I thought that would be kind of cool to show. So that's why we're doing it that way.
We're going to create a job template now. We're going to say that this job templates is the Web App Deploy. It is running on the Workshop Inventory. It's going to be running on the project as the Webops Git Repo, execution environment is the Default, the Playbook is going to be web_ infrastructure. You can see I have a lot more here, so I'll show that kind of feature I talked about. I guess it's where it starts with, that autocompleted the whole thing. Anyways, the web_infrastructure playbook is here. So /rhel/webops/web_infrastructure. And again, that goes into, like if I go in here webops and I go into /rhel/webops/web_infrastructure.
So this is the playbook that it's running. If you want to follow along or kind of look behind the covers, I guess, like Alice in Wonderland style. And I need their credentials workshop credential. And before I forget, Privilege Escalation, I keep forgetting to do that. For the become, I tend to cheat and my playbooks and I always just become true, which is not the greatest way to do it. I'm also going to put a Limit. So limit means only run on these hosts. So we're going to just run on that group web and we're going to Save that job. We're going to create one more job template, add a job template. This time we're going to call it Node.js Deploy.
Inventory is the same, Project this time is going to be the Webdev Git Repo, which is a different branch of that same Git project workshop examples. We're going to do Default execution environment. And this time we're going to do the install_ node_app. Credentials are the same. The Limit, we're only going to run it on the web hosts. The Privilege Escalation needs to be true and we're going to Save that. So now the fun part, ladies and gentlemen, add workflow template, sean's awesome, amazing workflow. We're going to use the Default Organization Workshop, while we don't have anything to see how this is an option because it doesn't really matter because each job template could be using a completely different inventory.
So as soon as I Save this, I get into the visualizer. Look how amazing this visualizer is, but there's nothing in it yet, so we'll click start. And what we're going to do here is we're going to click Web App Deploy and really since it's the first node, we can't, we need to always run no matter what? So it's, just run, so it's blue. So we get that first network. So right now like there's no advantage of a workflow over that job template, except they get this cool picture of it, I guess. So I'm going to do next is I'm going to add an additional node. So when I hovered this job template, you'll see this kind of menu come up. So, I can edit it, I can link it to something else that exists and click the little info button and look and investigate that job template. Or most importantly, I can click this little plus symbol. And I can determine, if this runs On Success, On Failure.
We're Always run regardless of what the previous job state is. And click On Success. I'm going to go in here. I'm going to look for that other job template I made. Node.js, I'm going to say convergence. We can even click this thing, Preconditions for running this node when there are multiple parents. So you see here, On Success, we're going to run this job. So we're going to do is Save this. And now we have that workflow. So to get back to Visualizer, we can click Visualizer. We can click X if we haven't added anything. So you can always get back to that Visualizer by clicking this Visualizer tab. You can see all the jobs they've run. We haven't run this yet. We can have a survey for your actual workflow versus a individual job template. The other thing I didn't show in the Visualizer, I can actually go backward flows, is in the Visualizer.
Let's say this, this node within a workflow had a survey on it. It would, give us options here on the left that we could fill that out. Now we can't do it mid automation orchestration because that wouldn't make any sense. So you'd have to like pretty fill out the surveys rather than on-demand. So you'd want to do a survey for the workflow itself versus kind of midway through an automation job. So now that we're in here, again, we'll click X, we're going to Launch this workflow. So as soon as you launch a workflow, unlike a job template, they're showing like the playbook output, is it's going to give you that virtuatilization, or visualization rather, of the automation. We can kind of zoom out until it's tiny or zoom all the way back in. It will auto fit everything that you have in there. If I want to look at a particular job template, I can click on it. It will show that it's running and I can look at the Output. So I can still dive in like a job template, but I can go back and see that the workflow is running and click back in here.
So I can kind of dive in, so it's still running this, you'll see that little squares kind of shrinking in and out. It might be some delay with way of recording, that's showing me that it's still running. I can also, as I hover it, it'll tell me that it's running right here on the left, it says Job Status Running. And you saw it just finished. You'll also see when I'm in here, there's a new variable called Source Workflow Job. So I can always click back on this. So once I'm in a job template, instead of clicking back on jobs, I can just click right here on that workflow. It's even more helpful when I have like a workflow within the workflow.
So now I run, this one is finished even faster. We can look at the Output, make sure the job exists, et cetera, et cetera. And what we can do is this did all 3 nodes? If you go back to the terminal line, we'll just go to 1, Hello world is, this is now running. We have Node.js running, the web server is running, and we did both things in 2 different job templates. So this was a fairly simple example. I think it gets a lot more interesting, the more things you start automating. You can see like even in a 2 node, each of these is a node, job template as we can kind of change of behavior. And if I want to change this link, for example, I click the Edit and say like Always Run no matter what, maybe I want to disconnect these 2 things. Or maybe I want to only run this On Failure. So maybe like this uninstalls the web app, so this says ok, it won't be happens on installed and not working. Let's uninstall it.
So there's a lot of features here, and like if I click this plus, I can run like any template I want. So this one is for like a Cisco IOS box. So you can see how interesting this gets as I add more and more nodes to get myself examples. And all of 3 of these would run in parallel as soon as this job finishes. So this gives a ton of functionality to users. This is where I kind of fit in the workflow visualizer, I kind of argue is orchestration because we're now kind of daisy chaining, putting together. But I don't know why I'm doing this. I get like a knitting together all these little automation jobs and then start thinking that this workflow accomplishes a business outcome versus like an individual thing. And like workflows could be different types to write as we can embed workflows within a workflow, I can even like put itself in itself, which probably does not make much sense. But actually we can filter right here by Workflow Job Templates.
So we can put itself in itself. And it's denoted by this W. So this is where I kind of envision like domain architects could kind of embed their workflow and then make it available to like a higher level automation architect. So that concludes this example. So I have a few slides, I want to wrap up and talk about some different places to go, where to find content, where to go next, and how to get started But I really appreciate showing these demos to you. And let's move back to the slides.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).