WEBVTT

99:59:59.999 --> 99:59:59.999
Thank you everyone for coming.

99:59:59.999 --> 99:59:59.999
If you were expecting the Postgres talk,
that was the one before, so

99:59:59.999 --> 99:59:59.999
you might need to watch the video stream.

99:59:59.999 --> 99:59:59.999
So, Ansible best practices,

99:59:59.999 --> 99:59:59.999
I thought about calling it "Ansible,
my best practices",

99:59:59.999 --> 99:59:59.999
so, just warning ahead, this is things
I stumbled on using Ansible

99:59:59.999 --> 99:59:59.999
for the last 2-3 years and

99:59:59.999 --> 99:59:59.999
those are very specific things I found
that worked very well for me.

99:59:59.999 --> 99:59:59.999
About me, I do also freelance work,
do a lot of Ansible in there,

99:59:59.999 --> 99:59:59.999
I'm also the Debian maintainer for
Ansible with Harlan Lieberman-Berg

99:59:59.999 --> 99:59:59.999
If there are any bugs in the package,
just report them.

99:59:59.999 --> 99:59:59.999
The talk will be roughly divided into
4 parts.

99:59:59.999 --> 99:59:59.999
The first part will be about why you
actually want to use config management

99:59:59.999 --> 99:59:59.999
and why you specifically want to use
Ansible.

99:59:59.999 --> 99:59:59.999
So, if you're still SSHing into machines
and editing config files,

99:59:59.999 --> 99:59:59.999
you're probably a good candidate
for using Ansible.

99:59:59.999 --> 99:59:59.999
Then, the second part will be about good
role and playbook patterns

99:59:59.999 --> 99:59:59.999
that I have found that work really well
for me.

99:59:59.999 --> 99:59:59.999
The third chapter will be about typical
antipatterns I've stumbled upon,

99:59:59.999 --> 99:59:59.999
either in my work with other people
using Ansible,

99:59:59.999 --> 99:59:59.999
or the IRC support channel, for example.

99:59:59.999 --> 99:59:59.999
The fourth part will be like advanced
tips and tricks you can use

99:59:59.999 --> 99:59:59.999
like fun things you can do with Ansible.

99:59:59.999 --> 99:59:59.999
Quick elevator pitch, what makes config
management good?

99:59:59.999 --> 99:59:59.999
It actually also serves as a documentation
of changes on your servers over time

99:59:59.999 --> 99:59:59.999
so if you just put the whole config
management in a git repo

99:59:59.999 --> 99:59:59.999
and just regularly commit,

99:59:59.999 --> 99:59:59.999
you will actually be able to say

99:59:59.999 --> 99:59:59.999
"Why doesn't this work? It used to work
a year ago"

99:59:59.999 --> 99:59:59.999
You can actually check why.

99:59:59.999 --> 99:59:59.999
Also, most config management tools have
a lot better error reporting than

99:59:59.999 --> 99:59:59.999
your self-written bash scripts that do
whatever.

99:59:59.999 --> 99:59:59.999
And usually, you have a very good
reproducibility with config management

99:59:59.999 --> 99:59:59.999
and also idempotency, meaning that if you
run, for example, a playbook several times

99:59:59.999 --> 99:59:59.999
you will always get the same result.

99:59:59.999 --> 99:59:59.999
Also, it's great if you work in small team
or you admin ??? in the company

99:59:59.999 --> 99:59:59.999
and you have some people working
on a few things too.

99:59:59.999 --> 99:59:59.999
It makes team work a lot easier and
you will save a lot of time actually

99:59:59.999 --> 99:59:59.999
debugging things when things break.

99:59:59.999 --> 99:59:59.999
What makes Ansible good?

99:59:59.999 --> 99:59:59.999
Comparing it to Chef or Puppet for example
it's really easy to set up,

99:59:59.999 --> 99:59:59.999
you start with two config files, you have
it installed and you're ready to go.

99:59:59.999 --> 99:59:59.999
It's also agentless, so whatever machines
you actually want to control,

99:59:59.999 --> 99:59:59.999
the only thing you they really need to have
is an SSH daemon and Python 2.6+

99:59:59.999 --> 99:59:59.999
so that's virtually any Debian machine
you have installed and

99:59:59.999 --> 99:59:59.999
that ???

99:59:59.999 --> 99:59:59.999
Ansible also supports configuration
of many things like

99:59:59.999 --> 99:59:59.999
networking equipment or even Windows
machines,

99:59:59.999 --> 99:59:59.999
they don't need SSH but they use the
WinRM

99:59:59.999 --> 99:59:59.999
but Ansible came a bit late to the game
so Ansible's still not as good

99:59:59.999 --> 99:59:59.999
in coverage like for example Puppet,

99:59:59.999 --> 99:59:59.999
which literally, you can configure any
machine on the planet with that,

99:59:59.999 --> 99:59:59.999
as long as it has a CPU.

99:59:59.999 --> 99:59:59.999
Next step, I will talk about good
role patterns.

