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

Introduction to Ansible

Developed with
Red Hat

The course is part of this learning path

Introduction to Ansible
Overview
Difficulty
Beginner
Duration
2h 47m
Students
508
Ratings
5/5
starstarstarstarstar
Description

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.

Transcript

So let's get started with the introduction, why they Ansible automation platform and what can it do? So I always like to start with a story. So obviously that can read this slide. Automation happens when one person needs a problem than ever want to solve. Again, I think that comic is always showing like, give a lazy man a problem and they will find the most ingenious way to solve it. I think most people who get involved in automation like to think of themselves as kind of clever that they're getting rid of tasks they don't want to do anyway. And I think they all have their own story. Mine is if we go back to the past to when I was probably, I don't know, between 12 and 15, my parents forced me to learn the trombone and do band. And I had to practice said trombone every day for an hour to two hours. I don't even remember. I remember I did not like doing that. So one afternoon I recorded myself practicing the trombone into a nice microphone that I must have had. I recorded scales, I recorded songs, I recorded some jazz songs like all the different things that they would've you're practicing. And I fed this back into when AMP, I put it on shuffle mode and then I would play video games with here phones on. And they would hear this out and amp of me practicing the trombone. So might not be the best example, but I cleverly got out of practicing jumbo and I think for two or three weeks before I got caught and in trouble. But automation is happening to allow more free time for folks. And I think automation sometimes can be really clever to solve problems, but it's becoming imperative for businesses to solve these problems because we don't have time.

Well, my examples a bit funny and a little bit more humor. I think we can take the same idea of taking tasks that are boring, repetitive, that don't need to have an architect assigned to them and apply it to any silo across an organization. So these kind of silos exist because of how much time or wasting and each of these individual things. The other way I kind of look at it is a lot of people don't care about a network engineer. And like my background's a network engineer, they don't care about the system administrator, they don't care about the security engineer. What they care about is the business outcome of an application. And the way I kinda talk to This is like my wife is very technical. She's a very smart person. She uses Tech. She's in the medical field, but she doesn't care what server, what engineer, what's happening for her Instagram account. She just wants the pictures to load. And we need to start thinking of IT infrastructure as business outcomes and not focused on maybe the specific thing. And automation allows us to start measuring the success of this and make getting out of these domain-specific tools and start focusing on orchestration automation for entire organization.

So why are they in some automation platform? Obviously, there's a lot of different orchestration automation tools out there. There's different DevOps tools. And we think we are very powerful. We have a lot of different use cases that we cover everything from network security systems, containers, public Cloud, private Cloud, cloud native. But were simple. And we're very simple to the point that, that's why you've heard of ansible.

Let's try wire in this class is we're becoming the de facto standard of automation, which lowers OpEx for everyone because it makes it really easy for someone to learn and get started and then trust automation. Then finally we're agent list, which I think kind of circles back to the other two points. And what this means is there's no software installed on what we're automating. And this means ansible is uniquely positioned to work really well in environments where there's just an API, Public Cloud or a ITSM tool like service now, or talking to a device that's more like an appliance, like a Cisco switch or a NetApp device, storage device. Because they don't necessarily have permissions for us to install Python or PowerShell or equivalent code and execute it from that device, we need to be agentless, meaning that we're going to execute on the control node. And then we use the connection method that we need to talk to that device, whether it's API, a command line, whatever. So there's a ton of different use cases for hints of automation, platform or Ansible in general, is, you can see some sort of use case on the bottom here, right?

So we have use cases on infrastructure. And that can be firewall servers, load balancers, Cloud's Application, storage containers, network devices, virtualization platforms. That could be VMware, that could be Rev, that could be anything. And what we'd like to do is say like, we really want people to think of ansible more than just Config Management. And that's, I think the main takeaway from this slide is that anything that you can do, a human can do, we can automate in some capacity. You're kind of looking more for that overall story like what is the business outcome? What do we want to automate? We can help you get there with Ansible automation platform.

