Episode Thumbnail
Episode 20  |  31:57 min

S1E20: Red Hat Experts Answer Your Ansible Questions

Episode 20  |  31:57 min  |  05.12.2021

S1E20: Red Hat Experts Answer Your Ansible Questions

This is a podcast episode titled, S1E20: Red Hat Experts Answer Your Ansible Questions. The summary for this episode is: <p>Listen in on one of our Tech Talk Thursday panels as Ansible Experts answer questions submitted from our Tech Talk Thursday audience.</p>

Listen in on one of our Tech Talk Thursday panels as Ansible Experts answer questions submitted from our Tech Talk Thursday audience.

Guest Thumbnail
Jim Garrett
Chief Architect at Red Hat
Jim is a Chief Architect at Red Hat, the world's leading provider of open source software solutions. He is part of the North American channel solutions architecture group, responsible for helping customers solve the most difficult and challenging problems they face.
Guest Thumbnail
Estelle Lissouck
Senior Consultant and Linux System Engineer at Moser Consulting
Estelle Lissouck is a senior consultant and Linux system engineer at Mosher consulting, focusing on the Red Hat Ansible automation platform and is a Linux systems engineer, having expertise in Red Hat, CentOS, and Solaris. She has been working as an IT professional for over nine years and she enjoys using her skills to contribute to the exciting technological advances in her community. Estelle also has expertise in virtualization techniques using AWS, VMware and Red Hat tools.
Guest Thumbnail
Louis Gordner
Principal Consultant and Technology Lead at Moser Consulting
Lewis Gordner is a principal consultant and technology lead for Unix and Linux systems at Mosher Consulting. He has 17 years of experience as a solutions architect for open systems focusing on system infrastructure, cloud architecture, server automation, and software deployment and administration, both operationally and dev ops. He's a Red Hat certified engineer and an AWS certified solutions architect. Louis is also a certified specialist in Ansible automation.

Angel Leon: Go. Hello everyone, and welcome to another edition of ASCII Anything, presented by Mosher Consulting. I'm your host, Angel Leon, Moser's HR advisor. In this week's episode, we're sitting in on a live Red Hat Ansible panel that features two of Mosher's experts and a Red Hat partner, answering the most common or most difficult Ansible automation platform questions. Want to know more about setting up Ansible? What are the most common mistakes and pitfalls? How do you optimize? This week's episode will cover those topics along with others. Our panel of experts includes Jim Garrett, Lewis Garner and Estelle Lissouck. Jim is a Chief Architect at Red Hat, the world's leading provider of open source software solutions. He is part of the North American channel solutions architecture group, responsible for helping customers solve the most difficult and challenging problems they face. Lewis Garner is a principal consultant and technology lead for Unix and Linux systems at Moser Consulting. He has 17 years of experience as a solutions architect for open systems focusing on system infrastructure, cloud architecture, server automation, and software deployment and administration, both operationally and dev ops. He's a Red Hat certified engineer and an AWS certified solutions architect. Lewis is also a certified specialist in Ansible automation. Estelle Lissouck is a senior consultant and Linux system engineer at Moser Consulting, focusing on the Red Hat Ansible automation platform and is a Linux systems engineer, having expertise in Red Hat, CentOS, and Solaris. She has been working as an IT professional for over nine years and she enjoys using her skills to contribute to the exciting technological advances in her community. Estelle also has expertise in virtualization techniques using AWS, VMware and Red Hat tools. Without further ado here is the live Red Hat Ansible panel.

Malinda: Hi everybody, and welcome to this webinar from Moser Consulting and Red Hat. We're going to talk today with our Ansible experts. We've asked ahead of time for questions to be submitted, and we got several questions. So we're going to be going over those. If you want to ask a specific question or something that comes up, have a need for further information, type that into the chatbox and we will definitely get that going. I'm going to do throw up a poll that you can participate in if you want. There's a couple of questions on there about IT automation and where you're at in that journey, because IT automation is a journey. It's something that it's best to plan and make a plan for long term. With that, I'm going to turn it over for a moment to Matt Ren. He's going to talk a little bit about what we do and introduce our panelists. So Matt.

