1
99:59:59,999 --> 99:59:59,999
Thank you everyone for coming.

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

3
99:59:59,999 --> 99:59:59,999
you might need to watch the video stream.

4
99:59:59,999 --> 99:59:59,999
So, Ansible best practices,

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

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

7
99:59:59,999 --> 99:59:59,999
for the last 2-3 years and

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

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

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

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

12
99:59:59,999 --> 99:59:59,999
The talk will be roughly divided into
4 parts.

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

14
99:59:59,999 --> 99:59:59,999
and why you specifically want to use
Ansible.

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

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

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

18
99:59:59,999 --> 99:59:59,999
that I have found that work really well
for me.

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

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

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

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

23
99:59:59,999 --> 99:59:59,999
like fun things you can do with Ansible.

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

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

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

27
99:59:59,999 --> 99:59:59,999
and just regularly commit,

28
99:59:59,999 --> 99:59:59,999
you will actually be able to say

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

30
99:59:59,999 --> 99:59:59,999
You can actually check why.

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

32
99:59:59,999 --> 99:59:59,999
your self-written bash scripts that do
whatever.

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

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

35
99:59:59,999 --> 99:59:59,999
you will always get the same result.

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

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

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

39
99:59:59,999 --> 99:59:59,999
debugging things when things break.

40
99:59:59,999 --> 99:59:59,999
What makes Ansible good?

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

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

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

44
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+

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

46
99:59:59,999 --> 99:59:59,999
that ???

47
99:59:59,999 --> 99:59:59,999
Ansible also supports configuration
of many things like

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

49
99:59:59,999 --> 99:59:59,999
they don't need SSH but they use the
WinRM

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

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

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

53
99:59:59,999 --> 99:59:59,999
as long as it has a CPU.

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

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

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

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

58
99:59:59,999 --> 99:59:59,999
and then unpause the actual video.

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

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

61
99:59:59,999 --> 99:59:59,999
You have the following rough layout.

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

63
99:59:59,999 --> 99:59:59,999
for example using the "assert" task to
for example check that

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

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

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

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

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

69
99:59:59,999 --> 99:59:59,999
and the variables are actually put into
the template and

70
99:59:59,999 --> 99:59:59,999
make the actual config file.

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

72
99:59:59,999 --> 99:59:59,999
a "validate" parameter,

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

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

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

76
99:59:59,999 --> 99:59:59,999
a check on the syntax of the file.

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

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

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

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

81
99:59:59,999 --> 99:59:59,999
defaults/main.yml

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

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

84
99:59:59,999 --> 99:59:59,999
you want to have running.

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

86
99:59:59,999 --> 99:59:59,999
you notice a few things and that is

87
99:59:59,999 --> 99:59:59,999
your role should ideally run in "check mode".

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

89
99:59:59,999 --> 99:59:59,999
your complete playbook

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

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

92
99:59:59,999 --> 99:59:59,999
and won't actually change anything.

93
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.

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

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

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

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

98
99:59:59,999 --> 99:59:59,999
that Ansible doesn't report any changes

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

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

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

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

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

104
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

105
99:59:59,999 --> 99:59:59,999
when you run it twice in a row.

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

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

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

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

110
99:59:59,999 --> 99:59:59,999
so you want to avoid that as much as
possible.