Episode 086: How to Get Started with Ansible | CloudSkills.fm

In this episode I catch up with Josh Duffney, author of the new book ‘become Ansible’.

Should you be using Ansible or Terraform? Maybe both? And if so… we all know everyone is super busy, how do you get up and running quickly? Those are the questions that we answer while doing some Q&A with a live audience.

Don’t forget to subscribe to our mailing list at cloudskills.io/subscribe for weekly updates, exclusive training, and advice on how to amplify your career.

Full Transcript:

Mike Pfeiffer:
What’s up everybody. It’s Mike Pfeiffer back again with another live stream here with Josh Duffney this time. I hope you guys are doing good. Josh, what’s up, man?

Josh Duffney:
Not a whole lot. How have you been?

Mike Pfeiffer:
Good, man. Good. So I sent out an email this morning and told everybody we wanted to talk about Ansible today, but I also mentioned that we wanted to talk about the difference between Terraform and Ansible. It’s a common question and they both have different use cases depending on the scenario. Then also, you’ve just written a book, “become Ansible.” So I wanted to get your feedback on the book process and stuff you’ve been working on. So, number one question before we get into the other stuff, what made you write a book about Ansible?

Josh Duffney:
It’s a good question. One, I’ve always really wanted to write a book and I was tired of, I don’t know, letting other people’s projections of the difficulty stop me from doing what I wanted. So that was kind of reason. Number one. And reason number two was I had a lot of knowledge that I wanted to share that really wasn’t documented anywhere. I came to Ansible from a unique approach. I have a Windows background, not a Linux background. So bringing that into a Windows environment was a very unique and interesting implementation that it didn’t really see documented. So that was the aim. But the book really… I tried to make a very, I don’t know, agnostic book. So it has examples for Linux and Windows. It doesn’t pick a side. It even doesn’t pick a cloud provider. I guess it does exclude Google, but there’s AWS examples and Azure examples.

Mike Pfeiffer:
Cool. People are starting to comment and let us know that they’re joining us. So good to see you guys. Seen a lot of people over on YouTube. Hopefully, the LinkedIn live stream is working. So it’s always fun to mess with these controls. See Steve out there on YouTube. Jasper, what’s up? Jasper says, “best arm tats in the cloud bracket.” Thanks, man. Appreciate that. Still working on it.

Josh Duffney:
Agree.

Mike Pfeiffer:
It’s been hard to stay consistent with my appointments with all the COVID stuff, but yeah. Cool. It’s good to have you guys with us. Well, let’s answer the question though, Josh. So people are wondering what’s a big difference between Terraform and Ansible. Should I do one or the other? Are they complimentary? What’s the story with this? So there’s a lot of confusion. I see that question coming up a lot.

Josh Duffney:
It’s interesting. So I, in my last role that I just left about two months ago, it was all Ansible, no Terraform. Now, it’s the reverse. But having written a book on Ansible, I want to find a place to use it. So I have a pretty good perspective on it. Ansible is really great for configuring… Well, they’re different tools. Terraform is for deploying and provisioning and then Ansible’s more configuration. Now, they can be used for the same thing. You can, in Terraform, hook into an Azure stripped extension and run some configuration or DSE, whatever you want. So that way, Terraform is really controlling and kicking off the configuration. Then the reverse distro where Ansible can be used to create virtual machines or pass services, there’s models that, they’re better…

Josh Duffney:
So here’s the distinction that I have is Ansible’s best for configuration and Terraform is best for creation deployment. So they’re, in my mind, they’re best use together is especially if you have an immutable stack where you’re creating virtual machines, IAS, and then you have to configure them. Then a new version comes out of Chocolatey and you need to deploy that out there. That’s where they work really well together. Now, if you’re using a lot of past services, it doesn’t make sense to have Terraform to do that because you don’t have any state to configure after it’s deployed. Yeah, if you’re using past services, that doesn’t add a lot of value, but let’s be real. A vast majority of the internet is run by virtual machines. So there’s still definitely a place for a tool that does the configuration of that.

Josh Duffney:
The other benefit that I see with Ansible that people miss is that it’s a really great orchestration engine for automation that can reduce toil, so that you could delegate out. That’s not something that you would use Terraform for because it’s declarative. You wouldn’t use Terraform to do a database fail-over. So stuff like that, that’s where Ansible, it becomes more useful in those senses. So really, context matters.