Matt: Thanks, Melinda. And thanks for everybody for joining today. So as Melinda said, my name's Matt Ren. I am responsible for leading our sales charge here at Mosher. I've been with Mosher for six and a half years, and I'm very lucky to be able to introduce our panelists today. We'll start with Estelle. Estelle is a senior consultant here at Mosher, focusing on a Red Hat automation platform and as a Linux systems engineer as well, having expertise in Red Hat, CentOS and Solaris. She enjoys using her skills to contribute to the exciting technological advances in her community. Next is Lewis. Lewis is our tech lead for our open systems, infrastructure and automation, as well as an Ansible architect for us. He's been with Mosher for a little over seven years. And if we ever get back to traveling and conference life, he enjoys a good bourbon. So if you see him, make sure you get him one. And then finally introduce Jim Garret. Jim is a Chief Architect for Red Hat. He's been there for almost five years. I'm very lucky to call him a personal friend of mine. And Jim also does enjoy a good bourbon when he travels, too. Mosher, we have been in business for 25 years. We work in the federal, state and local, and commercial markets. We have seven different practices here at Mosher. You can check those out at moserit.com if you want more information on that. Within our Red Hat partnership, we were fortunately enough name the SI partner of the year for small, medium-sized organization, as well as an Apex partner, which means we're able to do subscriptions, sell you subscriptions as well as perform architecture implementations and support of Red Hat products. A friendly reminder to everybody that Red Hat summit was the last two days, so please go back and check out any of the sessions. They all are on demand. And I will hand it back over to Melinda to be able to ask the experts and go from there. So thanks everybody.

Malinda: Okay. So we're going to start with a few of our questions that we got online. I'm going to hope this panel advances. I did click on it. So I'm going to give it a second. There we go. Thank you, Lewis. I saw it. I heard you do that. So one of the questions that we got, I would like to learn more about Ansible automation benefits. I would like to say we do have a podcast episode that talks about all of the benefits of IT automation. So if you go to our podcast, asciianything@listen.moserit.com, we go into very much more in-depth on that. But to start off, I wanted to ask Estelle to just talk a little bit about this.

Estelle: Yes, thank you Melinda and hi everyone. So IT automation implies making a routine task automatically repeatable. And the importance of automation is clear and it's very clear. In the past, this was very less a concern because the pace of IT itself was slower and IT is expected now to respond instantly to business needs. That's why they're moving towards IT automation. And now we can no longer afford to take three weeks to fire up a VM, for example, in a private cloud. So this types of delays are just not acceptable. They act as a brake on the business itself. So some of the importance or benefits of automation is greater speed and efficiency in your infrastructure. So developers or development gets faster when time consuming tasks like configuration are taken away from developers and implemented automatically. So this also results in consistent environments and more redefined configuration. So IT personnel are now happy because they are removed from the menial task and now free to focus on more important and higher value work, which will lead to higher level of productivity. IT automation will also save you money and resources and in the sense that it eliminates the needs of large things. It performs a lot of manual steps. A large team to perform a lot of manual steps to get started with production development. So it can help save on staffing costs. So labor spending is also reduced and workers spending time and resources working are more important value added tax. So the results can be significant cost saving. One more thing is about enhanced security. Automation will help your business enhance your security. And so by removing time-consuming and effort field tasks like monitoring from the developers' responsibilities and now through automation, developers and even cybersecurity professionals can focus proactively on preventing vulnerabilities and even troubleshooting issues. Without automation, security teams have to deal with an increased number of security alerts and potential incidents, which could require even many hours of that vulnerable time to resolve issues. And because there are so many false positives like miss level alerts that come in. That time ends up being inaudible in vain, but with security automation, these repetitive processes don't require human intervention. So it can free up a lot of time to deal with real cybersecurity threats. In other words, automation allows security teams to deal with potential alert in a faster, a more effective manner. And when you automate your IT processes, you also reduce the chances of human error. You can take steps to reduce human error and ensure a more accurate information as well as smoothly completed tasks and processes. And an error-free business is very more efficient and better at serving the customers. So with less chances of human error, a business can focus more on what they do best and not resolving issues that need fixing. So using automation, it's very important in inaudible company. Thank you.

Malinda: All right. Thank you. I'm going to try to switch to the next one. Ah, there we go. Question two that was submitted. I'm new to system administration. Curious about Ansible. Was wondering if anyone has any experience using Ansible to assist in administering a Horizon desktop environment. And if so, how does it help with automating their horizon environment?

Louis: So for those who aren't familiar, Horizon desktop environment is a VMware product. It's part of the normal VM stack, but it provides a VDI based environment. We're actually using that at our current client. And at the end of the day, the management on that's not too different than the management of most either Windows instances or VMware instances, depending on the layer of the stack you're dealing with. From provisioning all the way through customization, GPO, domain membership, and all the parts and pieces of software install, all the parts and pieces that you normally deal with the desktop and or with a Windows system and or with a VMware environment. Ansible handles those all pretty easily and out of the box. We've got modules for all of the above. And because PowerShell is a first class citizen, it makes taking anything you've already got written in PowerShell and migrating it into Ansible amazingly simple. If me as a infrastructure guy from start to finish whose last programming was C++ can do it, then it's doable. So I think that answered the question, Melinda.

