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.