Mike Pfeiffer:
Yeah. That’s really good feedback, man, makes a lot of sense. Spin up the cloud infrastructure first, maybe when Terraform because it’s well suited for that and then bootstrap your machines, if you’re still using those, with Ansible. Right? Cool. So a couple of comments came in along the way. It looks like something’s going on weird with the LinkedIn live stream. So I have to fix that. Hopefully, people find us on YouTube. But it looks like the live stream doesn’t seem to be playing. It’s showing the posts. There’s just no video. So apologize for that to anybody over there when you’re listening to this later on. Appreciate the folks in the comments sending everybody over to YouTube. So yeah, that was a really good, I don’t know, good clarity I think, to give somebody a decision point when you’re looking at Ansible, looking at Terraform. So let’s talk about the book. What what do I need to know to crack open that book and to get started? Do I need to have any experience previously or can I just kind of jump in and get going?

Josh Duffney:
No real experience needed. What would be useful as a background in infrastructure or system administration, so you know what the modules are doing, but it’s not even required. I wrote it to be a beginner’s guide and more specifically, a beginner’s guide coupled with implementation. I didn’t want to write an Ansible book that just threw at you everything that Ansible can do. I wanted to show you how to use it. What I do throughout the book is I start by helping you create your own local environment. So you build a container with Ansible and then you deploy out cloud infrastructure to give yourself an environment to task because that’s the big hurdle block in the beginning. It’s like, “Okay. I can write this infrastructure, but I can only run it locally or against my production systems. I don’t feel confident yet to do that.”

Josh Duffney:
So the answer to that is to provide you with your own development environment where you can safely experiment and learn. Then the rest of the book sequentially makes you, “become Ansible,” play on words in syntax there, where it walks you through use an ad hoc commands where you can use item potent commands and then transitioning those into reusable, repeatable playbooks. So it goes from command to repeatable in a playbook and then reusable where you abstract into modules. Then it wraps up the book by showing you how to deploy Ansible in a CD environment with GitHub actions. So it’s really to get you started with Ansible, but then also to show you how to use it in more of a real world context and here’s just all the bells and whistles that Ansible can do, and not having an opinion about how to do them.

Mike Pfeiffer:
So I think I know the answer to this, but when I’m following along in the book, Josh, am I working in the Azure cloud? Am I working in AWS? Google? What’s the story with that?

Josh Duffney:
So in the, I think it’s chapter three, you pick. So you decide if you’re going to provision AWS resources or Azure, and then after the resource are provisioned, the way that you use Ansible interact is the same because I’m using virtual machines underneath to demonstrate how to use Ansible. So whether that virtual machines in AWS or Azure, you still connect or with winRM or SSH.

Mike Pfeiffer:
Yeah. Okay. Interesting stuff. So you’ve been a blogger for a long time. You’ve done some online courses and stuff over the years, and this is your first book. Right?

Josh Duffney:
Right. Yeah.

Mike Pfeiffer:
So what do you think in terms of other people wondering if they’re thinking, “Man, that’d be really cool to write a book someday.” Do you recommend it now that you’ve been through the process or do you think maybe other types of content creation would be good? What are your thoughts on authoring a book?

Josh Duffney:
It’s funny. I think I have the outline of my second book already and I haven’t finished my first one. So I love the process. The long short of that, I didn’t go the traditional publishing route because I wanted to have complete control. I love the process because I got to do everything. I even designed the cover of the book with some Photoshop skills that I acquired in high school. So if it’s crude looking, that’s why. But it was really fun. I got to learn about email marketing. I got to learn about building a landing page. I actually started to use cloud services for my, “business” to launch the book, like to host a free sample that connects to the sign up page so you can get the first chapter for free.

Josh Duffney:
I was all learning that. I got to do that I loved, but I even loved the process of writing the book. I think on Monday, if I remember correctly, I have a script that tells me on Monday, “157 of consecutive days of writing everyday for about an hour or two.” I don’t want to stop. So I started a newsletter to continue me to write. I need some kind of accountability. Otherwise, all the habits would fall. But I recommend it highly. What I would recommend is to do it yourself, go the self publishing route. Start with an outline and then just start writing with markdown or ASCII docs because then it’s just a markup language that you can compile to a PDF, super simple. Yeah, that was the biggest thing that I got hung up on was like the first chapter. I felt like a complete imposter. I was like, “Who am I to write this book? Who’s going to read this?” Even I’ve written maybe almost a hundred blog posts articles by now.

Josh Duffney:
But fight past that and commit yourself to at least completing the first chapter to reevaluate whether or not you want to do it, but take it in. Use it as an experimentation. Just because you start to write the book doesn’t mean you commit to it, but give yourself enough of a deadline that you hold yourself accountable to at least create some part of it to really test out whether you want to do it or not.

Mike Pfeiffer:
Yeah. There’s a couple of comments along the way asking about what the book is. So anybody that joined us late, the book is, “become Ansible.” I think you can just go to becomeansible.com. Right, Josh?

Josh Duffney:
yeah.

Mike Pfeiffer:
To checkout the book, and then there was some cool points there, man. How many days in a row writing an hour?