Malinda: Jim, did you have anything to throw in there? I'm going to pick on you.

Jim: I think Lewis did a great job of answering directly as far as what Ansible can do with the Horizon environment. One thing I'd like to add too is with VMware, we have probably, I think 60 or 70 different modules inside of Ansible that provide ways to automate the VMware tasks that people do every day. So that's really the only thing to add.

Malinda: Okay, awesome. I'm trying to... There we go. How do you upgrade Ansible from previous versions?

Louis: So there are really three aspects to this. One, are you doing just Ansible core? Two, are you doing Ansible tower as well as Ansible core? And three, where's your code at? So the tower/ Ansible core stuff is actually pretty easy. It's all done via RPM package management or the tower installer, which comes either standalone or bundled with all the pieces you need. So for your DOD, or disconnected environments or anything it's sitting in a DMZ or something, you can use the bundled installer, but all of that is maybe 20 minutes of watching an Ansible playbook run. It's just staggeringly simple. Really the bigger kicker is that Ansible versions are supportive for 18 months and then code gets deprecated out. So when you're writing your code and running your code, you always got to look for those purple deprecation warnings because they will be changing things out from underneath you as it were, but they give you 18 months of warning. So as long as you're paying attention to your code as it's being executed, it's not that hard to stay current, but if you don't stay current on your code, then you can get yourself bit, a little bit. The other thing that tower does is it provides virtual environments. So you can create a virtual environment with the not yet released or the preview version of Ansible tower or excuse me, not Ansible tower, Ansible core. And then you can run against that and see how your code does before you ever go for your upgrade. So it gives you a test ground for you to work with on your code. But the biggest thing is to watch your code and watch your deprecation warnings. Jim, do you have anything further?

Jim: No. Lewis, you answered it perfectly. Good job.

Louis: Thank you, Jim.

Malinda: Okay. Again, trying to get this to too. Okay. Is Red Hat a good technology for engineering students to consider? And I was going to tap Estelle for this. I know Estelle has a lot of experience teaching and helping students. So there you go.

Estelle: Yes. The short answer for this question is yes, Red Hat is suitable for engineering students. So being an student or having that background sets you at an advantage because you already have that analytical, critical thinking and even problem solving skills. So it really sets at that advantage for Red Hat technology. And I'll say Red Hat has an array of certification oriented towards job roles from system administration, to system engineering and architecture, to development, and even application administrations and all sorts of cloud and virtualization administration. So it depends on what your goals and visions are. The Red Hat certified system administrator for example, is a Red Hat basic certification, which guarantees that an administrator knows how to configure a logical storage, work with the system security control, inaudible security, enhanced Linux, firewalls and access controls and manage its file system and user beads. And then further, we have the Red Hat certified system engineer that adds to these with skills in web server administration, remote storage, connection, configuring DNS server, NFS server, FTP, and SMTP services, and many others. Further, you can also go to be an expertise dealing with directory service, virtualization, clustering, and remote storage, giving security handling inaudible and other advanced technology. So of course having that engineering background will really set you at an advantage. And I will say, if you think you want to go in for any Red Hat inaudible, what I'll tell you is that you can do more than what you think you can do. Just your mind to it. It's nothing too complicated as an engineering student or with that engineering background. I strongly believe you will succeed and do good.

Louis: I wanted to append to that, also. The one skill I look for the most when I'm interviewing potential engineers of any stripe is the ability to troubleshoot or problem solve. The ability to think logically through a problem. And so engineering typically lends itself to that quite well. And Ansible is the same way. It's the ability to troubleshoot, because you never get it right out of the box. You have to iterate. And so the ability to troubleshoot is the thing that I find the hardest to teach and the most important in people I'm looking to hire.

Jim: Yeah. I'd like to add a slightly different slant to what both Lewis and Estelle had still had to say. So knowing that Red Hat is an open source company, what that implies is that individuals from outside of Red Hat, have the ability to download the source code, make changes to it, and possibly upload it back into our upstream source code tree. As an engineering student, what better opportunity to get involved with the community that is making an impact out in our ecosystem? I have a son, he's 22 years old, he's a computer science major at a university here in Cincinnati, otherwise known as University of Cincinnati. And he actually got involved with an open shift operator project last summer. And it was really educational for him. So Red Hat has not only great products that engineering students can leverage, products like Ansible, where they can learn how to automate all of the different mundane tasks that they do all the time. But we also offer opportunities to contribute and to do things back upstream, to help define what not only future engineering students are going to leverage, but other people out in the ecosystem. So great opportunity to learn and a great opportunity to contribute back into the world.

