Tech Talk Red Hat Ansible

Learn more about Red Hat Ansible like what it is, what job roles work with it, and more in our Global Knowledge Tech Talk hosted by Brent Brandow and joined by Red Hat experts John Walter and Scott Stewart. John Walter is a solution architect for Red Hat's certification and training team and Scott Stewart is the senior partner manager for Red Hat's training and certification team.

Red Hat Ansible Tech Talk questions

• What is Red Hat Ansible?
• What type of job roles benefit from using Ansible?
• What are the benefits of Ansible over Red Hat Puppet?
• How does Ansible connect to systems in an environment?
• What is Red Hat Ansible Galaxy?
• What is Red Hat Ansible Vault?
• How does Ansible integrate within the rest of the Red Hat portfolio?
• How about storage?
• How does Ansible benefit security engineers?
• How does Ansible benefit network engineers?
• What does it mean when Red Hat Ansible technology is human-readable?
• Where can you find Red Hat playbooks?
• Can you give some use-case examples?
• Why will Red Hat Enterprise Linux system administrators benefit from taking Ansible training courses?
• What Red Hat Ansible training courses does Global Knowledge offer?
• How does Red Hat make networking easier?
• Are there pre-req courses I should take before taking the Ansible courses?

When we talk about Ansible, we are talking about an automation language, right? So we can break Ansible down into two different products. We have Ansible Engine. That's typically what customers are talking about when they're talking about Ansible. That's playbooks. So it's simple, human-readable ways of automating tasks. And then we have Ansible Tower, which is a web UI that really enhances a lot of the functionality with Ansible.

So on the Engine side, we are able to automate tasks with something called playbooks. They're really simple YAML text files that just go through task by task. And they work on all the systems within your environment.

Tower provides something for more large-scale deployments. So when you think about larger environments, Tower allows you to have role-based access controls, job scheduling, workflow management, really for kind of soup to nuts as far as your entire deployment goes.

So I think throughout really your entire organization, different job roles are going to benefit from that. So I come from an administration background. So certainly from on an administration side. Automating those tasks, those repetitive tasks that you're having to do all the time, Ansible is a great tool for that. When we talk about playbooks, that's a lot of what people think about when they're working with Ansible.

So whether it's configuration or deployments, a lot of administration is doing the same thing over and over again. And when you have a playbook that you can just write once and run every time that you need to do it, that's always great.

On the same side, developers can kind of do the same thing. So I worked with a lot of developers who were always talking about how they had to spin up an environment if they wanted to-- let's say, a Ruby developer, right? They've got to install Ruby. They got to download their libraries. They have to do this every single time that they want to start developing an application. That's something that you can automate with an Ansible playbook as well.

In a DevOps team, Ansible is ultimately a DevOps tool. So I talked already about role-based access controls, being able to control who in your organization can touch which systems. You don't want your developers being able to interact with your production systems. You don't want your administrators necessarily working in your development system. So being able to really limit the access, so that you're able to kind of secure those environments and make sure that those environments are staying separate when necessary.

OK. And so there's more than one configuration management tool. I think Puppet is a good example.

Ansible is more than just really a configuration management tool. A lot of the difference of use cases-- and honestly-- we've had conversations with a lot of our customers-- it's not really Ansible versus Puppet, right? Ansible is something that you can use with Puppet. The big difference between the two is Ansible is what we call agentless.

So you have a central server that is going to house Ansible. That's where all your playbooks are going to live. It reaches out to all of your different systems. Those systems don't have to have any kind of Ansible software on it. It's reaching out via SSH, if it's a Linux or Unix-based system, WinRM if it's a Windows system.

And it's just running a set of commands. So you don't have to have Ansible installed on all these different systems in your environment to interact with them. Puppet is different. Puppet-- you have to have Puppet installed on all the systems that you want it to interact with.

Having said that, a great way to get Puppet installed on all of those systems is to deploy an Ansible playbook. That's something that a lot of our customers are doing right now, where they're having issues with their configuration management, Puppet isn't solving all of their problems. Ansible is something that they can use in conjunction with Puppet.

And Puppet's something that we've had integrated in a lot of our products for a long time. Puppet is something that's a big part of Satellite. And now we're moving Ansible into Satellite to co-exist with Puppet in that way.

