Alright, it looks like it's working. Every time I start these streams, since I'm using a little bit of an older Mac, it gobbles up the CPU and the stream doesn't always start right on time. But it looks like things are working now, and I'm seeing that on my other device it is…it is showing me! So that's good. Welcome everybody! A week or so ago—actually it was a few days ago—I was thinking about the fact that a lot of people got my book, and I also started doing some live streaming for Drupal, and I put the two together and I thought “Why not just live stream how to use Ansible, teaching from my book?”. If you don't know about it, this is Ansible for DevOps. You can get a paperback copy of it on Amazon, but right now until the end of March you'll be able to get it for free on Leanpub. I may or may not be able to extend that to another month or something like that, but we'll see. But thank you for joining the live stream! I can see people—you're hearing my voice twice, that's not good…is anybody—okay, works on reload. All right. So that's weird. As I said at the beginning, YouTube is sometimes a little shaky with the setup that I have on my older laptop, so if you have any problems, go ahead and put them in chat and hopefully we'll get them worked out. But thanks for joining the live stream! My intention is to go through examples in the book and kind of start from scratch, assuming you've never used Ansible before and don't even have it installed and go from there. So I figure we can get started in the Preface. And I will grab out my handy little bookmark, which is a Raspberry Pi 0. It's nice and flat makes a good bookmark. I have plenty of them sitting around, I also have a Pi A and all these little projects that I'm working on—here's a Pi 4. It's pretty fun using them for testing with Ansible, because they're by nature pretty headless, if you're using them for projects or in the house like I do, and we might get into that later in this series, but probably not today unfortunately. In the preface of the book I kind of go through how I got started with Ansible. I started using Ansible in…2013, I think it was, and the reason for that was I was transitioning from using a lot of projects that had the single server or maybe two servers, something like that, to having projects that had five, ten, fifteen servers, or managing lots of different projects that had servers that had similar requirements. And once you start making that transition, which a lot of people and a lot of companies made in the early 2000s or mid-2000s, you start realizing it's hard to manage all these servers. So configuration management tools that existed, Chef and Puppy were out, CFEngine, there were some other things too, and a lot of people had shell scripts or run books that they would do, but there wasn't anything really, really easy and simple. It wasn't as simple as writing a shell script and running it on your server, especially if you had to install stuff on your servers. So as we made that transition, Ansible came onto the scene and made things a lot simpler, because instead of having to know kind of some programming languages or some special DSLs, you could basically take a shell script and turn it into a simple Ansible script, or “playbook” as we call them, and you wouldn't even have to use any special Ansible modules or logic or anything. But you could make it so it could run all your servers really easily. In the book I start from the perspective that you probably have done some form of Linux administration before. This book is written from the perspective of me, who came into it as a junior-to-mid-level Linux sysadmin, and you go from that point and we're gonna take you through to automating large-scale infrastructure. And then eventually we're going to talk about Kubernetes, Docker, things like that as well. And in the book there's a lot of different typographic conventions and things, but one important thing is, I have in here—if you have the book, there is a section on the current published book version—it's important that I have that because a lot of books that I've gotten in the past, you buy the book and then it's out of date within a week, or a month, or, you know in the best case scenario, a year or so, because technology keeps evolving so much. And the reason I push people to buy my book on Leanpub is because on Leanpub you can get the book updates free forever, and I've already pushed out 22 major revisions to the book, with hundreds—or I think now of thousands of changes, a lot of them from people who found bugs or issues in the code in the book. And the other cool thing is I have all almost all the examples in the book in continuous integration, so when a new version of Ansible comes out and changes something, I know that that it’s broken right away and I can fix it. So if you have the book from Amazon, a paperback version, you can get a free copy of the Leanpub book right now, just go to Leanpub, search for Ansible for DevOps, and grab it! But it's also important, if you're looking at the book and you see the current book version is like, version 1.18, there's a lot of changes from 1.18 to now! And you can find all the errata on the book's website which is Ansiblefordevops.com, and down at the bottom there's a link to the errata and changes page, which has links to a lot of the fixes that are in the book. If you have the ebook, you can always download the newest copy and you'll have that. If you have the paperback, you might want to grab the ebook as well. In the introduction chapter I talked a little bit about Ansible and Red Hat and the history, and also DevOps—I think it's funny I named my book “Ansible for DevOps” partly because DevOps was beginning to be a very popular thing at that point. And also like I said earlier, put stuff in the in the chat stream and I will check on it throughout this video…and [viewer] asks if you're touching on network devices—I probably won't get specifically into networking in this initial series, but I will try to find ways to point you in the right direction for things that might have to do with networking, Windows, other things that I won't cover directly. But in the introduction I mentioned that DevOps is kind of a loaded word. some people call themselves DevOps engineers, other people say that DevOps isn't a real thing, all this kind of stuff, and in the book I make the point that DevOps to me is more of a philosophy than necessarily a job position or a role. It's the philosophy that your development and operations are really tied together, and that's becoming even more so today when developers might be managing build tools, and and things like—you know, with Docker containers being pushed up into Kubernetes clusters, and with applications using a newer kind of micro services architecture, or even if it's a monolith with split up code base, all the different ways that deployments happen, a lot of times development has to account for the operational capacity of running the things that are developed. So in that sense, I think it's it's a good word and a good movement to get around, to be able to have development and operations be intermixed. There’s still always going to be a need for SREs and sysadmins who are kind of running the servers and making sure applications work, and there's developers who specialize in building the applications, but it's it's more and more integrated these days and I think that's a good thing. And then with Ansible’s history—Ansible started out as a small project that was—the goal of it was initially kind of like an offshoot of a thing called Funk, which would allow you to run commands on multiple servers. And an interesting thing about the word Ansible: if you don't know what that is, and if you google it there's a few different things with Ansible if you Google it, I think there's a festival somewhere in South America, like “Ansible Fest”, which is funny because we have a festival for Ansible called “Ansible Fest”, and so when you search that timeline on Instagram, you see like, some people partying, and then other people partying who are not quite the same kind of partying! But “Ansible” is a device that was in the book Ender's Game; it's a sci-fi book from—I don't remember when it was published, but it's a, you know, relatively modern sci-fi book. And the Ansible is a device that lets you communicate instantaneously with other devices throughout the universe without any delays, not even the speed of light. It's like instant communication. The idea was that you can instantly communicate with all your servers from your local machine or from a CI machine or from Ansible tower or something like that, using Ansible, which is the device that communicates with them all. And Funk—and Ansible itself, if you just use the Ansible command—can run commands on servers using an inventory, which we’ll describe in a couple minutes. But some of the goals of Ansible are that it's clear, fast, complete, efficient, and secure. Those are the things that I put in the book. The idea is that it's easy to learn and pick up quickly, especially if you're used to shell scripting or any kind of basic automation. It's complete in that it has everything included with it—and that's an interesting thing that I'll get into later on. The idea is that it has its “batteries included”, because when you install Ansible you get something like 4,000 or 5,000 different modules that do all these different things with networking, with Windows, with Linux servers, even Mac with homebrew, and things like that. It’s also efficient, because you don't need to install extra stuff and have them running on your servers. Ansible uses SSH, or—we'll get into it—other communication methods to communicate with the servers natively without having to install a daemon that's running on the servers or having an open port on your servers just for the automation tool. It's also secure because of the fact that it uses secure transport protocols, and there's minutia that we could get into later. But a couple more interesting bits of trivia is that up until Ansible 2, major releases were named after Led Zeppelin songs, and in—no, let's see—up until version 2 it was Van Halen, and from version 2 on it’s Led Zeppelin songs. You might not see that day-to-day using it so well, but it's a fun thing to think about. I actually named some releases of another project I work on called Drupal VM after songs from Tron! I exhausted all of the Tron original 1972 songs by Wendy Carlos, but I have now I'm using the songs from Tron Legacy from Daft Punk. So fun things that you can do in your project! Ansible was founded a little bit after the project was started, and then Ansible was actually bought by Red Hat in 2015. And if you follow the news, Red Hat was acquired by IBM in 2018, I think…it might have been last year, I don't know. Time flies, and the past few weeks have been a little bit crazy anyways! Anyway, so at this point Red Hat is in charge of Ansible, and Ansible integrates a lot into the Red Hat ecosystem, which makes sense because Red Hat integrates with like, everything in the world of Linux and cloud computing and all that. And another thing to note in the introduction is that all the examples that we'll be doing in this book and in this video series are linked from the book’s website, so if you go to the code sample section, this is a GitHub repository, it's open source—you can you can download, it you can fork it and do whatever you want with it. Most of the examples are in here, and on the readme it has a mapping of which chapter the example comes from. I'm actually working on moving some more examples from the book into the repository so you can grab them easily. And hello to everybody saying hi! It's good to see you guys, and it looks like we have a good representation from all around the world, which is which is pretty awesome. There's also some other things that if you're getting started with Ansible it's good to know about. One is obviously docs.Ansible.com—not “doc”—“docs” dot Ansible dot com. It has all of the official documentation for pretty much all of the Ansible ecosystem, and there's lots of great documentation here. My book is not meant to be like a documentation guide. It's meant to be a more practical set of examples to get you started quickly, but the documentation has a lot of good—it has videos, it has information about Ansible Tower, which we'll get into much later in the book, and networking. I know someone mentioned networking earlier, there's documentation for it, and also using content off Ansible Galaxy. All these different things are documented here, and this has grown quite a bit since I started, and it's a great resource. There's a great team of people at Red Hat that work on this documentation, they make it one of the best open source documentation sets I've ever used. There's also a mailing list, Ansible Project mailing list. I think it's on GitHub, or—not GitHub, Google Mail—Gmail or whatev—Google Groups, that's what it is. All these resources are in the Ansible Community Guide, which is on Ansible.com. But this this mailing list is good for asking general questions or getting general feedback. There's also an Ansible development mailing list. These are good resources, and they're pretty active too. A lot of communities, you put out an email and you'll never get a response, but here a lot of times you get some good responses, sometimes from other people with the same problems. Someone mentioned “IBM acquired Red Hat in 2019”, yes that is true. Someone's saying “Hello from Aquia”—hi!! That was my—I worked at Aquia in the past, so it's good to see some good former co-workers coming in from there. There's also a lot of other guides. If you Google—if you go to the Ansible Community section, there's a lot of guides for all the different things you can do in Ansible once you start realizing how awesome it is. There's also the Ansible blog, which is “The Inside Playbook”. Blog dot Ansible dot com, maybe? Maybe not. Yeah, well…”Ansible blog”, I’ll go back to the old Google… The Inside Playbook has a lot of good resources a lot of good articles and it can keep you up to date when there's major changes in the Ansible ecosystem. There's a good article on here with Ansible collections, which is a big change. I'll mention it from time to time in the book. For this video series, I'm talking about Ansible 2.9, which is the current version of Ansible. In Ansible 2.10, some things will start changing with the way that content is delivered. Earlier I said something about “batteries included”—the way that Ansible is distributed will change a little bit, so that it's mostly “batteries included” but there are ways that you can make it so that you can kind of get Ansible WITHOUT the batteries included, too. Anyway, so let's move on and get started with using Ansible! The first chapter gets into basically how you're going to do your first work with Ansible, and see kind of how it works, how it interacts with your servers. And the reason I start here is because I think a lot of people that come into Ansible or Chef or Puppet or any kind of automation work, they realize, you know, that they have what we call “snowflake servers”, and a snowflake server is a server that—I’m gonna get back to my page here. A snowflake server is something that you set up by hand, or you have manual processes involved in managing that server, and you can't get that server back to a clean state with [just] a click of a button or running one command. You might have to do a bunch of steps, or you use a runbook to get that server back into a good state. A lot of times, the motivation for automation is [that] you want to get the ability to have servers set up and spin up new servers, or build containers, or build <fix> or images for your servers that are able to be put up very quickly, especially if you need to scale up and scale down if you run web applications, or have jobs that need to be able to spin up new servers quickly. There's a lot of different tools for it; I mentioned earlier there's CFEngine, Puppet, and Chef are three of the big ones that were out in the time that Ansible came into existence. Saltstack is another one that came out around the same time as Ansible and actually has a lot of similarities to Ansible, although there's also plenty of differences there, too, but it’s—I guess Salt and Ansible are sort of two of the more what I would call the the modern yaml-based systems for configuration management. One of the things I liked about Ansible was the fact that I could take my shell scripts and shell commands and things that I already knew how to do and just kind of move them into Ansible and let Ansible run them for me, and I didn't have to learn about Ansible’s modules. I didn't have to learn Python, I didn't have to learn any special syntax, all I had to learn was how to run that command on my servers. And the first thing that you need to do to be able to do that is install Ansible. There's a ton of different ways to install Ansible, but the way that I like and I use on almost every server that I've installed Ansible on, and my local machine, my Mac—my Windows machine is using “pip” which is a Python package library manager, and if you're using—if it's 2020 like it is now, you should probably start using Python 3, because Python 2 has been deprecated. But there's still cases where people use Python 2, and in the Python language there's “pip”, which is the Python 2 version, or “pip3”, which I'm using because I'm using Python 3 now. So I'm going to say pip3 install Ansible, and that's going to install the full set of everything in Ansible. It's gonna install the Ansible command, the Ansible playbook command for running playbooks, which we'll get into a little later. It's gonna install inventory management commands, and documentation commands, all the things that we'll get into throughout this book, and it installs Ansible plus all the packages it relies on. The first time you do this, it might take a few minutes to download and install everything, and if you have problems with it, sometimes that's related to your Python environment on your computer. You might be using a Python version that's built into your computer and it has issues with permissions, and you might be tempted to run “sudo pip install ansible”, and that might or might not make it work, but that's something that I won't get into in this particular video because we could go down a deep rabbit hole with Python environment management. Hello also to—someone's from Argentina, the Netherlands…I was gonna wear my Holland or my Netherlands soccer jersey today, but instead I have this boring blue shirt. But maybe I'll wear that in another future episode here. So Ansible is installed now, and I installed it via pip, and if I run Ansible <fix> version I can check and make sure that it's running. And when I do that it also gives me some information about how Ansible is running, which package it's using, where the executable is, what the Python version is that Ansible sees, and if you're running Ansible—if you're a Python developer, I'm not a Python developer, but if you're a Python developer and you use PI environment or some other tool to manage your Python environments, this stuff can be a lot more helpful to make sure you're running in the right setup and not not running in the wrong place, because in Python you might have like, five installations of Python at a time running. Someone asks about Miniconda, Anaconda, all that—I am—like I said, I'm not a Python developer, and I'm sure a lot of people on this watching this are not Python developers, and if you're not you might not want to dive straight into the world of Python environment management. And I don't particularly—I think what I did was I used a homebrew, so on the Mac it's “brew install Python 3” or something like that. That's how I installed my Python environment, and I'm happy with it, and it works, and I only use a few different things. If you're a Python developer, dive into all that stuff and figure it out. The next step here is I want to start running a command on server, so I actually set up in Amazon, in my Amazon Web Services account, I set up a little EC2 server. I'm on their free tier, because I you know, I'm saving money. I set up a little T2 Micro server, and this is its public IP address. I also made sure it has a security group that has port 22 open, but you can—this could be a server anywhere, it could be a server in DigitalOcean, it could be a server running in your house, it could be a Raspberry Pi. All that I need to do is make sure that the server’s on and has SSH available, and by default it's sent to a server. In Amazon, if you want to log in to that server, you need to make sure you have the key pair downloaded on your computer and added in your key chain. And then I can log into it right now using SSH. CentOS is the default user at that IP address. And now now I'm logged in to it, and you can also see that I'm in Saint Louis, Missouri, using Charter, which—I don't particularly like Charter, but it's working right now, so what can I say. I'm gonna exit out of that server, but I can log into it by SSH, and that's all that Ansible needs to do to be able to log into all your servers. There's other ways to connect to other types of things, network devices and Windows and all that, but you know, this book is targeted at Linux administration. I’m going to be able to connect to that server with Ansible, because I can already connect to it with this SSH. We've gotten Ansible installed. If you're on Windows—if you're on Mac or Linux, pip is the easiest way. If you're on Windows, there's actually a few different ways you can do it. I recommend using the Windows subsystem for Linux. Hopefully the WSL 2 will come out soon. If you're watching this video after the stream is over, it might actually be out by now! But it's easier to manage things that way inside of that Linux subsystem environment, because it's basically Linux inside of Windows, so you can install it the same way using pip. You might have to install the Python 3 pip package using pip, but once it's installed you can run “pip3 install Ansible” and get it. There's also a lot of different ways to install Ansible that I didn't cover that the book actually goes through. You can find those in the book, or look online at ansible.com. It's in the documentation, just search “install Ansible”. The first thing we need to do to get Ansible to know about the server—I know it, because I know the IP address here. We need to create an inventory file. An inventory file just says, “Hey Ansible, here's the servers that I'm working on,” and in this case we just have one server. I'm going to go into my site's directory where I have my projects and make a new folder called “Chapter 1”. I'm gonna go into that folder, Chapter 1, and I'm going to make an inventory file. So I'm gonna say “touch inventory”, then I'm gonna open this folder in my text editor, which is Sublime Text, and the inventory’s file is empty. It uses—by default, inventory files use an INI style syntax. It's not exactly INI syntax, but it's close enough. The way it works is you set up a group, an inventory group of servers. I'm going to call this “example”, because it's an example, and then you list all the servers beneath that group. So in the example group I just have this one server right now, the EC2 server. Daniel says in the chat, “I recommend installing Linux over Windows is the first step ;)”, yeah, that's an option for some people I guess! So here's my inventory file and this is basically [?] Ansible. I have a group of servers called “example”, and in this case there's just one server in that group with this IP address. You can put an IP address, you can put in a host name, whatever it is, however you reach that server when you call it via SSH. I'm gonna save that inventory file, and now Ansible knows about that server. What I can do is I can say “ansible”—oops, I think I hit escape—“ansible”, and then you pass the inventory file to it, so “- i inventory”—that tells Ansible where the inventory file is for your servers. And then I can say “example”, which is the group of servers I'm operating on, and then “-m ping”, and this tells Ansible to use its ping module to ping the servers. And then I'm gonna say use user CentOS, because that's who I logged in as. When Ansible comes back it says it was successful connecting to that server, there were no changes made on the server—this will be important for something I'll mention in a bit—and when it pings the server it got a “pong” back. It also is telling me that it found Python on the server, which is great. One quick note is that I said that Ansible’s agentless, and it doesn't require anything special to be installed on the servers. That's mostly true, but you do need Python, a version of Python, to be installed on the servers, which probably 95 to 98% of servers out there have Python on them already so this isn't gonna be a problem. But if you do have a server out there that doesn't have any Python available on it, you might need to make sure that that those servers have Python available for Ansible to be able to interact with them, because it it sends over a Python module, it runs it, and then it gets the results back. Anyway, we've just used Ansible to communicate with that server instead of using SSH, but Ansible actually uses SSH in the background. You might think also, this is kind of annoying that I had to put in, like, the inventory is here, and I had to put in a username. You can actually put some of these things into the inventory file. I can put Ansible SSH user in here to to tell it what what SSH user to use, and I can also set up an “ansible.cfg” file, which I'll do now to give Ansible some general configuration directives. I’m going to create an Ansible…”ansible.cfg”, and then in here I’m gonna override Ansible’s defaults, and I'm gonna set—I think its “INVENTORY = inventory”. Let's see if that works. So now I don't have to specify that inventory file, and all the directives that you can put into your Ansible configuration are available online if you search for “Ansible configuration”. The Ansible documentation has that. I’m gonna save that and close it, save the inventory file. Another few notes about this: I put in here “-u centos”. You can also specify if you don't have key based authentication—so I'm using the SSH key, or what is it, I forget what Amazon calls it—the key pair! I'm using a key pair, or an SSH key, to connect to the server. If you want to use password-based authentication you can actually do that, and I think the flag for that is “-k”? I have it in the book. You can use “-k”, and you can also “--ask-pass” to provide the password in the command line instead of having it in your prompt and in your history. But it's a lot better to use SSH keys. If you're not familiar with them, there's some links in the book. You can also use a link to Ubuntu’s documentation, because it's the most complete and simple I think, but the idea is that you have a private key on your computer, and you put the public key pair on the server, so that you can connect from your computer to that server securely using key-based authentication, which is a little easier to use and also easier to automate than using passwords, and it's more secure than having passwords being transported all over the place. It's nice that we can see that we can ping the server, but that's not very useful. One thing that I actually do use—these are called ad-hoc commands, and “ad hoc” is Latin for “to this” or “for this” or something like that, I took Latin and I'm already forgetting all of it, back in college and high school. But anyway, these commands basically run something against the server, and so I'm going to run the command “free -h”, which is going to give me the the free memory space descriptions on on the server. You can see it doesn't have any swap space, but it has a gig of memory and has 800 MGs or 750 MGs free, so that has a lot of space available. Sometimes when I'm diagnosing a problem I might run this against a set of servers just to see, is one of them overloaded, is one of them having some processes that are that are locked, that kind of thing. You can also—a lot of times I run a command like “date” against a set of servers, because sometimes you notice one is doing weird things, and probably half the time it's due to either DNS being the problem—as they say on, you know, Guinness, “it can't be DNS, it's never DNS. It was DNS.” Same thing with dates. If the date gets out of sync on your servers, sometimes you can have weird problems with databases and other applications. That's happened in the past for me. Then you have to figure out why that server’s not connecting to NTP, that kind of thing. So you can run commands using Ansible that way, and at this point we're able to basically run any command that we want, and you might notice too that I—in this first command I used “-m ping” and I didn't have any “-a” argument. “-m” tells Ansible what module to use and “-a” gives arguments for the module. If you don't pass any module than Ansible defaults to “-m command”, which is the command module that runs a command on the server. But there’s—Ansible, as I said, it has thousands of modules, and you can use any module that you want on the command line like this using ad-hoc tasks. What is in the example file again? Examples is a variable? Oh, yeah, I'll clarify that here. So in this command, the first thing is Ansible, you're calling Ansible to run run a task on a host, or on a set of hosts. “Example” here refers to the group in your inventory, so that's “example” here. I could also specify this server in particular instead of example, but I'm just saying whatever servers are in the example group run this command on all those servers. This is the argument passed to the command module that's the default if you don't specify a module, and use CentOS to connect. And then Ansible will use whatever settings are in my SSH config and use any keys that are in my SSH keychain locally. So that is that, and we've hit the end of chapter one, and it's good timing too! I was hoping we'd be able to get through Chapter 2 today, and it looks like we will be able to. And [viewer] is saying “You haven't passed the -m module”, and like I said, the main thing is you can pass—I could pass “-m command” here, but the point is that Ansible defaults to the command module if you don't pass a module, so if I do this, this will run the exact same thing as the above command, because it defaults to the command module. Of course it's being a little slower, probably because it's getting later in the stream and my CPU is starting to fall over and die, so let's move on! In chapter 2 I start talking about ways that you can develop infrastructure locally without doing it in the cloud. A lot of times, like if I'm working on an airplane or something, I'll be able to do this stuff, and you can work very fast unless you need to download things over the Internet. You probably shouldn't be on airplanes right now anyway, so I shouldn't talk about that example. But if you're in a local environment, you can do things a lot faster a lot of times than working through the cloud and interacting with servers that are farther from your computer. So I usually use Vagrant to build virtual machines locally. It’s interesting, a lot of people earlier on in the kind of revolution of configuration management, a lot of people still would not have necessarily, like, a development set of servers that they would work on when they're automating them, and then production. They would work on some automation in production, or they would work on a new server automating it, and then they'd kind of like, let it sit there and be very careful with it. So you're still working with snowflake servers in that case. I like to always start by building a local virtual machine or a local Docker container, and then I start automating inside of it. Once I'm done with that, I delete everything and then I start it up again and make sure that everything's the same, and then I keep doing that, and whenever I come back to a project I can quickly come back to it. Vagrant is extremely helpful for that. Vagrant’s a little bit of an older tool, but it's still extremely useful for building local virtual machines and building in the automation workflow to test them and make sure they're working. And then it can also work with cloud machines too. [viewer], sorry if I'm butchering your name there, is also mentioning [that] for networks you use “-k” so that you can use passwords. There are a lot of cases where you can't use SSH, and in those cases, yeah, you do need to use different command line flags to be able to send in a password. You can also use a password file on your system, so that Ansible doesn't need to ask you for a password so it's still automatable. [viewer] mentions, from what I was mentioning with the airplane, “Stay home, WFH, wash your hands”. Yes, make sure that we work to get rid of this crazy coronavirus! For anybody watching this video in the next decade, it probably won't be relevant in a few years, but still, if you really want to live relive the old days, this video was made in the midst of one of the most crazy timelines of my life, with all this coronavirus stuff going on. The first sign of how serious that was getting was when I was noticing what was going on in China, and then I also saw the they canceled ALL of the professional sports in America, things were starting to get serious. And now it's kind of sad, there's a lot of people having their lives affected in very bad ways for various reasons and various things, not just the virus itself, so I pray for them. As I mentioned in an earlier video, I'm a Catholic, so I'm gonna pray for you whether you like it or not. But anyway, hopefully things will get better, and I mean things WILL get better, but hopefully that happens soon and doesn't have too much of a human toll on it. But that's part of the reason I'm doing this video! So let's move along. I also use Vagrant most of the time with VirtualBox. There's actually different ways to use Vagrant, you can use it with Amazon EC2 instances, you can use it with Docker, you can use it with, what is it, there's a lot of different virtualization tools out there. VMware Fusion on your local machine. But I use it with VirtualBox, mostly because VirtualBox is easy to get on Windows, Mac, or Linux. Even if it's not necessarily the most optimal on Linux, versus some other solutions it works really well, and there's tons and tons of what Vagrant calls “base boxes” available. There's base boxes for every known operating system that I've ever seen, and there's lots of different ones that you can download from the community, and you can build your own. We're not going to work on building our own base box right now, but I actually maintain a bunch and use a lot of them in this book for like things like CentOS 7, CentOS 8, CentOS 6, even, I still maintain one for that. Debian 8, 9, and 10, Ubuntu 16, 18, and now 24—whatever system that you want to use in your production servers, chances are there's a base box available for it that you can use without much work. To get started with Vagrant, you can download it from vagrantup.com, or if you use a package manager like Homebrew on Mac you can do “brew install vagrant”. Then you also need VirtualBox, which you can download from virtualbox.org. I already have those downloaded and installed, because they're a little bit bigger and take a little longer to install. I didn't want to spend time just sitting watching them install on this stream. But VirtualBox and Vagrant are both updated pretty regularly, so you want to make sure you always have the latest versions of both, because sometimes like when a new version of Mac OS or a new version of Windows comes out, things can break, and if you're on an older version you're gonna have a painful experience. So once you have those downloaded and installed—I’ll just run “vagrant --version” to make sure it's installed, it's version 2.2.7, which is the latest version—you can start using them to build local virtual machines. I'll go ahead and close that window out. I'm gonna close this, and for the first server that we're gonna do I'm just going to create a quick CentOS 7 VM. I'm going to make that in a new directory, so make that “chapter2” because that's where we are right now, Chapter 2, and what I'm gonna do is I'm going to run the command “vagrant” in it, which creates a new Vagrant environment using what's called a Vagrant file. The Vagrant file tells Vagrant about what kind of environment you want, how you want it to be set up, how you want its networking to be set up, all that kind of stuff, but we're just going to use the defaults for now. So I'm going to say “vagrant init geerlingguy/centos7” and it's going to create a Vagrant file. I'm going to close this chapter window, and I can close that, I don't need it anymore, and I'm gonna open this folder, and you can see the Vagrant file it just created, which is right here. And vagrant files are in Ruby. You don't really have to know Ruby to be able to work with them, but if you want to do a lot of powerful things you might need to know a little bit of Ruby syntax. But at it's very basic level, the Vagrant file tells Vagrant what box to use—in this case, CentOS7, and you can find more boxes by going to this URL, vagrantcloud.com/search, and of course since I closed that browser window it went to my other screen. Like I said, you can find boxes for pretty much any OS that you could ever imagine, so if we wanted to use Ubuntu 20.4 which is not yet release but will be extremely soon, you can find that. Here's my box that I just released a couple days ago. So you can use any kind of box that you want in your local environments. I'm gonna use CentOS 7 just because it's stable and will probably still be working in three four years, since CentOS and Red Hat versions are supported practically forever. And that's all it has in this file. It just says that this is the box to use. So once I have that, I can run the command “vagrant up” and that's going to download the box if you don't have it on your computer already. I think I already have this box on my computer, so it doesn't have to redownload it, and then it's gonna start a VirtualBox machine with that with that VM running. While it's doing that I'm gonna glance at the chat, because I noticed somebody's putting some new things in here. “Default file/directory structure to your Ansible project code” I will get into that, not in this video, but as we get into playbooks I'm gonna start talking about that. But at a very basic level I usually have an inventory file and a main playbook, usually called main.yaml, and then a readme file that has all the information about how to use the project and what it's for, and if you have roles and collections and things like that, those will all be in there too. But I'll get into that as we get further into the book. “IoT-devices”—there are ways to do it, you can use Ansible with any kind of connection. If your computer can connect to another device, no matter what transport it is, chances are there's already a module or plugin for Ansible to be able to connect to it, a connection plug-in. But if there's not, you could write one depending on if it's something that—basically, if your computer can communicate with it, Ansible could be made to communicate with it. However, you might also need to be able to run commands on it in a different way than just using Python, so, you know, we can can talk about that later. You might want to pop that onto a mailing list and see what other people are thinking, because people do use Ansible for Internet of Things quite a bit. “Playbook to see VMs and see what things don't have space”…one thing is that…Ansible is not necessarily tool for monitoring, but if you wanted to check on which devices don't have much space you could use those ad hoc commands. You can put an inventory file out, or—we'll get into this later, again—have a dynamic inventory that pulls all the information out of your your hosting system or like EC2 or vCenter, and then it would look at all those servers and run that command and give you the output. But we'll get into more advanced inventories later. Anything else…”If you can script you can do it with Ansible”, that's basically what I said, yeah. If your computer can do it already, chances are there's already something for Ansible to do that that you just need to install, or it might already be built in to Anssible. You can do inventory via other mechanisms. I’m just showing the INI style method, which is not truly INI, but it's very much like INI. You can also use yaml, and there's other ways to do it too, and there's plugins to interact with EC2 and DigitalOcean and all these different posting providers out there, Azure and Google Cloud. Someone asked “What does sublime do”—or “What does ‘subl .’ do?” On the Mac, “open .” opens the file in the finder wherever you are in the terminal, so I use that a lot if I need to get into here and find out what's in there. And then Sublime has a shortcut, Sublime Text, that's my editor that I use, as a shortcut to open the folder in Sublime. So here's here's this directory. If I say “ls”, you can see there's the Vagrant file. Anything else? Yeah and again, if you want the book, it's free. I forgot to mention that it shows up with what the default price is, and if you want to grab it for free just drag the slider—and you need to have JavaScript enabled, I know this audience probably has a number of people that don't have JavaScript enabled in their browser, you live with the pain just so that you can you can protect the privacy in your CPU a little bit more!—anyway, you have to have JavaScript enabled, and then you can drag the slider over to zero. I think that's all the questions that I saw really quick. I'll also try to go back and make sure that I answer anything I missed, but we have a VM running now, and if I run “vagrant ssh” that's a shortcut that that Vagrant uses to let me SSH into the VM that I just set up. By default it sets up a host-only network, so you can connect to it but other computers outside your computer can't see this VM, and this connects me to SSH. If I want to also see how to connect to it, if I wanted to just use SSH itself, I can say “vagrant ssh config” and that's going to give me some information about how how to connect to that VM from elsewhere. It basically gives you the the different instructions. I could put this in my SSH config file to be able to connect just by SSHing to the server name. Actually, by default it doesn't set up, I guess, a virtual private network on an interface like 192.-something, or I think on my network it's 100.0.10.-whatever, it's a local private network. It doesn't do that by default, so you have to tell it to do that. But anyway, so now I can I can also do things like “vagrant halt” shuts down the VM, “vagrant destroy” deletes the VM, all these different things. The next step that I'm gonna do though is I'm gonna say I want to use Ansible with this Vagrant VM, because I want to start doing some development. I want to develop a playbook that works on a CentOS 7 server, and I'm gonna use Vagrant to run that playbook. Vagrant lets me—without having to configure all this and an Ansible inventory, I can just tell Vagrant “Hey, I have this playbook, I want you to run this playbook on the server”, and it takes care of those details for me. And to do that, I just go in the Vagrant file—I’m gonna clear out all the extra comments that we don't need, just to make this this Vagrant file a little simpler, and all I need to do is put in a little configuration, “config.vm.provision” is a provisioner for Vagrant. You can actually use a lot of different provisioners. You can use a shell script provisioner, Chef, Puppet, Ansible. There's other ones too, but I'm going to use Ansible for this one. “do [ansible]”…and then I'm going to say the Ansible playbook to use is “playbook.yaml”. And now you might be wondering “Where is this playbook.yaml?” Well, we haven't created it yet! So I'll go ahead and do that. I'll do it here, “touch playbook.yaml”, and in the playbook I'm gonna make a really simple Ansible playbook. We’ll get deeper into playbooks later, but for now I'm basically going to tell Ansible what to do. It's the same thing as running Ansible commands, ad hoc commands, individually on the command line, but I'm going to describe them in a format that Ansible can run them one by one in sequence. First I'm going to say the host that I want Ansible to operate on are all the hosts that’s available, and Vagrant will intelligently tell Ansible about all the hosts that are available, which in this case is just this one host that it's connecting to. I'm going to say “become: yes”, and I'll describe why I'm doing this in a minute, and I'm gonna give Ansible a list of tasks. The first one is, these servers might be used for database or something, so I want to make sure the time is synchronized, so I'm going to say “Ensure NTP is installed.”, and I'm gonna say, I’m gonna use Ansible’s yum module, and I'll talk about how this all works in a minute. “name=NTP state=present”, and somebody I'm sure is gonna mention the fact that CentOS 7 uses chronyd by default, we can talk about that later. And I'm also going to make sure that “Ensure NTP is running.”, it's not very useful if it's not actually running and synchronizing time. I'm gonna say “service: name=ntpd state=started enabled=yes”, and I'll get into that in a minute. So I have this playbook, which I'll describe in a second, and Vagrant can actually run this playbook against the server by running “vagrant provision”, and when you do this it's gonna run any provisioners you have defined in the Vagrant file, which, I didn't save this Vagrant file so it's probably not actually gonna run that. Let's see what it does. Yeah, it didn't do it because I haven't actually saved the Vagrant file, so I'll try this again. So Vagrant provision’s gonna pick up the fact that I want to run this Ansible playbook, and then it's gonna grab this Ansible playbook and kind of put all the right things together for Ansible to run it, and of course it's gonna throw out this little compatibility mode warning, don't worry about that if you ever see it using Vagrant. I actually have an issue in, hopefully that will be removed soon. But it's going to run these these two tasks against the server, and this playbook—we’ll get a little bit more into playbooks in probably the next video, because we're running up on time at this point, but the playbook is basically saying, this is a play. Ansible playbooks have a list of plays. This is one play, that starts with this list item, and the play has to tell Ansible what hosts it wants to operate on. In this case it's all ,or we could put 127.0.0.1 because that's the host that it’s operating on, if we just wanted this play to affect one host. I also use “become” because this task, the yum task that's installing NTP, needs to be sudo, or it needs to be the root user. The basic user that that Vagrant uses in its system is called vagrant, and it doesn't have the rights to install packages and make changes that the root user needs to do. So “become” says “Run this playbook as sudo” or becoming the sudo user, whoever that is, and by default it uses sudo. There's actually other ways to elevate your privileges in other systems, so Ansible has plug-ins for that too. Then once it connects and becomes the root user, it runs this task, which uses Ansible’s yum module. The yum module manages packages, and you pass it a name of one or more packages to install, and then you pass it “state=present”. I could also uninstall the package using “state=absent”, and you can also upgrade modules using “statement=latest”, we'll get into that later. And then it runs the second task—let's see…well that's annoying. I thought this worked earlier…service name… That is kind of strange. I wonder if something's different with the version of Ansible I have installed today, because I've been installing and reinstalling Ansible a bunch. But anyway, this task uses the service module Ansible’s service module, which translates behind the scenes—or it's supposed to translate behind the scenes, this looks like someone's going wrong!—that I want the ntpd service started. So I want it to be running right now, and I want to enable it…is it enabled? Yeah, that's the problem, I had a typo in my playbook, and sometimes—this is one complaint that sometimes you'll get with starting out in Ansible, the error messages are not necessarily that good sometimes and you might end up realizing later on that you actually had a typo in your playbook. But anyway, this task uses Ansible’s service module to behind the scenes see if it's running with sysvinit or systemd or whatever service manager there is, and it makes sure that the service is running and makes sure that it's also enabled. Now something I haven't mentioned yet but is going to be very important in our Ansible journey is idempotence. I think that's how you say the word, and it's not really in a lot of dictionaries, but the idea of idempotence, or something being idempotent, is you can run it once or a thousand times and it won't effect a change after that first time that it makes all the changes. So you could see this first time that I ran it up here, it showed that this task resulted in a change, and then in the output below it says there was one thing changed and there's also something that failed unfortunately, and it failed again here, but the second time it didn't report a change, because NTP was already installed. So Ansible checks, “Hey, is it already installed? Yes, okay, I don't need to do anything”, and it reports no changes. So this third one, it actually—since I fixed my typo, it shows that something did change, but it still says that this has not changed. So if I run this again, since I'm using Ansible’s modules that are intelligent enough to know when to make changes and to not make changes, this time it should report no changes and it should say that everything is okay. There's three, three okay tasks, no changes, nothing failed, assuming that nothing fails with with this VM right now—you can look up here and see my CPUs are all kind of working like crazy right now. Whenever you're running a bunch of VMs locally and doing a live stream, it's not very good for an old laptop. But you can see that it says that nothing's changed, and this is very helpful because later on we'll talk about using Ansible for CI and CD. You can actually have play books like this that are run on a CHRON timer, like run it every day or run it every hour or run it every week, and you can verify things. They can can verify that nobody's accidentally changed configurations because Ansible will say “Hey, this changed”. You can flag that in your CI store in Ansible Tower and say “We need to check on the server because something's happened to it that's outside of our automation”, that's something that's very useful to be able to do. Similarly—and this is way later on—Ansible operators can also use this principle in a Kubernetes cluster, running your applications to check on them and make sure that they're healthy in tandem with Kubernetes, and you can do some extra special checks for that too. So idempotence is important, and that's one reason it's good to always use Ansible modules when you can, because that way you're able to rely on the fact that Ansible can track changes on your systems. Somebody also popped in to the live chat the actual definition of idempotence, and I think I actually have that somewhere in the book—I think it's earlier in the preface or something. But you can go back and find where that is if you want. Let's see. So going through the playbook in the book, I mentioned a few other things…there's also another word on idempotence. So you know you could, in Ansible, if you wanted to run a command you can just say “command: yum install -y NTP”. This would be the equivalent of the above, but only for the first time. The problem is if I go up here and I run this playbook again, it's going to run this second task, and it's going to say it changed, because every time you run this, Ansible or whatever other system doesn't know whether or not a change happened here. It probably didn't if NTP was already installed, but it doesn't know that. Yaml’s not intelligent enough to to output something that says “This changed vs. didn't change anything”. So, if you wanted to make this idempotent you can actually use Ansible’s shell module, and in yaml this little bar here means everything after it should be on different lines, and you can actually inline a shell script in Ansible. So I could write, basically check if if this is actually installed yet. “-qa | grep -qw ntp; then” “yum install -y ntp”. I could actually inline the shell script and use the output here to be able to determine if this changed or not, but you know this is kind of obtuse syntax and it's not immediately obvious unless you're like, a shell script guru what this is actually doing, vs. saying “Hey I just, I want to make sure that this package is installed”. So that's one thing with playbooks that's nice about using Ansible’s modules, and I have an example in the book of turning this into an idempotent bash script, but that is actually like eight lines long, and it's not very—it's just really annoying to do it that way all the time. Until I learned about Ansible, I was actually doing this. I had a lot of shell scripts, they were somewhat itempotent because I liked being able to run them multiple times on my servers, but being able to maintain that, it was really hard. Ansible takes that effort and puts it into Python modules that are pretty well tested and maintained, and you can kind of offload all that and abstract it into these statements which in my opinion are a lot easier to use. And if you're somebody who likes having fewer lines of code, you can even take out these comments. I can take out the name comments here, and this is also the exact same equivalent playbook. I could run it the same way and it would work the same. But Ansible itself in the documentation says this many times, and I believe it—it’s best have the documentation in your playbooks and in your code. So Ansible lets you name anything including place, so I can say “name: Ensure NTP is installed.”, and now it's obvious what the intent of this particular task is, because it has a name. The other nice thing is, if you don't have a name, it just says “TASK [yum]”, and you're like “Okay, I don't know what that is”. You could get verbosity and see exactly what's happening, but if I have a name for it and I run it, it says “TASK” and then it has the name of it up here, “[Ensure NTP is installed.]”. So it's better for the output, it's better for the documentation in line with the code, and you can also name plays like this. I could say “name: Setup NDP on all servers.”, and now my play is going to be named as well. So right now we're going to be dealing mostly with playbooks with one play in them, and that's what most play books will be, probably, but sometimes you'll have multiple plays in a play book, and it's good to name them too. Let's see, there's a few more things here… [viewer] asks, “How can I help keep the lights on?” Yeah, I mean definitely if you're buying the book and you can pay for it and all that, that's great, that would be awesome. There's actually other ways to help—and since it's 11 o'clock and since I finished this task, here, the last thing that I'll do here is “vagrant destroy” because I don't want to have this VM running on my computer this whole time. But we have a playbook running. Next week we'll get into a little bit more advanced usage of ad hoc commands, and we'll get into play books a little bit more, get a lot deeper than this really simple example. But to that question about “How can I help, how can I make sure that these streams keep going on even if I end up in some weird situation”, you can actually sponsor me. GitHub sponsors…yes…somewhere here… You can sponsor me on GitHub if you want, that would be really awesome to see. I have some sponsors there, they're very helpful in helping with all my open source work. In addition to this video series and the books, I maintain 200 or so projects on GitHub, and I'd love to keep doing that, and the more sponsors I have, the more time I can devote to that. You can also support me on Patreon. Another thing is, below me there's a subscribe button on YouTube—if you subscribe on YouTube that actually helps a little bit with with my ability to get a little bit of ad revenue. It's like a few pennies per video, but anything counts, you know? And there's also a notification button if you want to get notifications. I hate notifications, I don't recommend it, but you know, if you like notifications, you do you! And you can also hit the like button on this video, I guess! there's my YouTuber spiel, I guess. But you know, I would say at this point I am I'm doing okay, and I hope you are too. The main reason I put out the book for free and I'm doing this video series is because I want to help people that aren't doing so well, and I hope that, you know, if that's if that's you please feel free to take advantage of whatever you can for free at this point. And you know, if someday you can pay it forward, that's great! If not, you know, I hope that you are in a better place in the future! “How can you get the physical book?”, someone asks. If you go to ansiblefordevops.com, you can buy it on Amazon—so there's three places I publish, Amazon, Leanpub, and iTunes, and on Leanpub and iTunes you can get book updates a little easier, but if you want the paperback it's available on Amazon and should be able to ship pretty quickly still. It's saying that you can still deliver by April 24. I know some books take longer to ship, but somehow my book has missed that cut, and you can get it in a couple days in most parts of the world. Any other questions or notes here? Someone's asking about editors and things. I'm using Sublime Text, and it has built-in yaml support. It has a lot of different languages. It also has Jinja, too, which is nice, I will get into that later on in the series, which is the templating language that Ansible uses. But Vscode has has good support for Ansible and yaml and things, and so does Vim, and some other tools, basically any editor does yaml files these days, and that's that's most of what Ansible does. Anything else, let's see…”Thank you”, and yeah! And also alternate days—so [user] asks if—and again, sorry if I butcher your name, I’m one of the worst people at reading people's names probably in the world, so it's no offense to you—but can I do alternate days? I’m gonna plan on doing these on Wednesdays, but i'm gonna make sure that I record all of them. This will be available on the YouTube channel within minutes after I finish the recording, and i'm gonna make sure that they're all up there, and I’m going to put them all together in a blog post so that you can refer back to them. So please feel free to look back at these videos, and hopefully you like it. And again, if you liked the video, you can hit the like button, whatever, but definitely do hit Subscribe if you're interested in this series. I’m gonna get a lot deeper into Ansible as time goes on, thank you very much, and right at the end someone asks “Terraform vs. Ansible?” We will probably get into that as well, but that is not something for a day one intro topic. But thank you everyone for being on this stream, and for watching if you're not watching the live stream, and hopefully you guys are doing well! As i said earlier this is a crazy time in our world, definitely try to reach out to each other and help. Be a friend to people who might not have someone at their at their residence who who's with them and keeping them company, even if they do—you know a lot of us, if we have kids they can kind of drive us insane, so it's nice to be able to talk to somebody who has the ability to have logic and reasoning. So reach out to your friends and co-workers during this time, and please stay safe and wash your hands, avoid getting near other people! Let's conquer this crazy virus as soon as possible. Thanks!