Josh Duffney:
157.

Mike Pfeiffer:
157, really?

Josh Duffney:
Yeah.

Mike Pfeiffer:
Geeze, man. It’s hard to keep up a streak like that. When I first started writing probably 2009 or '10 and I decided I was going to do a book, I used a website called, “750 words.” That’s how I got started where it was just like-

Josh Duffney:
Cool.

Mike Pfeiffer:
It’s still there. I think it’s still out there and it just trains you to be consistent because you’re right. Once you get over that hump, it becomes more of an automatic muscle and that’s the hardest part with the writing is getting the momentum behind you. Man, 150 days is good or 157 days. That’s legit. So you really got to love writing though, right? That’s part of the process.

Josh Duffney:
What I most enjoy about it is to writing is to think. I forget who that quote’s from, but I learned how little I understood what I thought I understood while writing it.

Mike Pfeiffer:
Yeah.

Josh Duffney:
So in the beginning, each the beginning intro of a chapter took me like two hours because I had to explain what it was that I was going to teach in a useful way and a succinct way. Through that process, I gained a lot better understanding of the things that I assumed that I knew. I knew how to do things in Ansible, but I didn’t know how to tell you how to do them, let alone the value that they add. So it just gave me a far deeper understanding. So even if you don’t publish it publicly, writing is such a great way to further deepen your knowledge in something that you think that you understand.

Mike Pfeiffer:
Yeah. You got to really slow down to be able to explain it and really think it through. It’s good stuff. So there’s a couple of technical points that have come up. I want to circle back to some of these other things that you brought up. But one question that was really good was asking about Packer. If anybody hasn’t worked with that, really it’s just a image builder. Is that something that you covered all in the book, talking about building VM images and automating that process?

Josh Duffney:
No. I left that out. So I just used the baseline images that come from Azure or AWS.

Mike Pfeiffer:
Got it. Okay. But for anybody that’s brand new to that, essentially that’s commonly used in this world when people are automating the process of building VM images. Usually, they’re picking up some kind of flavor of automation for this and Packers a really common used one.

Josh Duffney:
Yeah. So the value there is say you’re using a Windows machine and you need to pre-configure WinRM in some certain way so that Ansible can connect to it and you don’t want to use a shim like a script resource in Azure or the user data in AWS, an image is one way to do that. Or there’s stuff that needs to be installed everywhere and you don’t want to add 20 minutes to the build. Configuration with Ansible, you can embed that in the image. Packers way to automate that image building process.

Mike Pfeiffer:
Yeah. Yeah, it’s amazing tool. Definitely worth checking out for everybody listening. The big cloud services now, Azure, AWS, they have complimentary services that hook in with that and worth checking out. I brought a comment up on the screen from YouTube. Carlton says, “Did writing this book inspire you to write another book in the future that’s more advanced Ansible concepts or is your next book going to be something else?”

Josh Duffney:
I’m not sure yet. I don’t think it will lead to another Ansible book at this point. I think… I don’t know. I’ll probably keep updates with," become Ansible," as time goes on. But yeah, there’s nothing in the works for V2, deeper dive. A good book that’s in that space right now that I can’t compete with is, “Ansible for DevOps,” by Jeff Geerling. I believe that’s how you pronounce his last name. I’ll put that in the read next of my book because it’s such a phenomenal resource.

Mike Pfeiffer:
I remember going through that book a little bit a couple of years ago. It’s been around for a while, but I think he keeps it up to date. Right? [crosstalk 00:13:04] And it’s super comprehensive. Yeah. So that’d be a good next up after you get through this one to show you the foundations. That’s always good. A bunch more comments coming in. One from Brian, let me bring this up on the screen, this is important because everybody’s trying to get so much done these days and it almost seems impossible to keep up with everything. Brian says, “You’ve tweeted about your daily routine.” He wants to know how you unwind from work.

Josh Duffney:
It’s a struggle. I’ll tell you that because a lot of times, you get into a coding problem or it’s just something that I can’t leave your mind. The way that I do it is I just disconnect from technology. I don’t have Slack on my phone. I’ll put it on airplane mode. I’ll hide it in the kitchen drawer. Those are the ways that I do it is I actually have to just get technology out of my life. Otherwise, my line won’t shut down to the point where I can mentally rejuvenate energy. So that’s how I do it.

Mike Pfeiffer:
That stuff will steal your energy, man, if you’re not careful, right? All the social media stuff and the extra emails and everything.

Josh Duffney:
Yeah. Well, you lie to yourself and you think that you could always be productive. But always being productive is going to burn you out. It has to me several times. So yes, it’s dangerous to have the world in front of you on your cell phone because there’s always blog posts to read. There’s always books to read. There’s always feeds to scroll. Sometimes the best thing you can do is just give yourself breathing room.