Louis: And a heck of a resume builder.

Jim: Heck of a resume builder. That's right. If you want to impress somebody, show them that you volunteered, you've contributed your time to upstream projects that are making a difference. That's a big deal.

Malinda: Yeah, absolutely. And I want to iterate, too, what Lewis said about problem solvers. That's what we look for at Mosher. Everyone we hire, we want them to be problem solvers, be able to take something and pick it apart. So, all right. I'm trying to move forward here. So this is one of the more common questions that we get about Ansible, about IT automation. What are the biggest roadblocks to automation that we see at clients?

Louis: So I'm now into my fourth, fifth year, excuse me, of doing Ansible at clients. For those of you who aren't aware of how a lot of these contracts work, I spend between 5 and 15 to 20 weeks at a client generally, and then move on. So I've seen quite a few clients in this four and a half, five years. The two biggest things that I see are one it's cultural. And there's no better way to say it is that if you have the mentality of everything's a special snowflake, then you fight to not automate. But as we know, that's a negative to progress. It doesn't help us with consistency. It doesn't help us with compliance. It doesn't help us with any of the things that are normal goals in IT would be. The other part is you try to take the whole mountain in one step. You got to start and just keep building. So the biggest thing is to start getting quick wins on your automation. Figure out a straightforward process that you do a ton and that you realized saves you five minutes a week. But if it saves you five minutes a week and it takes you 20 minutes to automate, now you've saved yourself five minutes a week every week and it only took you 20 minutes. You start with smaller bites and it works pretty darn well. Jim, Estelle?

Jim: Yeah, I think one of the biggest roadblocks that we have is that people are busy. They don't feel like they can slow down enough to actually pick up a new technology and run with it. However, that also becomes one of the biggest reasons to adopt an automation technology. One of my colleagues at Red Hat actually made a comment to me one time. And this guy, he was super educated. He's got, I think, five different certifications at Red Hat, from certified system administrator, certified engineer, certified security. I mean, this guy has it all. And once he started using Ansible, he started automating all of those tasks that he did just routinely or mundanely every day. And ironically, before he knew it, he started to forget some of the command line commands that he used to use simply because he was running automated scripts to do everything for him. So these automated scripts definitely help, but you have to sometimes slow down a little bit in order so that you can speed up at a later point.

Estelle: So one thing I can add is change. A lot of people are just not accustomed to change. And sometimes bringing automations to an infrastructure means bringing change and people are not just always open to change because it will require you moving from what you're used to doing manually having to do it with automation, even though it's easier, just a button in whatever you're doing is done. Some people are just very stereotype and they don't want to embrace change. So the ability to embrace change can be one work block also.

Malinda: So do you guys feel like top it down helps the implementation of automation or is it more bottom up? Is it the tech people who say, we need to automate this and then it goes up through management. Have you seen it work both ways?

Louis: So it actually needs to work both ways. The running joke I've always heard in IT is that the higher up the food chain you have to sell a product, the worse it is. So if you get the CTO happy about the product and the tech guys don't like it, probably not a great product. That said you have to sell it at that level. You can't convince the ups that it's good by saying, I really like it. It's cool. Look at this happy bell. You got to go, hey, there's a 400% ROI over nine months. We're going to reduce our costs and we're going to increase our compliance. We're going to reduce our risks and start talking that speak that makes sense. And so I find it better to come from both angles. It's really easy for adoption. The tech people like it. And it has a really quick return on investment for what is a comparatively low initial outlay. So yeah. You got to come at it from both angles.

Jim: Yeah. I couldn't agree with Lewis more. It goes both ways. Management needs to see how much they can save, how much return on their investment they can save, but technical people need to push it from the bottom to say to them, we believe if we do this, we're actually going to be able to do more with our time with fewer tools, with fewer minutes in the day. And that's a huge selling point. And one of the questions we often get asked is will this hurt my job? Will it make me obsolete? And the response to that is heck no. The more you become able to automate the different things that you do on a daily basis, which means you can do more during that time span, the more valuable you become. And that's one of the messages to carry home is that value comes in being able to do more and that helps when a company either upsizes or downsizes is if they increase in size again, you're able to do more. If they decrease in size, the person they're going to want to keep is the person that's doing more. So it's a very important aspect to understand.