Same with Chef. A lot of people are enhancing their Chef and Puppet deployments with something like Ansible.

The biggest way is you have your central node. That's where all your playbooks are going to live. The playbooks are interacting with inventories. So an inventory is just a list of systems.

And you can have those as sophisticated as you want. You could say here are my web servers located in North America. Here are my web servers in Europe. Here are my database servers in North America. I got my databases in Europe. And you can say, for this playbook, just interact with all of my systems in North America.

That's going to reach out. It's going to run a series of tasks on each of those systems, just by connecting SSH-- the same way that if I wanted to get into that system and run the commands myself. So that the biggest benefit for customers is that there's no added security risk. The same way that you're going to be interacting with those systems the same way that you would do manually, Ansible is doing it the same way.

And you can integrate your identity management protocols with that. There's a lot of SAML integration. So it doesn't have to be hey, I'm going to SSH in with port 22. You can make it a little more secure than that.

And then, on the Windows side, it's using WinRM, which is very similar to what, on a Linux or Unix-based side, SSH is like. So it's really, really simple. Because it's agent-less, there's not a lot of bloat to it. There's not really a lot of configuration that has to go in on your entire environment, as long as you have that central host that manages all of your playbooks and your roles.

Ansible Galaxy is two things. So, one, it's a community. And that's obviously something we at Red Hat talk a lot about-- the community and how important that is to the success of all of our products. Ansible is the same way.

Ansible Galaxy is a community where you're able to create roles. And roles, in this sense, are basically mass deployments for your Ansible, whether that's inventories, your playbooks, etc.

On one hand that's Ansible Galaxy. You go to ansible.com/galaxy you can download a lot of these different roles that usually the community is implementing. And then on the command-line side, on your system, Ansible Galaxy is also a command-line interface. So that's how you deploy those roles in inventories and those things that you don't necessarily want in your organization to have to start from scratch, you can go to Ansible Galaxy and download a lot of that stuff and just apply it to what you have in your environment.

Ansible Vault is another command-line tool. It's a way of encrypting and decrypting a lot of stuff within your environment. I talked about inventories a little bit. You don't necessarily want everybody in your environment to know these are all of my hostnames and these are all of my IP addresses. This is a need-to-know basis.

Ansible Vault is a way of encrypting that data. Same thing with-- a lot of times we're deploying systems with users and passwords. All of that might be plain text within an Ansible playbook. I don't necessarily want anybody that has access to that system to be able to just open up that file and be like, cool, well, I know Brent's password is "password."

You don't necessarily want everyone to have access to everything. And that's something that, just from the command line, you can secure those files. You can secure those role files, your playbooks, really anything that Ansible is touching, Ansible Vault is a way of securing that.

Red Hat is pushing this more and more and more. You're going to see that the longer that we go, the more integrations there are. So in our REL-- our Red Hat-Enterprise-Linux family of products-- REL is already shipping Ansible playbooks for deployment.

So a lot of what people are doing is spinning up VMs, or spinning up physical systems, spinning up in the cloud REL systems. You can use Ansible to do that. With Satellite, a lot of the configuration management that people are doing, they're using Ansible now to do that.

Red Hat insights, which is our predictive analytics tool-- let's say you have a configuration file that might lead you to be a little vulnerable to something, or if a new rated security vulnerability comes out, Insights tells you about that ahead of time.

And you can then have that output to an Ansible playbook and just run that into your entire environment. Same thing with our middleware offerings-- configuration management on that side-- so pushing out JBoss configurations within your environment.
What else? I know there's a million more. Name another product. I'll tell you how it integrates. CloudForms, starting from scratch, really deploying OpenStack, OpenShift, spinning up instances within OpenStack and OpenShift. That's all stuff that can be automated with Ansible playbook, straight from the Tower as well.

We have awesome [INAUDIBLE] integrations with our Ansible, just spinning up storage on demand with Ansible playbooks. You name it, you can pretty much do it. And if there's not an integration already built in with a playbook, you can just do ad-hoc commands, so basically just set up a playbook that will just run a series of commands on any system.

So if you need to set up storage on demand, and there's not really something in your environment that's already configured that way, you just write a few commands the way you would do it manually on one system, create that into a playbook, and then you can run it on your entire environment.