Mike Pfeiffer:
Yeah.

Josh Duffney:
That’s how I’ve… The only way I’m able to maintain that is not because I’m super disciplined. I’m actually not that disciplined, and I just need to do the action of getting away from me so I don’t have the choice.

Mike Pfeiffer:
It reminds me of getting sucked into some kind of weird addiction almost in a way because I always used to go to Vegas for conferences all the time, but I’m not much of a gambler, but every time I walked through the casinos, you always see those people with the slot machine just pulling on that lever one more time. You know? So I think of when I’m sitting on my phone way too long and I’m just like scrolling, pulling on that lever waiting for something else to pop up. You sit there all night and do that, right? So you got to consciously decide, “I’m not going to touch this thing, going to save my energy,” and that’s how you turn your brain off about work, I guess. Huh? It’s a good technique.

Josh Duffney:
Well, I have another app that I use. It’s called a, “Moment,” on my phone. So I have a threshold of an hour a day on my phone tops. I usually don’t get above 30 to 45 minutes on my phone, but it’ll ping me like, “Oh, you’ve used 15 minutes. You’ve used 20 minutes,” in five or 10 minute increments. So there’s my warning signs. They don’t put those on the slot machines though like, “Hey, you’ve pulled this 500 times.” [crosstalk 00:15:32] Your phone’s the same way, put that on there to give you some kind of a warning of how much you’re consuming it.

Mike Pfeiffer:
Yeah, create some awareness so you actually know how much you’re losing. All right. So Elio has a question here, a good one. “Do you also cover containers in this course? What’s the story with that? Do you show how to run stuff in container or build containers?” What’s going on with that?

Josh Duffney:
It’s an interesting take. So I walked through using containers for Ansible or using Ansible in the container. You’ll learn about Dock containers in the book by building a container that will run Ansible. So you’ll start that container, you’ll run it interactively and at the end of the book, you’ll learn how to use that same container inside your CICD to execute Ansible inside of a pipeline. It’s gets a little confusing because you can use Ansible to orchestrate the building of containers or deployment and manipulation. I don’t cover that in the book. I cover how to use it in the context of the container itself is where Ansible lives and interacting in that way.

Mike Pfeiffer:
Got it. Okay. Then you mentioned CICD. So are you working getup actions, Azure pipelines?

Josh Duffney:
Yeah.

Mike Pfeiffer:
What are you doing in the book?

Josh Duffney:
Yeah. GitHub actions.

Mike Pfeiffer:
Nice.

Josh Duffney:
If you don’t have any background in release engineering and you haven’t used CICD before, GitHub actions are a really great place to start because they’re super simple and it’s not… When I started, I had TeamCity over here and Octopus deploy over here and I was like I just want to run this pester test and then copy this file here. No, I have to learn two systems first. GitHub up actions negate that where it’s really just a gamble document that you have to figure out how to use. Then it’s inside the same tool of your repo, which is nice. So highly recommend looking into those.

Mike Pfeiffer:
Nice. Yeah. One of the things that you triggered there in my head was a thought that a lot of times, people think Ansible’s just for Linux. But you kind of came up with Ansible in a Windows world. Isn’t that right?

Josh Duffney:
Yeah.

Mike Pfeiffer:
So what are your thoughts on that for folks that may be doing Windows and supporting Windows servers for years to come? Maybe they’re just going to be moving beams in the cloud, but still using it there. Do you think that this is something Windows people should have on their radar, Ansible as a provisioning tool to help them bootstrap servers and whatnot?

Josh Duffney:
Absolutely. I think so. I’ve been using this for about three years and I have not yet had to create a custom module for Windows. So that’s because with Ansible, they have Windows support in their existing modules that come with Ansible. If that doesn’t work, then you have doc resources that you can leverage and invoke them independently, but inside of an Ansible playbook. Then lastly, if none of that works, you can still run just PowerShell. So if you can run PowerShell, you can do anything in Windows. So the benefit that you get with Ansible versus using just PowerShell and writing everything yourself is a lot of time saved in an orchestrator, an orchestrator that invokes item potent modules so you don’t have to write. The example that I like to use is like a folder.

Josh Duffney:
So you create a folder with PowerShell, works great the first time. You create the folder again, it fails because it already exists. Then you got to write some try catch logic. Then if you want to retrieve data about that file or folder, you have to write a git command to retrieve it. That’s what happens in a Ansible module. All that item potency is built into it where you don’t have to write all that code, but then you get to still have all the comforts of PowerShell and able to run that with inside Ansible. I think there’s absolutely a hundred percent space for Ansible to be used in one of those environments.

