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.