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!