99:59:59.999 --> 99:59:59.999
If you've never worked with Ansible
before,

99:59:59.999 --> 99:59:59.999
this is the point when you watch
the video stream,

99:59:59.999 --> 99:59:59.999
that you pause it and start working
a few weeks with it

99:59:59.999 --> 99:59:59.999
and then unpause the actual video.

99:59:59.999 --> 99:59:59.999
A good role should ideally have
the following layout.

99:59:59.999 --> 99:59:59.999
So, in the "roles" directory, you have
the name of the role and task/main.yml

99:59:59.999 --> 99:59:59.999
You have the following rough layout.

99:59:59.999 --> 99:59:59.999
At the beginning of the role, you check
for various conditions,

99:59:59.999 --> 99:59:59.999
for example using the "assert" task to
for example check that

99:59:59.999 --> 99:59:59.999
certain variables are defined, things
are set,

99:59:59.999 --> 99:59:59.999
that it's maybe part of a group, things
like that you actually want to check.

99:59:59.999 --> 99:59:59.999
Then, usually, you install packages, you
can use apt on CentOS machines,

99:59:59.999 --> 99:59:59.999
yum, or you can do a git checkout or
whatever,

99:59:59.999 --> 99:59:59.999
then usually you do some templating of
files where you have certain abstraction

99:59:59.999 --> 99:59:59.999
and the variables are actually put into
the template and

99:59:59.999 --> 99:59:59.999
make the actual config file.

99:59:59.999 --> 99:59:59.999
There's also good to point out that
the template module actually has

99:59:59.999 --> 99:59:59.999
a "validate" parameter,

99:59:59.999 --> 99:59:59.999
that means you can actually use a command
to check your config files for syntax errors

99:59:59.999 --> 99:59:59.999
and if that fails, your playbook will fail
before actually deploying that config file

99:59:59.999 --> 99:59:59.999
so you can for example use Apache with
the right parameters to actually do

99:59:59.999 --> 99:59:59.999
a check on the syntax of the file.

99:59:59.999 --> 99:59:59.999
That way, you never end up with a state
where there's a broken config.

99:59:59.999 --> 99:59:59.999
In the end, you usually…

99:59:59.999 --> 99:59:59.999
When you change things, you trigger
handlers to restart any ???

99:59:59.999 --> 99:59:59.999
If you use variables, I recommend putting
sensible defaults in

99:59:59.999 --> 99:59:59.999
defaults/main.yml

99:59:59.999 --> 99:59:59.999
and then you only have to override
those variables on specific cases.

99:59:59.999 --> 99:59:59.999
Ideally, you should have sensible defaults
you want to have to get whatever things

99:59:59.999 --> 99:59:59.999
you want to have running.

99:59:59.999 --> 99:59:59.999
When you start working with it and do that
a bit more,

99:59:59.999 --> 99:59:59.999
you notice a few things and that is

99:59:59.999 --> 99:59:59.999
your role should ideally run in "check mode".

99:59:59.999 --> 99:59:59.999
"ansible-playbook" has --check that
basically is just a dry run of

99:59:59.999 --> 99:59:59.999
your complete playbook

99:59:59.999 --> 99:59:59.999
and with --diff, it will actually show you
for example file changes,

99:59:59.999 --> 99:59:59.999
or file mode changes, stuff like that

99:59:59.999 --> 99:59:59.999
and won't actually change anything.

99:59:59.999 --> 99:59:59.999
So if you end up editing a lot of stuff,
you can use that as a check.

99:59:59.999 --> 99:59:59.999
I'll later get to some antipatterns that
actually break that thing.

99:59:59.999 --> 99:59:59.999
And, ideally, the way you change files
and configs and states,

99:59:59.999 --> 99:59:59.999
you should make sure that when the actual
changes are deployed,

99:59:59.999 --> 99:59:59.999
and you run it a second time,

99:59:59.999 --> 99:59:59.999
that Ansible doesn't report any changes

99:59:59.999 --> 99:59:59.999
because if you end up writing your roles
fairly sloppy, you end up having

99:59:59.999 --> 99:59:59.999
a lot of changes and then,

99:59:59.999 --> 99:59:59.999
in the end of the report, you have like
20 changes reported and

99:59:59.999 --> 99:59:59.999
you kind of then know those 18,
they're always there

99:59:59.999 --> 99:59:59.999
and you kind of miss the 2 that are
important, that actually broke your system

99:59:59.999 --> 99:59:59.999
If you want to do it really well, you make
sure that it doesn't report any changes

99:59:59.999 --> 99:59:59.999
when you run it twice in a row.

99:59:59.999 --> 99:59:59.999
Also, a thing to consider is you can define
variables in the "defaults" folder

99:59:59.999 --> 99:59:59.999
and also in the "vars" folder,

99:59:59.999 --> 99:59:59.999
but if you look up how variables get
inherited, you'll notice that

99:59:59.999 --> 99:59:59.999
the "vars" folder is really hard to
actually override,

99:59:59.999 --> 99:59:59.999
so you want to avoid that as much as
possible.