I talked a little bit already about Insights, which is one of our predictive analytics software. We have other integrations as well. So REL ships with an OpenSCAP, which is a security guideline and practices software.
A lot of security profiles are out there. So let's say if you're in the government, the NSA has one kind of security profile. The CIA might have a different role. DOD has a different one. So those are all collected into these security profiles that OpenSCAP has.

For a while, you just had to run OpenSCAP within each of your REL boxes, or Unix boxes, see what kind of vulnerabilities you were vulnerable to, and then remediate those manually. Whereas something like Ansible, you can run that once on one system, output that to an Ansible playbook with one simple command, upload that to Tower, and then your DevOps team can then push that to every system in your environment.

It's just a great way to automate the security stuff that you don't necessarily want to have to manually check on all of your systems. And my background at Red Hat was working with our security vulnerabilities team a lot as far as-- just last year we had something called Dirty COW-- which, by the way, I love the vulnerability names that we come up with.

Dirty COW was a privilege escalation vulnerability. So, basically, the kernel was vulnerable. If you were Joe Somebody, you could, with a couple of commands, escalate yourself through privileges, you have access to do whatever you want on that system.
Something like Ansible can really, really quickly push fixes that Red Hat provides to all of those systems, instead of having to go in and manually update. And some of our customers have five boxes. Manual updating isn't that much of a big deal.

Most of our customers have thousands of boxes in their environment. And that's not really that easy to do. And they're all different versions. You've got to check all these different versions to see if you were vulnerable. That's something that Ansible can do for you really, really easily.

We have an entire network automation option within Ansible as well. And I don't think I've really touched on this, but Ansible is something that can really touch everything that's out there.

When we talk about network devices, routers, switches, VLANs-- you name it within your networking systems-- you can reach out and configure all of those systems with Ansible.

I was at our tech exchange last month. And one of our biggest customers had something like 150,000 different network devices. And they were automating all that with Puppet, or they were managing it all with Puppet. And their big concern was, we're not really able to interact with all these things. We have to create all of these manual integrations. And that just takes a lot of time.

If we add new devices to our system, we then have to spend all this time creating Puppet configurations to interact with those. Ansible has those integrations built into them. So we have Cisco, Juniper-- what are some other network devices? You name it, they're all out there.

So the way that Ansible works when you're writing a playbook-- there are basically a series of modules. And there are something like 12,000 modules out there, hundreds of network-specific modules. So you can write out there-- you can monitor configuration drift. If you're just configuring your networking systems, you can do that as well. I mean, there's just a lot of monitoring and ongoing set-up that you can do with that as well.

So the playbooks are written in YAML. And anyone that doesn't know what YAML is, I think, immediately is oh, well, that sounds like programming. I don't really know what that means. So the way that the playbooks work, they're task-based. So you say, I want you to interact on these systems. I want to run this command. And then I want you to run this command. And then I want you to run this command.

And the way that it outputs, it goes through task by task. And it says, all right, well, on this task you want me to install this service. I'm going to run it on this system and this system and this system. And it tells you if it's successful or not.
The way that it's written is really, really simple. So I have absolutely no programming experience in my life. I shouldn't say that. I took AP Computer Science when I was 14 years old. So something like 16 years ago.

How did you do?

I passed.

That's good.

I didn't take the exam.

[LAUGHTER]
So, for me, going through, I was initially a little nervous as far as, well, I might not get this. Everyone keeps telling me how easy it is. But the people who are telling me how easy it is are really, really, really smart people.

I think that anyone with a little bit of experience writing playbooks-- just understanding what the format is-- task, command, task, command, task, command-- that's all that it is. Once you know a few of those different modules-- and the modules are pretty simple.

Anyone that's a Linux administrator or Windows administrator, those modules are all going to be really familiar to you, because they're really just commands that you're running on a day-to-day basis.

Anyone else in your organization who isn't really fingers on the keyboards on the administration side can go through and read those playbooks and understand exactly what they are. They're really self-documented. On the DevOps side it's really nice because, really, a playbook is a process. And it is a way of really documenting a process.

That's something that, when speaking to a lot of customers, a pain point is, a lot of our DevOps team complains to us that we're not documenting what we're doing. That's something that a playbook does for you. You don't have to necessarily go through and create documentation for that stuff because the playbooks are already doing that.