Mike Pfeiffer:
It’s an interesting take. You mentioned DSC. I’ve been wondering, and I probably am out of the loop. I haven’t heard anything. I’m curious if you’ve heard anything about where we’re going with DSC. Are we still doing anything with that? Is Microsoft doing new resource modules or is I still kind of just like what it was a couple of years ago?

Josh Duffney:
I’ve been a little detached, but it is still moving. There’s been a lot of great progress from the community and from Microsoft on the modules. I don’t know what the future is of the LCM and PSE natively, but it is very useful hooked into other configuration management tools. Ansible’s not the only one that can use DSC chef and Puppet can also, I believe Puppet can.

Mike Pfeiffer:
Okay. So let’s take a question. The Great Shabbaz is wondering, "Do you use tower in the book? Do you go over Ansible tower and speak to that at all?

Josh Duffney:
I don’t. So I had a chapter scope for that and outline. I decided that it wouldn’t make the MVP just because I didn’t want to take the next year to write. I had a deadline in my mind of four to five months. So that might be something I add in or as a compliment outside, but it isn’t covered in the book. No.

Mike Pfeiffer:
Very good. All right. Let’s see. I got some other questions for you. This one’s kind of interesting. So do you think Ansible is the number one coding language, which is practiced industry wide for IaaS, infrastructure as a service? What is your feeling on the gauge of Ansible’s popularity from where you’re sitting? I know it depends on your perspective, but what do you think?

Josh Duffney:
In the Windows world, it’s obviously very low. So this is a funny little experiment I did. So I’ve been learning about email marketing in preparation for the book and stuff. So I noticed I have a fairly popular blog post on PowerShell on adding credentials. I think it’s still on page one of Google. I migrated my blocks on my last SEO, but it got about 150 page views a day. So I was like… I got clever. I was like, “Oh, I’m going to embed a little sign up for my book in here and see if there’s any crossover.” I waited probably like a week or two and I had 3000 views on the sign up form. So people had scrolled past it, not a single signup. So what that indicates to me is that from the PowerShell community standpoint and Ansible, I do this and post it on LinkedIn, there’s almost no overlap between the two.

Josh Duffney:
If there’s two Venn diagrams, Ansible’s right in the middle and the circles barely touch each other. I don’t think it’s extremely popular. I think it’s more popular in the Linux space, but I think it’s on the rise. Where’s the chart that I saw? I think it’s in the Terraform up and running book landing page. If you scroll down, there’s a metrics of popularity and the increases over the last three years in that language. Terraform is as close behind, but Ansible was actually beating Terraform as far as adoption increase as a language. So I think it’s really at the beginning of the rise of automation, especially as it gets into the network space and orchestrating and automating network configuration and stuff like that. [crosstalk 00:21:40]

Mike Pfeiffer:
What was the… Cool. What was the biggest weird issue you ran into as you were going through this book, biggest unexpected discovery? Any major revelations throughout the authoring process? [crosstalk 00:21:51]

Josh Duffney:
The only thing in my way was me, was the big revelation revelation that I had.

Mike Pfeiffer:
Say that again?

Josh Duffney:
Yeah.

Mike Pfeiffer:
The only thing that was in the way was me for writing the book or furthering my skillset. That was the biggest, “aha moment,” for me is like, “No, I can actually do this.”

Mike Pfeiffer:
So just overthinking it a little bit?

Josh Duffney:
Yeah. Well, how much do you lie to yourself and let fear dictate the actions you take would be probably the biggest takeaway.

Mike Pfeiffer:
That’s really good. So did you feel like chunking it out and kind of building an outline and then going through your process of just every day doing a little bit, like you said, an hour for now 157 days straight, but do you feel like that is what helped you eventually realize, “Oh, I can take this giant thing and break it down into small chunks,” and you started getting comfortable as you started moving into it? Is that how it went?

Josh Duffney:
Yeah. So how I wrote it was I started with an outline and at first, I obsessed over the outline. It had to be perfect and that prevented me from writing. I realized that that was just my own fear, and it was a tactic that I was using the stall myself from starting to writing. So then what I would do is I was like, “Okay. Well, what’s the first two chapters that are solid?” So I picked those and I started to write. Then I wrote three chapters and I figured out that they need to be reordered.

Josh Duffney:
I basically gave myself flexibility in the order, but I basically scoped to two chapters out, wrote them and then I discovered a good pattern of picking the chapter, outlining the book, picking the chapter, outlining the chapter, and then basically doing the headings for the chapter and then always starting with the introduction and making sure I nailed that before I moved on because so many times, I would just start diving into the book and getting all tactical and stuff. I’m like, “Wait, this doesn’t even make sense here and I don’t know why I’m writing these commands in here. It’s not helpful.” So yeah. Outline the book, outline the chapter, start writing. After the chapter’s done, revisit and repeat the cycle was what I did.

Mike Pfeiffer:
Must’ve felt good to finish our last chapter. Huh?

