1. Home
  2. Training Library
  3. DevOps
  4. DevOps Courses
  5. Ansible Basics - Automation Technical Overview


Developed with
Red Hat

The course is part of this learning path

Start course
2h 47m

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.


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.


With templating, it's a huge component I think, of almost any automation throughout there and Ansible is no exception. We use Jinja2 templating. When we do templating, it's kind of included within the language and we'll kind of do a top-level overview and I'll show example. There is a template module. This is very similar to a file module, except the source is on the control node, meaning where we're running automation from? In this case, this example here where it's highlighting it, is the source, is in a folder templates. And then there's a Jinja template, httpd.conf.j2. Now this is very common because the configuration on one web server might not match with another. But we might need to template out the configuration based on variables that are unique to that particular host, were that group of host or a subgroup of hosts, it really depends.

And the destination is exactly like a file module where we're just moving something from our control node to that destination. The only difference here is when we source it, we're going to run it through Jinja2 templating engine. And again, Jinja2 is not unique to Ansible. It is a very common framework. It's used a lot in building websites. So Jinja2 is used all over the place for templating things out. And when you see that, it's really nice that we're leveraging Jinja is because Stack Overflow, various forms, Red Hat Access. There's tons of people who built stuff in Jinja even before Ansible existed. It's been around a long time. It's very battle proven. We know that it's been tested in every various form.

So I'm kind of doing it side by side here. So on the left is the Ansible playbook. On the right is a configuration. And this is the actual Jinja template. So this is actually that httpd.conf.j2. So this is the j2 file. So what it's going to do? This is like the simplest example I can think of to put in here as. It's just going to replace these curly brackets variables. So we learned about variables. The templating is just going to do this on-demand. So http_port 80 is going to turn into Listen 80. And then the http_docroot, it's going to change into /var/www/ mysite.com, with the 1 task. Let's move over and look at a practical example.

So let's look at this playbook. This is a 1 task playbook using the template module we just learned about. It again, is very identical to the file module where you can set the owner, the group, the mode. This is only used on Linux servers. You would use something different if you were doing something on like a Cisco IOS box or a Windows Server box. A template module, however, works for all various forms of Linux, whether it's a BSD system, like a barely next, RHEL box or whatever you happen to have. The source is motd-facts.j2. We can look at that file in a second and the destination will be on, in this case node1 /etc/motd. So very, very simple. The j2 example, I guess VSCode had a way to color-code this warning but we'll not do that.

So welcome to ansible_hostname. Now this is a fact that we learned about. So these facts, this is a built-in one that it's going to gather, it's going to gather that distribution, the distribution version, the architecture, and the kernel. These are all facts that Ansible natively gathers. And it's going to set this on the motd. So let's try this. I kind of guess exactly what it looks like. Again, we looked at the facts before, if people are wondering. I can show that again, for, should just work. So you can see that all these key-value pairs are done in there. So ansible_hostname for the control node itself. I just ran and executed that playbook on the localhost, would be ansible-1. So you can kind of imagine what these ansible facts are going to look like in a second.

We're going to run the ansible-navigator run motd The right folder, in the right folder. No. If you're unfamiliar with Linux command, pwd is my current working directory and I was just in the wrong folder. So ansible-navigator run mots-facts.yml And then I'm going to do --mode stdout. Just because there's only one node and one task, we don't really need interactive mode for that. So, it's kind of gather facts. It's going to template that, it ran and again we can show idempotency if I run it again, it's not going to change. Now that template was templating a variable that changed like a timestamp, it would change, but in this case we weren't doing that. So again, it says ok and it's green.

So I'm going to SSH over to node1. Look at that dynamically generated motd. Now that's kind of the power of templating as we can use variables and you can kind of stretch that out. Imagine if I had a web server, I want most things to match. But I might want some particular data that's unique. I can just grab that from host vars for that particular box or my facts that I gathered about that box. So you can see that it said the host name Redhat 8.4, deployed on x86_64 architecture and then 4.18 kernel. So that completes the Jinja templating exercise that I wanted to showcase. We're going to move into roles and discussing, how roles work on Ansible or what they are and how to distribute them?

About the Author
Learning Paths

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, GCP, Azure), Security, Kubernetes, and Machine Learning.

Jeremy holds professional certifications for AWS, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).