And again, circling back to that silos kind of problem that we outlined. Imagine. One of these, the silos is, I don't want to do music, I want to automate music practice and I wish I could upload skill set into my brain. But in a real organization we have we have all these different silos in silos are needed. I'm not saying there's not a need for specialists or people that are a background of a network engineer, or they're a systems engineer, or their system administrator, or they're an SRE, we need those specialties. We just need to scale them out by automating stuff that they know how to do. We can't call the same guy hero that of that organization over and over because you can burn these people out. So this is a way to scale out people and create consistent governance between all these different groups.

Imagine on the Edge team that there's a use case where we're always doing the same thing. That could be an automation script. You let other teams run on your infrastructure and then you kind of create guard rails on it. And we'll circle back to that later in this presentation in talking about what that means and how that's implemented with Ansible automation platform. So what is in the Red Hat Ansible automation platform. So there's Ansible automation components, including automation controller, will dive into.

There's hosted Cloud services. So these are on console dot run out.com, which includes services catalog, it includes automation hub, which is kind of like an app store for content. And includes automation analytics, which is now called Red Hat Insights for Ansible automation platform. And finally, the content itself is part of the Ansible automation platform. So content is stored in what we call collection, which we'll do a deep dive in. And collections can contain modules that can contain roles which are pre-baked playbooks that are reusable. So this now allows different teams or vendors that you know and love to share automation with you. So it's kinda pre-canned where you're like, Hey, I'm probably not the first-person automate changing the message of the day on my Linux server.

So you can just take this role, reuse it in a collection and off to the horse races you go. So when we look at this kind of from a top-down view and want to see all the different components. On the left of this diagram we have the different users. And I think a lot of these are involving, and it's not necessarily due to Ansible automation platform evolving the type of users, but Ansible or automation in general, is changing organization's culture. So you have this idea of operators, domain experts, users, content creators. And these can be even sub-domain out, right? We have a network domain expert in a security domain expert, and a application expert, right? And they're going to use different content domains.

So we kind of divided up our content domains, which is that middle section here. Four major categories. Infrastructure, which to us for this purpose of this diagram means Linux servers in Windows servers, cloud, which means public Cloud, private Cloud Container native, or Cloud native, or how we implement with Kubernetes and OpenShift network, which is automating network switches and routers from like Cisco, Arista, and Juniper. And finally security, which is Firewalls from again, the same vendors, but it also includes things like checkpoint. It includes integration with a multitude of different tools, including IBM QRadar and sniffing packets. And kind of implementing this into an entire use case for not just automating security devices, but automating where they fit into the ecosystem. And on top we have controller, which is the web you, I will do a deep dive on automation hub, which has a hosted part and private Automation Hub which is hosted on premises. And that is a content repository for your content.

We have automation services catalog that I talked to about before. This is kinda like a lightweight ITSM tool. So it allows you to do some ordering of it. And we kind of see the use case for consumers within your organization that are engineers. So imagine like I'm being onboarded. I want to order a laptop and get my desk and figured they could just press a button and it takes care of the approvals and everything behind the scenes.

Then finally, insights for Ansible that allows some analytics. And that's how we measure success of automation across our enterprise. And then finally, on the bottom we have Ansible core, which I'll kind of elaborate on a little bit. So, well, we say, don't take my word for it. Obviously, I'm going to be biased. I love Ansible automation. I think it's awesome. I left my previous company to come work on and some automation. And that's why we kind of lean on the analysts in our slide decks and kind of show what, what they're showing.

So in this case, the Forrester Wave has showed us as a leader multiple years in a row. Now, we see the highest possible score. So I never say, don't take John's wort for it, but you can take foresters word for it. And you can see that we showed up very strong and we competed with a lot of huge companies out there. And you've probably heard of almost all of these companies. So hopefully that provides a good overview of ansible. And now we're going to do a deep dive in the next section, starting with Ansible core.

About the Author
Students
106789
Labs
59
Courses
113
Learning Paths
91

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).