Josh Duffney:
It did. It was very fleeting though.

Mike Pfeiffer:
Yeah. It’s right, right? It’s like, “All right. Got that done. What’s the next big challenge?” That’s always fun. All right. Let’s bring up a question/comment from Brandon here. He says, “Josh, do you plan to show in the book, some good practices patterns for managing Ansible, get repositories for playbooks, modules and so on?”

Josh Duffney:
So I don’t specifically call out the best practices, although because I want it to be practical, I do show you… There’s a chapter, it’s titled, “Starting at the source.” So a big gap that I noticed when my team adopted is we weren’t just learning Ansible. Several of us on the team didn’t have any prior experience with git, didn’t have any prior experience with release engineering. So there’s two to three tools plus Ansible to learn. So the book, I try to walk through that. There’s no specific like, “This is how you should structure.” It’s more, “Start using source control, start to commit stuff,” and then as you progress through the book, you see how that naturally evolves where it starts as like a read me with some commands and then it goes into a playbook and that playbook gets extracted into roles. Then the roles get used by a site playbook. So as you progress the book, you’ll actually start to see the transition from a scripting repo to a configuration management repo.

Mike Pfeiffer:
Nice. Okay, cool. Another really good question from Destructo says, “Can Josh talk about one of the playbooks he wrote at his job? What was the use case? And not just the book, but what were you doing in the real world with Ansible?”

Josh Duffney:
My favorite success story… So there was this really painful meeting that whoever was on call had to suffer through. Every week, there was about an hour [inaudible 00:25:23] meeting where we had to do some kind of… I won’t go into the specificS, but some kind of testing with the environment and basically click a lot of buttons that people told us to do and change some configs and files to test a process in the environment. That happened every week. it was an hour to two hours of your time if you’re on call. The success story from that is a PowerShell script already existed, so we retrofitted that to go into Ansible. So we just took the commands and we’re like, “Oh, what’s the module for this?” and wrote a new playbook. Then it became really easy where it took the two hour meeting down to 45 minutes, but yet we were still on the call. Basically, to give a little bit more detail the playbook, it would change a bunch of config files against like, I don’t know, a hundred web servers and they would change some database stuff.

Josh Duffney:
It took a long time to do manually. It was a lot of tedious work. Then we would have to reverse that at the end of the process. So then we got that in the playbook, we had to click the thing, could brought it down to like 45 minutes because it wasn’t a lot of RDPing. It was running automation, new automation. But then the most beautiful thing was, is we’re like, “Hey, why don’t we just put this in tower and then put their 80 group that this team that’s asking us to do this in and delegate it to them and then have them run it?” So we did a couple of sessions where we let them run, but we were there to get them comfortable with it. But after two, three weeks of that, we just stopped attending the meetings and they were fine. Then a month later, something changed or we introduced a bug and it failed and then they called us in.

Josh Duffney:
But then that was the norm where we would go months without hearing from them and not have to attend those meetings. So that was like the real, I don’t know, probably my favorite thing that we did was just taking back our own time by delegating tasks or automating them. So there are several other things that we use that were just… like disk space cleanup. I’ve never been in a job where disk space cleanup is not the bane of my existence. So we wrote automation and we just put it on a schedule to clean up all these files constantly. If we started getting alerts for it, we cranked up the frequency of that. That just reclaimed a lot of time.

Mike Pfeiffer:
Nice. That was a good story. Let’s see. Working smarter, right? So let’s see. Puneet had a really good question. You mentioned at the beginning when we were talking about configuration management versus infrastructure as code and stuff like that, but is there anything that you’re targeting in the book against pads services? So platform services, things other than VMs in these cloud platforms?

Josh Duffney:
No. The book really walks through configuring a bot, like a web server, both Linux and Windows is the primary guts of the book-

Mike Pfeiffer:
Got it. Okay. Cool.

Josh Duffney:
… to just demonstrate how to use Ansible. [crosstalk 00:27:57]

Mike Pfeiffer:
That makes total sense. So let’s talk about this real quick just so everybody knows. So Josh is basically… He’s been a cloud skills and trucker for a long time. You helped us deliver content in our AC 400 courses and stuff. We’re actually doing a workshop at the end of this month. Josh is going to be primarily delivering this content; cloudskills.io/ansible, if you guys want to get in. It’s just a one day, pretty much take you through the whole book. If you just want to kind of get on a live call with Josh and myself, kind of go through all the stuff in the book, that’s what this is about. You can catch that towards the end of this month. I think that’s the 26th. Right, Josh?

Josh Duffney:
Yeah. Yeah. Really looking forward to it, a book in a day. [crosstalk 00:28:39]

Mike Pfeiffer:
It’s going to be fun, man. So obviously, it’s going to kind of follow the book, right? Is that the game plan?