They're all over. So the Ansible community is really, really, really active. There are something like 15 million crazy different playbooks that are on GitHub. And if you go to Ansible.com, there's a lot there.

It is one of the most helpful communities that are out there. I'll say that I went on their freenode IRC channel. They're still using IRC, for those of you out there on YouTube that is still like me and still connected at IRC.

I went through when I was going through the Ansible course and just had a few questions about how to make something specifically work. 50 different guys chimed in and helped me out as far as writing a very simple playbook. So for those of you out there that are worried about exactly how to get started, the Ansible community is a great way to get started with that as well.

And then, obviously, shameless plug for us-- our training is a great way to start. I was very, very nervous and hesitant to get started in that. And then, by day one, I was already writing my first playbooks successfully and understanding it, because it's just so simple.

And that was after your first day of class, taking your first Ansible class.

Yes. That was five hours of hearing a little bit about what Ansible was, installing it, and then, by that point, I was already writing playbooks and deploying playbooks.

So we talked a little bit about configuration management. That's a big one. I think that that's kind of the barrier to entry for a lot of people is, oh, this is an alternative to Puppet. This is going to basically serve that purpose for us. But there's so much more than that.

This can be integrated into your DevOps workflow really, really well. And there are integrations with things like GitHub and Jenkins. We talked a little bit about some of the networking use cases, like checking on configuration drift. That's a really, really big problem.

If you have configuration drift, then your system time is off, which means if you have a web server that things may not be able to connect anymore. There's a lot of different issues that can come about with that. And we talked about security as well, making sure that your systems and your environment are secure.

There are hundreds of use cases out there.

Having been a Red Hat-certified system administrator, a lot of my day was configuration. And so whether that was just spinning up new systems, deploying web servers, those are things that were repetitive tasks I was having to do constantly.

Those are things that, now, with a simple playbook, I write that one time. And, really, I'm just writing the tasks that I would do normally to do that-- converting that into a playbook, I can deploy that, and then, boom, I've spent the time doing that once. And now I never have to do that again. I just have to run one command to spin that up right away.

And I think everybody who's a system administer, I think they'd all raise their hands, after they've taken one of our system admin classes or classes, they'd probably raise their hand-- I want to continue my training with Red Hat.

And I think that Ansible is probably the most logical next step for system administrators after they've gotten to that certain level-- either certified Red Hat-certified system administrator or Red Hat-certified engineer.

Then to John's point, it's very beneficial just from a day-to-day standpoint, to have that skill with Ansible to be able to deploy those playbooks.

Our first course is a course called D0407. It's our introduction to Ansible. So it's all about Ansible Engine. So you're going to learn to create your playbooks, creating inventories-- and inventories, again, are how to manage all the systems in your environment. You'll learn a little bit about Ansible Vault and Ansible Galaxy, which we talked about before.

But a lot of it is just focused on creating playbooks. You'll start out simple, as far as installing and starting a service. And then you'll get really complex, to spin up an environment from scratch, all the way down to spinning up a web server, throwing your index.html file into it, whether it's custom or not.

It really gives you a holistic sense of all the different things that you can do with Ansible Engine. Beyond that, we do have an Ansible Tower course as well. It's D0409. That will give you all of the introductions to all the different features of Ansible Tower. So that's role-based access control. That's job scheduling.

So a lot of what my experience as an engineer and admin was was deploying straight to production, which is pretty much the worst thing that you can do as far as I'm concerned.

But what you can do with Ansible-- and specifically the Ansible Tower-- and you'll learn this within the course-- is basically set up a playbook that will spin up a development environment, run your playbook, and if that's successful, spin up your production environment, and then deploy it there. So that's a really, really good benefit.

Beyond that, there's centralized logging. So if you have something like Log4j or Elastic, something like that, there are integrations for that as well. So learning about the different integrations-- because a lot of people, they're hesitant because they have all of these different services within their environment. They don't want to add something else.

What they don't understand is that Ansible can integrate all those together, whereas it's been this hodgepodge. We do also have a specific Ansible for networking configuration course, network automation course-- that's D0457?
467.

And that one's actually one of our newest courses. That's going to go over everything that we were talking about earlier, as far as monitoring networking configure-- or deploying networking configurations, monitoring networking drift.

And that's something that has been a big headache, I know, for a really long time. So automating that has been a really, really, really good story for us.

