Red Hat’s Cloud Domain Architect, Jason Ritenour, has a diverse background in virtualization, storage, containerization, and open source technologies. He sits down with our Red Hat Sales Director, Rich Savage, to take a deeper dive into automation with Red Hat in the public sector.
Rich Savage: Hello everyone. I'd like to thank you all for joining our podcast today. To take a deeper dive into automation with Red Hat in the public sector. I'm Rich Savage with the Red Hat team at Carahsoft Technology and I'm here today with Red Hat's cloud domain architect, Jason Ritenour. Thank you for joining us today, Jason.
Jason Ritenour: Rich, thanks for having me. Good to be here. I always love coming to visit you guys at Carahsoft and looking forward to talking about automation with you today.
Rich Savage: Great. Jason, the team at Carahsoft often receives questions from our government customers asking what automation is and how does Red Hat Solutions enable it. And also, what benefits will their agency ultimately realize. So for our listeners, Jason, let me start by asking you a couple of questions here. The first one that we hear most often is why should agencies consider automation solutions?
Jason Ritenour: Well, that's a good question, Rich. Back when we first started really getting into the automation space, the questions were, are you automating? Today, the question is more, what have you already automated? How are you doing so, and how can we help you improve and streamline that process?
Jason Ritenour: Now what we see a lot of times, we actually talked to a lot of agencies today that are already using Ansible or another tool like that to automate like their Linux workloads. But then you have like the Windows guys are out doing things on Powershell, you have the Network guys doing their own vendor specific automation tools. So a tool like Ansible was a chance to kind of break down those silos and bring them all together under one umbrella using the same tool, the same like Rosetta Stone basically, to bring everybody on the same page, get them all speaking the same language.
Rich Savage: Great. You alluded to a few of them I think already, but what are some of the critical obstacles to automation?
Jason Ritenour: As far as technical obstacles, there aren't really many. One that's sort of technical in nature, but maybe not completely technical, is not having a clear understanding of what you're trying to automate. You look at something and it might look like a single step when actually there's many steps behind the scenes to get from point A to point B. And then there's other things in the environment that are automated by what you're trying to impact. Take like a self driving car, for example. I can just plug in my destination and you might think, "Okay, that's it. It's going to take me there. It's going to barrel down the road at 80 miles an hour and that's it." But really there's more play. It's got cameras and sensors to detect where other cars are. It's examining like traffic lights and signs, it's detecting what the road conditions are like due to the weather so it can adjust that speed accordingly.
Jason Ritenour: So there's so many different things that come into play with automating even a single task and you really have to be cognizant of what you're doing and how it's impacting the environment as a whole. For example, I worked with an agency several years ago. This was actually pre Ansible even, and we were trying to automate their deployment of JBoss workloads. So it was this massive monolithic process before that took several weeks and we started off, we could have very well gone in and tried to boil the ocean and do it all at once, but it ultimately would've resulted in failure. So first, we began automating just the building of the servers and installing the software. Once we had that working, it's like, "Okay, let's start pulling in the source code and deploy the application," the actual code onto the application once the servers are up.
Jason Ritenour: Once we got that win, it was, "Okay, let's automate deploying the load balancer pool and putting a VIP in front of them." Then we hit our blocker because the next thing we want to do is automate the deployment or the request and granting of SSL certificates. The security team said, "No, we don't want you automating that. We want an actual human being to come in and sign off on it and validate the request, make sure it's legit, make sure it's nothing nefarious going on." So that brings me to the second obstacle that we see with automation. And that's culture. Now, sometimes there are reasons for being a post automation, like in that SSL, in the security team's instance, for example. It was they wanted somebody to actually be accountable for what they were doing and they wanted a human being to have the final say on granting that certificate.
Jason Ritenour: Sometimes it's fear of automating yourself out of a job basically. And that particular agency I was working with, that I alluded to, we eventually got the win and got the security team to go along with what we wanted to do. It required a little bit of give and take, we had to assure them that somebody is actually going to be reproving all requests at the very beginning and somebody on the ops team will ultimately look at the request, ensure that it's valid, ensure that all the other check marks are in place, so to speak. And they will ultimately sign off and be accountable for what's deployed. And it was a matter of bringing some of our high level architects and to talk to their people. It's really, you have to kind of take those cultural battles and make sure you understand the other team's concern and help them to talk through them, to give them some assurances. And sometimes you have to kind of take a step back and maybe not go as far as you initially intended to, but you can eventually get everybody on the same page I believe.
Jason Ritenour: So that's something that both the teams at Red Hat and Carahsoft can do. We can help you assuage any concerns that the people that are maybe opposed to automation are afraid of it and kind of help them take that step forward.
Rich Savage: Yeah, I can definitely see that being an obstacle that many IT organizations have to face over time. And I think there's a lot of opportunities for automation within an IT infrastructure environment. I guess, what specific processes can agencies automate with Red Hat?
Jason Ritenour: Well, I mean it's not hyperbole to say you can automate just about everything with Ansible at this point. It originally started off as a tool for just automating Linux workloads. Today, it can automate Windows platforms and Microsoft actually heavily contributes to the Ansible project and has helped us build modules for both windows and Azure. On that note, it can automate building things in cloud environments, Amazon instances, relational databases, what have you. Can automate Network Gear. That's the big thing we're seeing at this point, a big push into automating, building out the network environments, both physical network devices as well as software defined networking. And that's not even getting into the things you can automate that maybe there aren't official modules for, but like we can talk to restful APIs and do things against them. We can use the command and show modules to automate things on a Linux system that we don't have a module for.
Jason Ritenour: So really, if you can think of it and you can put it to paper, we can probably come up with a way to automate it with Ansible.
Rich Savage: Great. What are the advantages of using Red Hat Ansible over other automation tools that exist in the market?
Jason Ritenour: Well, I think Ansible has a lot of things going for it. The first of all is the fact that it's so diverse, it really is like a Swiss army knife. There are a lot of tools that can, for example, provision workloads in a public cloud. But all they do is build the instances, they can't get in and really do any configuration on them after the fact. They pretty much they fall back into using a shell script or like a cloud and net config file. And after that initial run it's done. It can't go in and do like any updates, it can't push any code to it or what have you.
Jason Ritenour: But compare that to like a YAML playbook and even somebody who's not technical in nature can probably look at it and get a rough idea of what the playbook is trying to do. So it is self-documenting in that regard. So agent-less, self-documenting fast and efficient using all the native protocols that's already installed on the system.
Rich Savage: Excellent, excellent. And we hear a lot of our customers are moving to DevOps, DevSecOps methodologies going forward. Does Ansible help customers move that direction?
Jason Ritenour: I would say so. You need some kind of tool like Ansible and I think because of all the reasons I alluded to, Ansible should be that tool from a DevOps standpoint. It goes back to what I was talking about earlier with getting everybody on the same page and I think it helps the Ops guys who, I'm personally am an Ops guy by nature. I know a little bit about a lot of different programming and scripting languages, but I've never been a developer.
Jason Ritenour: But using Ansible has helped me of get into that Dev mentality. So I understand the principles of like putting everything in source control, versioning it, obviously making good comments so my people I'm working with understand what I'm trying to do. I think it helps get everybody on that same page. And again, it helps the Ops guys understand the Dev world a little bit more and I think it helps the Dev world understand what the Ops guys are doing with how they approach a deployment and whatnot.
Rich Savage: Are there any success stories that stick out to you that you feel would be relevant to share?
Jason Ritenour: Oh yeah. I mean, everybody who's using Ansible is winning. I mean that's the bottom line. Now the thing with Ansible is we're seeing now like a second wave of adoption. You take customers like NASA who have been using Ansible for a long time. And NASA of course has always like on the bleeding edge and then really forward thinking with their adoption of emerging tech. But they were one of the first government agencies I can recall that was using Ansible heavily in production. They actually did like a massive data center migration a couple of years ago using Ansible. And today they're now on that trail of automating all their networks. We see a lot of agencies that they adopted Ansible for Linux a couple of years back and now they're saying, "Okay, what else can I automate? I had so much success with Linux. I want to automate my Windows workloads. I want to automate building out Networks."
Jason Ritenour: Tennessee Valley Authorities, another big customer in the sled space that are doing just that. Now they're on that kind of riding that second wave of doing their network automation. And on that note, even though they're not like a federal agency, they're certainly in our space and we've talked to them a lot, Microsoft. They actually just put out a case study last year discussing how Ansible helped them automate all their network build out globally. And think about that for a second. Can you imagine ten years ago Microsoft putting out a statement saying that they were using our Red Hat open source tool to automate anything? So I mean that goes back to that cultural shift that I talked about earlier under the guidance of Satya Nadella, they're much more embracing of open source. There are big contributors to Ansible and other open source projects. So that just shows that when you embrace open source and you embrace that culture of collaboration, the things you can achieve.
Rich Savage: the world is definitely changing in the favor of open source, that's for sure. So if the first wave of Ansible was data center migration and maybe the second wave now is Networks, what might be the third wave?
Jason Ritenour: Oh, it's hard to say. I mean there's so much stuff Ansible can do. I'd imagine the next big thing is you're going to see more tight integration between things like say Ansible and OpenShift. So you're going to see, if you look at like an OpenShift 4, there's a lot of Ansible under the hood doing things like the operators and the configuration of your workloads and that kind of thing. So I think you're going to see a lot more of Ansible automating these cloud, horizontally scaling workloads and the things that's going on behind the scenes in there.
Rich Savage: Great. Thank you, Jason, for all this great insight. For our listeners, if they want to learn more about Ansible, where do you suggest that they go to find that out?
Jason Ritenour: Well of course go to Ansible.com, it's still its own distinct site separate from the Red Hat site. So that's where most of our Ansible content lives at this point. We've got several great white papers there, several how-to videos, all the modules are well documented. They're telling you how to utilize them in a playbook and going over some of the more advanced things like roles and the new thing that we recently added, the collections where we certify content from various vendors. That's a great place to start. There's also a nice book if you're looking for either a Kindle book or like an actual hard copy, there's Ansible for DevOps, which you can buy an Amazon and other fine booksellers.
Rich Savage: Perfect. Those are great suggestions. And Jason, thank you again for your time and all the insights and information. We really appreciate it. And for our listeners, please go to the suggestions and the websites that Jason has mentioned. And then also there's some additional resources on the podcast landing page that you can check out. And of course you're always welcome to contact us anytime at Redhat@carahsoft.com or (877) 742-8468. Thank you again and see you next time.
Jason Ritenour: Hi there. I'm Jason Ritenour. I'm a cloud domain architect with Red Hat, and, today, I'm going to talk about Ansible and I'm going to show you some of the ways we can do automation against the system that we don't have access to.
Jason Ritenour: Imagine you're a systems administrator and you've got several hundred web servers running maybe some static content, maybe some dynamic content, but you need to do an update on these web servers and you can't... You don't have direct command-line access to get in and make any changes. You do, however, have access to the code repository where the content is stored, so I'm going to show you.
Jason Ritenour: As you can see on my screen, I've got this webpage up, and, if you notice, there's a misspelling. That's not how we spell index, so I want to go in and I want to make a change to that page dynamically without actually getting in and opening it up and... like a text editor and making a change that way. Especially if I've got several dozens or several hundred servers running the same content, that's obviously completely inefficient, so I'm going to go here to my GitHub code repository, and you can see the Ansible playbook I use to deploy this web server. You notice it went through and it did things like install Apache. It set this content.
Jason Ritenour: You can see the misspelling is actually here in this playbook, and then it allowed traffic through the firewall and it enabled the services appropriately, so what I'm going to go do here at this point is I'm going to edit this code repository, this playbook right here, and I'm going to change this misspelling. I'm going to correct it. I'm going to commit my changes, add a message here saying that I corrected a misspelling.
Jason Ritenour: Now, my playbook is updated at this point and the spelling is correct, but I need to actually run this playbook on this affected system in order to correct that mistake, so I'm going to go here to job templates. This is Ansible Tower, by the way. This is our graphical user interface for Ansible that allows you to manage your systems at scale. It allows you to collect systems into inventories so that they're more easily manageable. We can pull in your playbooks from source control.
Jason Ritenour: I'm going to run this install/update Apache playbook at this point, and this is going to go through. The first thing it's going to do is it's going to sync my inventory because it's getting my inventory from the virtualization platform that my web server is running on. In this case, it's Red Hat virtualization, so Ansible is going to go talk to REV to see if there's any new virtual machines that it needs to be aware of and then it's going to pull in the updated version of that playbook from source control, and then it runs through its process.
Jason Ritenour: The first thing it does is gather facts where, basically, it's talking to the system and it's finding out information about it. It's asking it things like what is your host name, what is your IP address, how much free memory do you have, how much free hard drive space, et cetera, and then you'll notice it went through and it... Some of these steps they, "Okay." Some of them say, "Changed." When it says okay, that means that it didn't actually do anything to the system because Ansible went through and it queried it and it found out that it wasn't going to actually have to do anything to get to that state described in the playbook, so, since Apache was already installed, it just said, "Okay." It skipped over that.
Jason Ritenour: It did, however, change our index file, so, if we click on this, we can get some information about what actually happened here, and it tells you the file that it went through and made the modification against. It does this information like the owner, group, the permissions on it, et cetera, and then everything else. The firewall rule was already in place. It did restart the firewall because that's something that is going to happen regardless. It's always going to restart when I say to restart the service, but if I go back over to my webpage now and I do a refresh, you'll see that my index is now correctly spelled.
Jason Ritenour: Now, this is good for just editing static content, but what if I wanted to do something that allowed some user input at the time of running the playbook? Let me go back here again. I'm going to make another change. I'm going to edit the index again, and you'll notice this variable here. Anytime you see in a playbook something enclosed in the double curly braces, that means it's a variable. Now, in this case, Ansible_hostname is an example of a fact that's gathered at the time that the playbook runs, so that's something that's dynamically going to be pulled from each system, so, that web, if you go back over, it says, "This is the index of Web." Web is the host name of this system, so, if I go through and I change this to something else like... We'll call this run message.
Jason Ritenour: Actually, let me go ahead and change all of this. Let's just eliminate all this text. Run message is going to be our variable name for the message we're going to put here on this index, so I've updated my source control. I've saved it. I'm going to go back here to my Ansible Tower, and, now, I'm going to go in and edit this job template because I want to make some changes. I want it. You'll notice, when I ran it before, it just automatically executed without any user input. This time, I'm going to go down here to my extra variables and I'm going to ask it to prompt me on launch, and I'm going to put in a variable called run message, and I'm going to make the default just a blank space. I'm going to save that.
Jason Ritenour: A couple other things I want to point out here, you'll notice I can enable things like a webhook, for example, so I can make it so that, by using web hooks, as soon as I commit the source control change, it would automatically trigger this playbook and run the... and make the appropriate changes against the systems in this inventory, but I'm not doing that in this case. Everything is being done manually, at least triggering the launch of the playbook, so, again, I'm going to go ahead and launch this job template. It will prompt me now, asking me what I want to use for this run message, so I'm going to say something like, "This site will be under maintenance Saturday, 2/8." I'm pretty sure the eighth is Saturday. Hopefully, I'm right.
Jason Ritenour: I'm going to go ahead and click next here, and then I'm going to actually launch this, so, now, again, it's going to go through this process. It's going to reach out to the... do an inventory update. It's going to pull in the most recent version of this playbook from source control, and you'll see here it's telling me now that it's running with this extra variable that I just provided, saying that the site is going to be under maintenance, so we'll give it a couple seconds for it to pull in the updated inventory in the updated playbooks, and then it will actually start executing the job, so, again, it's gathering facts. It's going to skip over the Apache install install because, again, that's already there. It's changing the index file, nothing to do with the firewall other than restart it, and it's done, so I'm going to go back over to my index again, reload it one more time, and you can see now it's running with that message I supplied, "The site will be under maintenance on Saturday, February 8th."
Jason Ritenour: That's how we can make some changes on a system using, again, changes that we do at our source control to the playbook itself or how we can do it dynamically by supplying input at runtime through Ansible Tower, and, again, imagine running this against several dozens, several hundred servers at once. It's certainly a more sane way to approach rather than going in and making manual changes to the files one by one on each individual system.
Jason Ritenour: One more thing I want to touch on before we wrap up here is a new concept we introduced in Ansible 2.8 and officially supported beginning in 2.9, and that is Ansible Collections. Now, in the past, Ansible modules were married to the Ansible release. We only updated modules when we updated the actual Ansible runtime, so, if we had some changes we made in Ansible modules, they wouldn't come out 'til Ansible 2.5 or 2.6 or what have you. Now, with Ansible Collections, we can allow vendors to make their own versions of modules, and we can certify them independent and decoupled from the Ansible release themselves.
Jason Ritenour: You'll see that here in our Ansible Automation Hub we have an example of several partners that have begun embracing this new way of distributing content. For example, Microsoft, they have several modules for Azure, and this is another. This is a great example of how having this decoupled from the Ansible runtime release has helped us, because cloud providers are constantly adding new services and new resource types, so, because we're able to allow them to release them at their own pace rather than waiting for us to update the Ansible runtime, we can get this new content out there quickly.
Jason Ritenour: Collections consist of more than just modules, however. There can also be different plugins, different actions, other forms of various collateral that could be distributed independent of the actual Ansible runtime, and, again, if you look here in the Automation Hub, this tells you how to actually install these collections. It's simply a matter of running Ansible Galaxy, collection install and then the name of the collection, so, if you want to see more collections other than these ones that we've certified here, you can go to galaxy.ansible.com, and that's a great place to start.
Jason Ritenour: If you are a current Ansible Tower subscriber, you can go here to cloud.redhat.com and check out the Ansible Automation Hub. In addition, we have plans to offer this as an on-prem version that you'll be able to run in your own data center, so look for that coming in the near future, so thanks again, and I enjoyed running this demo for you.