Josh Duffney:
Yeah, for the most part. There’ll be some variance and differences. I’ll probably choose Azure to go through the demonstration unless there’s some demand to show some AWS examples- [crosstalk 00:28:58]

Mike Pfeiffer:
Cool.

Josh Duffney:
… questions, but that’d be the difference.

Mike Pfeiffer:
You also had a really good blog series over on the CloudSkills blog, and I know that you publish that in a couple of other platforms as well. So I’ll include that in the notes, the show notes for this so people could go out there and check that out. What are their resources should we point people to? Would becomeansible.com, which is where you could get the book, is that officially out now or is that coming out towards the end of this month?

Josh Duffney:
It’s officially out. It’s not officially launched. So I did a lean publishing model. I did versioning all weird, but since chapter one, it’s been available or part one has been available for purchase for, I think since April. So right now, you get version 0.9. You can buy it. When it gets to 1.0, you’ll get the version for free. But official launch date is September 1st and that’s when I’ll have the 1.0 done and it’ll have a launch and all that good stuff, but it is available for purchase now if you’re eager.

Mike Pfeiffer:
Yeah, need some reading material for the weekend. A couple of followup questions here. Also, everybody as we’re starting to wrap stuff up here in this live stream, we’re not done yet, but feel free to put your final questions and comments and we’ll start queuing them up. The Great Shabbaz, I hope I’m pronouncing that right, has another question. “Ansible galaxy playbooks versus roles; is this something that the book covers or no?”

Josh Duffney:
Yeah. So I walked through the roles. So you develop a role first and then I highlight the need to use it across multiple repositories or Ansible code bases, and that’s where galaxies would come into play. So I walk through definitely… First start with the local role and then what does it look like to put it in its own get repository and then use galaxy to pull it down and use release takes to version your roles.

Mike Pfeiffer:
Cool. That’s going to be awesome. Another question from PowerShell Prompt. I love these usernames. These are great. “Is there a big difference between the ease of use of GitHub actions versus Azure DevOps? Followed the DevOps boot camp and all into Azure DevOps only to see the industry seemingly switched to GitHub.” So I’ll make one comment on that, and I know Josh has some stuff to share. But just in case you haven’t heard, Microsoft bog- No, I’m kidding. I think everybody’s heard that. But yeah, Microsoft’s doing way more stuff. They were doing a lot in Azure pipelines. They’re doing a lot now in GitHub actions. However, there’s tons of customers in Azure’s pipeline.

Mike Pfeiffer:
Just so everybody else knows the situation, Microsoft will still continue to support that. But yeah, GitHub actions is getting way more airplay at this point. So that was kind of where the question came in and also, the AC 400 tests still focuses very much on Azure pipelines, as well as GitHub action. So that’s also interesting. But anyways, Josh, to the point of the question, big difference between the ease of use of GitHub actions versus Azure DevOps? I think you kind of mentioned this earlier, but what are your thoughts?

Josh Duffney:
So feature parity isn’t there yet. So if you need to do some advanced things, I would definitely look at the Azure pipelines. But for personal projects and side stuff, for me especially just running some Ansible or running a container, GitHub actions make a lot of sense where I don’t need to worry about this other tool.

Mike Pfeiffer:
You feel like that- [crosstalk 00:32:07]

Josh Duffney:
It’s really simple actions, if not, pipelines.

Mike Pfeiffer:
Yeah. Do you feel like the learning curve is lower for GitHub actions at this point?

Josh Duffney:
I think so.

Mike Pfeiffer:
Yeah, me too. I think GitHub actions, to your point earlier, is very intuitive to get started with, especially if you’ve already looked at something like Azure pipelines. If you’ve already been doing pipelines, GitHub actions will be much easier, so that would be my footnote to add to that. All right, guys. Any other questions you guys want to add into the chats or under the comments, we’ll take them. So what’re you going to do after this book, Josh? You said you’re writing another book or are you going to kind of see how things go?

Josh Duffney:
I’m tinkering with the idea. I haven’t fully committed. I think I have some really good ideas around there, but yeah. That’s the thing… Actually, I don’t know. The thing that I’m worst at is the transition period between one thing… I’m good at picking something and then focusing on it, but finding what to do next has been the challenge for me. So I’m still very much in that what do I want to commit to next and do next? And I’m not quite sure what I will do.

Mike Pfeiffer:
Yeah, man. Writing a book is insanely hard to do. So congratulations on doing your first book. When you were talking earlier about self publishing, I couldn’t echo that anymore. If you’re going to write a book, man, doing it in Markdown is the smartest way to do it. I just got done contributing a chapter to a book and I had to do the word template thing. That’s so painful. So I think if I was going to start over and do another book, I would do exactly what you did. I would self publish. I would write it all Markdown and do that lean publishing model because things just move too fast anymore.