We also offer-- SSQ number D0410 and that's actually a combo class. We teach all of the content in the Ansible for Automation class and all of the content in Tower, then combine it, make it into a rapid track, teach it all in five days. It's probably six days worth of content. We teach it in five days.

So if somebody's really interested in both, Engine and Tower, there's an opportunity to take it all at the same time. But I think it's interesting, too, if we start talking about Red Hat training and some of the offerings out there-- to John's point earlier, Ansible works with everything inside of Red Hat, off from a product set standpoint.

Red Hat has an offering we offer through Global Knowledge. It's called Red Hat Learning Subscription. And what that is, if you're a REL system administrator, but you're also tasked with Ansible, you're going to get all the REL system administration classes there and all the Ansible classes there.

We make it a subscription, make it a one-year subscription, just like our product subscriptions are. We wrap all of our training content. So if you're an Ansible administrator or a REL administrator. You're also tasked with Ansible but, also, you're responsible for Satellite.

Or let's say you're starting your DevOps play inside of your company, and maybe you're going to be tasked with OpenShift from a platform as a service standpoint. The beautiful thing about Learning Subscription is that you can take all the classes that you're working on today, what your job role is today.

But also you can prepare for the future. If you've got a product deployment's going to happen in six months and you want to go and prep on it beforehand and start doing tests on it. A great way to do that is to take the classes inside Red Hat Learning Subscription.

So we take all the classes from JBoss, to our cloud classes, to OpenStack, to OpenShift, to Ansible, it's over 40-plus. I think the last count was around 47, 48 classes we have. And we put it in a nice little package, give you access to it in Red Hat Learning Subscription.

And, oh, by the way, you get all the labs for every class that we teach. And there's another version, Red Hat Learning Subscription Standard, that gives you five exams and also two retakes as well.

So it's a great opportunity if you're interested in Ansible, but also have responsibility for other things Red Hat-related, or have interests in other things Red Hat-related, to buy that Learning Subscription. Because you're going to get access to be able to learn on your own throughout that one year. And we have a couple of titles that are available through Global Knowledge today if that's something you guys are interested in.

And you're going to find, more and more, especially as Ansible comes more integrated into our product portfolio, that our training courses are also going to have Ansible integrated into those courses as well.

So, for instance, we have a Red Hat security course that's all about physical, virtual, and cloud Linux and [INAUDIBLE] physical, virtual, and cloud, that's all about automating security. You'll touch on running playbooks for securing your environments. You'll touch on OpenSCAP, which we were talking about a little bit before.

You'll find that our Satellite training is going to have Ansible integrations that you're going to learn about whenever you take the Satellite course as well. So a great part about the Learning Subscription is once you have that kind of narrow focus on one product, you'll learn that it is present in the training for all of our other products as well.

And one thing about Learning Subscription, too, is that today we have a certain set of courses that are available. But it's not like we're going to stop releasing products. And typically courses attach to products very, very quickly.

So you get some investment protection too if you're on a certain version of certain software. You want to train on that, but also there's a new version that comes out, we have new curriculum around that as well, or a new product comes out. Or something like Linux, it updates, and you get the opportunity to take the classes now.

And then six months from now, eight months from now, nine months from now, there's a new course available, you're going to get access to it as well without having to buy something new from Red Hat.

We recommend that they be at a Red Hat-certified specialist-- RHCSA level at this point. It's not completely necessary. I will say that. The big thing is-- and Scott talked about the labs-- all of our courses are very lab-intensive.

They're hands-on. They're practical courses. And they all exist within the REL environment. So if you're unfamiliar with REL, there is going to be a bit of a learning curve whenever you go in.

But having said that-- and we've touched on this before-- Ansible itself, as a product, is something that is OS agnostic. You can deploy it in Linux. You can deploy it in Unix. You can deploy it in Windows.

You can deploy it in any cloud. So throw it up on AWS, Alibaba, Azure, you name it. Ansible, I think, is really the only course that any customer-- and when I went through it, I was with guys that are only Windows admins. So, initially, writing the playbooks there was a little bit of a learning curve there.

Once they got that, they totally saw the value. It totally clicked with them. So as long as you're familiar with navigating a command line, writing within VI or text editor, you're going to be able to be successful in the Ansible course.

View Red Hat Ansible training courses >