Malinda: All right. I'm trying to... there we go. Six. So what are next steps once you start with Ansible? So let's say you have Ansible up and running and I've made a couple of playbooks. What now?

Louis: So I think, oh, go ahead, Jim.

Jim: I think the next step, and Lewis you're probably going to probably going to say the exact same thing, but once you start to automate, you're going to see that you have not just one or two playbooks, but you're going to have 10, 20, 30, maybe hundreds of playbooks that do all of the various mundane tasks that you do manually now. The next thing you have to worry about is how do you make those playbooks available to the global audience? In other words, rather than just running a playbook via the command line, how do you take that playbook and make it so that anybody can run it? And of course, that's done through using what we call Ansible tower, but then even beyond that is you need to think about where are you going to store these playbooks, and then how are you going to make them available to Ansible tower? How are you going to version control them? Allow people to modify them and track those changes. Again, those are all things that come into play once you start expanding this footprint and using Ansible to do so many more things. And that's really what the Ansible automation platform as a whole is all about. So the platform has enterprise, I'm sorry, has Ansible tower, and it also has the Ansible engine built into it. And that's where the real power comes into play is being able to expand version control, allow other people to run those scripts without having to necessarily give them administrative access or root access to a system. All that you can do with the Ansible tower.

Louis: Yeah. I'd agree. Tower does provide that nice API interface for user self- service, whether you're using ServiceNow or JIRA or a PHP website or. NET, or insert your user self- service tool here. And because it's a restful API, the integration points are pretty easy. Additionally, as Jim was talking about, Ansible handles are back or role- based access control so that you can get real granular with what you allow people to do and don't do. And what part of the inventory they're allowed to touch, for example. That said the other part of next steps is always all right, so I've gotten server provisioning done and I've gotten server retirement done, and I've gotten user management handled. What would I do next? So for me, it's always, you look at your emails or you look at your ticket system and go, what am I doing the most of? And then start looking at what's taking your time. And so you look at both. What takes your time and what tasks are consistently done incorrectly. Is it adding firewall rules? Is it user management? Is it insert task here, but the idea is if something's consistently going wrong for you, then that's what you should be taking a look at. And automation is phenomenal for driving consistency. So those are the two areas that I always have people look for most on finding what's next.

Estelle: And inaudible to what Lewis just said. One little thing I'd like to add is to identify work that takes less time and the most time, these are the tasks you want to start with to automate, and then prioritize. Make a plan for long- term goal. Look about what infrastructure automation makes sense as an end- to- end solution for long term inaudible and prioritize those tasks.

Malinda: All right. I think that is all of our predetermined questions. I want to thank all of our panels today. Thank you guys for coming in and taking this time. We're going to be sending out a email with a summary of this and some links in it. These links, the link to Red Hat summit. We'll be here for a couple of minutes if anybody wants to type a question into the chat pod, or you can always send us a question on our website. So thank you.

Louis: Yeah. If there are any questions on things that are currently kicking you in the teeth or are just kind of, I'm trying to get it done, and I'm just not sure how. We're happy to help, even if it involves complex data structures in Ansible. We can play that game too. Well, Matt won't be able to help with that, but the rest of us.

Matt: No, definitely won't.

Malinda: I won't help with that either, but the rest of you.

Louis: You have a better shot at it then Matt does.

Malinda: I'm not going to comment on that.

Matt: At least I can get it stood up. So if I can do it, anybody can.

Louis: That's not wrong.

Malinda: All right, I'm going to thank all of our panelists today and all of our attendees and everybody have a great day.

Angel Leon: Thank you for listening into this. Week's edition of ASCII Anything, presented by Mosher Consulting. We hope you enjoy listening in to the live Red Hat Ansible panel. We'd love it if you would join us next week, when we continue to dive deeper with our resident experts in what they're currently working on. In the meantime, please remember to give us a rating and subscribe to our feed, wherever you get your podcasts. Until then, so long everybody.

More Episodes

S1E22: Best of Season 1 - A "Golden Girls" Style 'Clips' Show

S1E21: How To Modernize Collaboration Work Management Tools At An Enterprise Level Regardless Of Industry

S1E19: Discussing Destinations: Where Do Tech People Go to Take Some Time Offline?

S1E18: The Evolution of Data Architecture for Analytics Workloads: A Discussion with Databricks

S1E17: Data & Analytics: People, People, People-Who To Recruit, How To Find Them, And How To Keep Them

S1E16: Interest and Aptitude, Lists, and The Ability To Interrupt- A Women's Guide To Tech Success with Debbie Schilling