Mike Pfeiffer:
How are you supposed to keep up the dates and update the content in such a hard way? So I think this is a good pattern if anybody else is thinking about getting into this game. Did you publish this book on Leanpub? Is that what you did?

Josh Duffney:
Gumroad I chose.

Mike Pfeiffer:
Gumroad.

Josh Duffney:
Yeah.

Mike Pfeiffer:
Okay. But fairly similar process, right-

Josh Duffney:
Yeah.

Mike Pfeiffer:
… if you were going to write the book in Markdown? Cool. Very awesome. Brian says he finds Markdown painful. That’s interesting. Yeah. To me, compared to word document, so much easier. [crosstalk 00:34:05].

Josh Duffney:
It depends on your comparison.

Mike Pfeiffer:
Yeah. Word documents man, or word templates are hard. [crosstalk 00:34:11]

Josh Duffney:
One note on the self publishing though, it doesn’t mean that you can’t go to a publisher after it’s done. You actually have a better chance from what I’m hearing from authors that have gotten on the published route is if your book is successful and gets some traction self-published, you’ll actually have an easier time taking it to a publisher if you want to go down that route, if that’s something you want longterm. I don’t know if I’ll pursue that opportunity if it arises with this book that I wrote, but that’s just what I’ve heard and have seen to be true.

Mike Pfeiffer:
Cool.

Josh Duffney:
So it doesn’t mean that you can’t do the publishing model if you do self-publish first.

Mike Pfeiffer:
Definitely a good point there. I’ve actually seen that too, where he gets some traction with the self-published book and then take it to a publisher. They’re going to be more likely to take it off your hands and actually do a publish, but that’s awesome.

Josh Duffney:
Don Jones just released a statement about his, “Be the Master.” That’s going to go into a published forum.

Mike Pfeiffer:
Very cool. Any idea what the publisher is? [crosstalk 00:35:02]

Josh Duffney:
No clue.

Mike Pfeiffer:
Cool.

Josh Duffney:
But it’d be a good book, I’m sure.

Mike Pfeiffer:
One of the questions that just came up was, why Gumroad instead of Leanpub? Any major-

Josh Duffney:
I have find that the Twitter thread. I really liked the UI, the simplicity of it. I wrote in ASCII docs instead of Markdown. I don’t know if it rendered the same in Leanpub. The biggest thing for me is I liked the digital market and I had in my mind that I wanted to do more than just a book. So I wanted to, in the future, maybe do some video courses or maybe an audio copy. Gumroad gave me that ability to price in multiple different versions or packages where Leanpub is really just the book. So that was more future thinking and proofing on my part. Whether I’ll do those things, I don’t know. But that was the main reason.

Mike Pfeiffer:
Yeah. Cool. Sounds good. Then there was a couple other comments about Markdown in there. I think to me, Markdown was easier to understand because I understand web development and so I know what the output format is. So for me, that was something that helped is understanding, “Oh, here’s what I’m actually doing.” So that might be something that helps a little bit, but look for a Markdown cheat sheet out there. There’s so many, and that would be a good way to start. There was another question about… Totally off topic, but what kind of camera am I using? It says, “#askingforafriend.” So yeah, this is a Sony A6500 that I’m using. Last couple of months, I’ve been using a different lens. I’m trying to look it up right now. But basically, I think it’s one of the Sigma of lenses from Sony. This is a Sony A6500 and I’ve actually got a connected to a USB to HDMI converter.

Mike Pfeiffer:
So the camera is literally being used as a webcam on my machine. Then with this lens, it gives me kind of a nice, blurry background behind here. So anyways, that’s the story with that. If you want to email me or something, I can send you the actual links to that stuff if you’re interested. Yeah. So it’s basically, using a nice camera as a webcam. All right, Josh. Thanks so much for being on the show today. Super pumped to read your book and looking forward to the workshop at the end of this month. So just in case anybody missed it earlier, go to cloudskills.io/ansible. Check out the one day workshop, but definitely check out Josh’s book if he can’t join us for that. Also, look at the show notes later. We’ll put the link to Josh’s series, blog series on Ansible. Any place else we want to send people, Josh, after this?

Josh Duffney:
The best place to see what I’m up to is on Twitter, so @JoshDuffney, best place to find me, where I share my thoughts. [crosstalk 00:37:33]

Mike Pfeiffer:
Deep thoughts by Josh. All right, everybody. Thanks so much for being with us today. Really appreciate your questions. We’ll see you guys on the next live stream. Thanks everybody.

Subscribe to the CloudSkills Weekly Newletter

Get exclusive access to special trainings, updates on industry trends, and tips on how to advance your career in the tech industry.