WEBVTT 1 00:00:00.080 --> 00:00:05.240 Welcome curious minds to another deep dive. Today. We're taking 2 00:00:05.240 --> 00:00:07.120 a bit of a shortcut. We want you to be 3 00:00:07.280 --> 00:00:11.640 exceptionally well informed on a topic that's well fundamentally reshaping 4 00:00:11.679 --> 00:00:16.320 how we manage technology. That topic is antible automation. We're 5 00:00:16.320 --> 00:00:19.600 digging into the Red Hat Certified Engineer Antible Automation Steady 6 00:00:19.640 --> 00:00:22.440 Guide by Alex Soda Bueno and Andrew Block. That's a 7 00:00:22.800 --> 00:00:26.679 fresh off the press from O'Reilly. Our mission really just 8 00:00:26.719 --> 00:00:29.960 to pull out those key insights, those aha moments for 9 00:00:30.039 --> 00:00:33.280 you without you having to wade through absolutely everything, whether 10 00:00:33.320 --> 00:00:35.799 you're prepping for something, maybe a project meeting, or just 11 00:00:35.840 --> 00:00:38.320 catching up, or maybe you're just you know, super curious. 12 00:00:38.399 --> 00:00:39.079 Let's unpack it. 13 00:00:39.159 --> 00:00:41.159 Yeah, and it's a great resource for that, this guide. 14 00:00:41.280 --> 00:00:44.280 It gives a really in depth, hands on perspective. The 15 00:00:44.320 --> 00:00:46.880 authors Alex Soda Bueno and Andrew Block, they bring like 16 00:00:46.960 --> 00:00:49.280 a massive amount of real world experience from red Hat 17 00:00:49.320 --> 00:00:53.079 Alex's director of Developer Experience Andrew's distinguished architect. They're involved in 18 00:00:53.119 --> 00:00:56.000 everything from app life cycles to cloud native stuff. So 19 00:00:56.039 --> 00:00:58.520 this isn't just about the mechanics. The how it really 20 00:00:58.520 --> 00:01:01.119 gets into the why answer is so critical. Now. 21 00:01:01.280 --> 00:01:05.079 Okay, so let's start right there. Why should you listening 22 00:01:05.200 --> 00:01:09.159 right now care about antsable? I mean it, infrastructures today, 23 00:01:09.159 --> 00:01:11.439 they're just sprawling, aren't they. You've got cloud, you've got 24 00:01:11.480 --> 00:01:15.760 virtual machines, bare metal servers, networking gear. Trying to manage 25 00:01:15.760 --> 00:01:18.719 all that manually, it just feels well, not just slow, 26 00:01:18.760 --> 00:01:21.159 but like you're constantly fixing mistakes exactly. 27 00:01:21.200 --> 00:01:24.920 That's the core issue. The guide really highlights this managing 28 00:01:24.920 --> 00:01:28.879 complexity and ensuring consistency. Ansable lets you store your entire 29 00:01:28.920 --> 00:01:34.359 infrastructure as code. Think about that, it becomes maintainable, reproducible, 30 00:01:34.799 --> 00:01:37.840 you know, version controlled. Even It's not just about speed, 31 00:01:37.920 --> 00:01:42.120 though speed is nice. It's about control, consistency, preventing those 32 00:01:42.680 --> 00:01:45.319 unintended consequences you get from manual tweaks. 33 00:01:45.560 --> 00:01:47.560 And you know, for a lot of folks listening thinking 34 00:01:47.560 --> 00:01:51.879 about their careers, boosting their skills. The RHC certification, specifically 35 00:01:51.920 --> 00:01:54.239 this ansible exam that e X two ninety four. That's 36 00:01:54.439 --> 00:01:55.680 pretty big deal, isn't it. 37 00:01:55.680 --> 00:01:58.239 It really is? And the guide asks, you know, why 38 00:01:58.280 --> 00:02:01.079 get certified? It's not just enough line on the resume. 39 00:02:01.480 --> 00:02:05.040 This sert proves a deep understanding of antsable It genuinely 40 00:02:05.040 --> 00:02:08.479 distinguishes you in the job market. It can accelerate your career, 41 00:02:08.599 --> 00:02:12.439 push you towards those senior automation or DevOps roles. Plus, 42 00:02:12.639 --> 00:02:15.240 it just makes you better at your job right, equiped 43 00:02:15.240 --> 00:02:18.759 to handle complex stuff. And importantly the ex two ninety 44 00:02:18.759 --> 00:02:21.719 four exam, it's not multiple choice, it's hands on. You 45 00:02:21.800 --> 00:02:24.960 have to perform real tasks using ansible. It proves you 46 00:02:25.000 --> 00:02:25.759 can actually do it. 47 00:02:25.800 --> 00:02:28.919 Okay, practical skills, career boost got it. So let's get 48 00:02:28.960 --> 00:02:31.560 into the nuts and bolts. What makes ansable well answable. 49 00:02:31.599 --> 00:02:34.120 One of the first things people mention is that it's agentless. 50 00:02:34.439 --> 00:02:37.080 What does that actually mean in practice? Why is it significant? 51 00:02:37.159 --> 00:02:41.520 Yeah, the agentless thing is pretty fundamental. It's a key differentiator. 52 00:02:41.680 --> 00:02:44.039 See a lot of configuration tools, they need you to 53 00:02:44.120 --> 00:02:47.360 install a piece of software and agent on every single 54 00:02:47.439 --> 00:02:50.520 machine you want to manage. Ansable doesn't do that. You 55 00:02:50.520 --> 00:02:52.360 set up what's called a control node that could be 56 00:02:52.360 --> 00:02:54.599 your laptop, could be a CICD server, maybe even a 57 00:02:54.639 --> 00:02:57.680 container that's where ansable lives, and from there it pushes 58 00:02:57.719 --> 00:03:00.639 instructions out to the managed nodes you're target, get servers, 59 00:03:00.680 --> 00:03:01.840 network devices, whatever. 60 00:03:01.960 --> 00:03:06.120 Oh okay, So no extra software cluttering up those managed machines. 61 00:03:06.639 --> 00:03:08.800 How does it talk to them? Then? Securely? 62 00:03:08.960 --> 00:03:13.479 Yep, securely usually over ssh for Linux or Unix systems, 63 00:03:13.960 --> 00:03:18.319 or WinRM sometimes open ssh for Windows hosts, so it 64 00:03:18.439 --> 00:03:22.759 uses existing secure pathways and those instructions you mentioned. They're 65 00:03:22.800 --> 00:03:26.120 basically small programs called modules. Ansible copies the module over 66 00:03:26.360 --> 00:03:28.560 runs it, say to install a package using yum or 67 00:03:28.639 --> 00:03:31.879 copy of file with faceyp gets the result and then removes. 68 00:03:31.639 --> 00:03:33.520 The module, so cleans up after. 69 00:03:33.360 --> 00:03:36.479 Itself exactly, very little footprint left behind. Ansible comes with 70 00:03:36.560 --> 00:03:38.400 tons of built in modules, but you can also write 71 00:03:38.400 --> 00:03:40.080 your own, usually in Python or PowerShell. 72 00:03:40.240 --> 00:03:43.360 That's quite elegant. Actually just sends what it needs, runs 73 00:03:43.360 --> 00:03:45.919 it gets out okay. So if someone wants to get 74 00:03:45.919 --> 00:03:49.039 started get their hands dirty, what does the setup look like? 75 00:03:49.159 --> 00:03:50.639 According to the guide. 76 00:03:50.319 --> 00:03:53.199 It walks you through it pretty clearly. For your control node, 77 00:03:53.280 --> 00:03:56.560 you basically need any Unix like machine with a reasonably 78 00:03:56.599 --> 00:03:59.919 recent Python like three point nine or later, or Windows 79 00:04:00.039 --> 00:04:03.599 with WSL works two. Managed nodes are more flexible. They 80 00:04:03.599 --> 00:04:06.000 can often work with older Python versions like two point 81 00:04:06.080 --> 00:04:09.680 seven or three point five and up. Installation itself is straightforward. 82 00:04:09.960 --> 00:04:13.080 Usually your OS package manager like DNF or APP or 83 00:04:13.120 --> 00:04:16.000 PIP on mac os or from source if you really 84 00:04:16.000 --> 00:04:18.399 want to. The book used Ansible two point one five 85 00:04:18.399 --> 00:04:21.040 one two. But you know, any currently supported version should 86 00:04:21.079 --> 00:04:21.399 be fine. 87 00:04:21.480 --> 00:04:23.720 And you need machines to manage, right. You can't just 88 00:04:23.920 --> 00:04:25.720 manage the control node itself. 89 00:04:25.439 --> 00:04:28.639 Right, You need targets. The guide suggests using virtual machines, 90 00:04:28.639 --> 00:04:31.319 which makes sense for learning. They introduce the idea of 91 00:04:31.360 --> 00:04:33.439 the host your physical machine, and the guest the VM 92 00:04:33.519 --> 00:04:35.839 running on it, and to make that easy, they recommend 93 00:04:35.959 --> 00:04:39.639 using something like Oracle VM virtual box as the hypervisor 94 00:04:39.680 --> 00:04:42.959 the software that runs the vms, and then crucially Vagrant. 95 00:04:43.240 --> 00:04:46.720 Vagrant is fantastic for managing these development environments. 96 00:04:46.959 --> 00:04:49.639 Vagrant Yeah, I've used That makes spinning up vms much 97 00:04:49.680 --> 00:04:50.519 easier totally. 98 00:04:50.959 --> 00:04:54.920 You just define your machines maybe a staging server, a 99 00:04:54.959 --> 00:04:57.959 prod server in a text file called a vagrant file. 100 00:04:58.199 --> 00:05:00.879 Then you just type vagrant up and boom, your vms 101 00:05:00.879 --> 00:05:04.399 are running. You can check ips ssh in. It makes 102 00:05:04.480 --> 00:05:06.600 the hands on part really accessible. 103 00:05:06.720 --> 00:05:10.040 Okay, environments set up. We've got antsable on a control node, 104 00:05:10.240 --> 00:05:13.600 some vms managed by Vagrant. What's next? How do we 105 00:05:13.639 --> 00:05:14.879 tell antsable what to manage. 106 00:05:15.000 --> 00:05:17.480 That's where the inventory file comes in. This is like 107 00:05:17.680 --> 00:05:20.319 ansable's address book. It's just a text file usually I 108 00:05:20.600 --> 00:05:23.839 I or yamal format, where you list all your managed hosts. 109 00:05:23.879 --> 00:05:26.079 You can group them too, which is super powerful, like 110 00:05:26.360 --> 00:05:28.959 put all your web servers in a webservers group, databases 111 00:05:28.959 --> 00:05:30.040 and debservers as. 112 00:05:30.160 --> 00:05:32.399 You can target commands at whole groups exactly. 113 00:05:32.480 --> 00:05:35.439 Imagine you have fifty back end servers, define a back 114 00:05:35.560 --> 00:05:38.160 end group and then run one command to install Java 115 00:05:38.240 --> 00:05:41.360 on all of them. That's the power. The default file 116 00:05:41.399 --> 00:05:43.800 is usually a cancible host, but you can point ansable 117 00:05:43.879 --> 00:05:45.439 to any inventory file you want. 118 00:05:45.600 --> 00:05:47.759 Can you put other info in there besides just host 119 00:05:47.879 --> 00:05:48.680 names or ips? 120 00:05:48.959 --> 00:05:51.759 Oh yeah, You can add variables directly in the inventory, 121 00:05:51.879 --> 00:05:55.199 things like the username to connect as antsib, loser, vagrant, 122 00:05:55.600 --> 00:05:59.160 or maybe even the SSH password, though using keys is better. 123 00:05:59.360 --> 00:06:02.360 Right right? Okay, so we have an inventory. What about 124 00:06:02.439 --> 00:06:07.040 running simple quick commands not full automation yet, just like 125 00:06:07.399 --> 00:06:08.639 checking if servers are up. 126 00:06:08.959 --> 00:06:11.920 That's what ad hoc commands are for. You use the 127 00:06:11.959 --> 00:06:15.920 answerable command line tool directly. For example, to check connectivity, 128 00:06:16.000 --> 00:06:20.040 you'd run something like antsable all I inventory rumping. 129 00:06:19.839 --> 00:06:22.279 All, meaning all hosts in the inventory. 130 00:06:21.959 --> 00:06:25.360 YEP, or you could specify a group name like webservers. 131 00:06:25.680 --> 00:06:28.199 The imping tells it to use the ping module, which 132 00:06:28.279 --> 00:06:30.519 just checks if it can connect and run Python on 133 00:06:30.560 --> 00:06:33.560 the remote host. You can do lots with ad hoc commands. 134 00:06:33.720 --> 00:06:35.879 Use the user module to add a user, use the 135 00:06:35.879 --> 00:06:39.839 commander shell module to run arbitrary commands, even reboot servers. 136 00:06:39.879 --> 00:06:42.199 What's the difference between command and shell modules. 137 00:06:41.920 --> 00:06:45.360 A good question. The command module is simpler, safer, maybe, 138 00:06:45.600 --> 00:06:48.920 but it doesn't understand shell things like pipes or redirects. 139 00:06:49.319 --> 00:06:51.839 The shell module runs the command through the nodes default shell, 140 00:06:51.879 --> 00:06:53.959 so it understands all that syntax. 141 00:06:53.639 --> 00:06:56.920 Got it? Before we jump into the big stuff playbooks, 142 00:06:57.319 --> 00:07:00.680 the guide mentioned something called gathering facts. What's that about? 143 00:07:01.079 --> 00:07:03.959 Facts are super important. There are pieces of information about 144 00:07:03.959 --> 00:07:07.839 the remote hosts, things like host name, IP addresses, amount 145 00:07:07.879 --> 00:07:12.279 of memory, disk space, operating system version, kernel version, loads 146 00:07:12.279 --> 00:07:16.040 of stuff. By default, Ansable runs the setup module at 147 00:07:16.079 --> 00:07:18.639 the beginning of every play to gather these facts. It 148 00:07:18.720 --> 00:07:21.680 stores them in variables, typically under ansible facts, and then 149 00:07:21.720 --> 00:07:24.199 you can use these facts in your automation, like. 150 00:07:24.199 --> 00:07:27.240 Only install a certain package if it's a specific OS. 151 00:07:27.040 --> 00:07:30.439 Version exactly that kind of thing, or configure an application 152 00:07:30.519 --> 00:07:33.439 based on the available memory. It makes your automation dynamic 153 00:07:33.439 --> 00:07:34.120 and adaptable. 154 00:07:34.160 --> 00:07:37.800 Okay, that makes sense. Facts provide context, but ad hoc commands, 155 00:07:37.839 --> 00:07:40.959 while useful, seem limited for complex stuff. That must be 156 00:07:41.000 --> 00:07:41.920 where playbooks come in. 157 00:07:42.120 --> 00:07:45.839 Absolutely, playbooks are the core of Answable for anything beyond 158 00:07:45.920 --> 00:07:49.399 simple one liners. They let you orchestrate complex, multi step 159 00:07:49.480 --> 00:07:53.040 processes repeatably. A playbook is basically a list of tasks 160 00:07:53.079 --> 00:07:56.879 written in Yamel that Ansable executes against specified hosts from 161 00:07:56.920 --> 00:08:01.120 your inventory. A single playbook can contain multiple plays. Each 162 00:08:01.199 --> 00:08:03.439 play targets a set of hosts and runs a series 163 00:08:03.439 --> 00:08:06.959 of tasks on them. Fundamentally, playbooks are about defining the 164 00:08:07.000 --> 00:08:08.879 desired state of your systems, and. 165 00:08:08.839 --> 00:08:11.560 This ties back to that concept you mentioned earlier, idempotency, 166 00:08:11.720 --> 00:08:14.639 right ensuring tasks only run if needed precisely. 167 00:08:15.240 --> 00:08:18.480 Most built in ansable modules are idempatent. They check the 168 00:08:18.519 --> 00:08:21.360 current state first. If the system is already in the 169 00:08:21.399 --> 00:08:24.800 desired state, say a package is already installed or a 170 00:08:24.800 --> 00:08:28.199 file has the correct permissions, the module does nothing. 171 00:08:27.920 --> 00:08:30.519 Which saves time and prevents errors from running the same 172 00:08:30.560 --> 00:08:31.360 thing over and over. 173 00:08:31.480 --> 00:08:34.360 Correct It makes playbooks safe to rerun. You're saying, ensure 174 00:08:34.360 --> 00:08:36.960 the state exists, not run these commands regardless. 175 00:08:37.039 --> 00:08:39.159 So what does a simple playbook look like? Can you 176 00:08:39.159 --> 00:08:39.879 give an example? 177 00:08:40.120 --> 00:08:43.440 Sure, it's a yamal file. It might start with three dashes. 178 00:08:44.039 --> 00:08:46.600 Then you define a play You give the play a name, 179 00:08:46.879 --> 00:08:50.399 specify the hosts, a targets like webservers, maybe set become 180 00:08:50.519 --> 00:08:53.360 true if you need root privileges for the tasks. Then 181 00:08:53.399 --> 00:08:56.279 you list the tasks. Each task typically has a name 182 00:08:56.360 --> 00:08:59.360 and calls a module. For instance, a task might use 183 00:08:59.440 --> 00:09:03.399 antsable dot built in dot em with name dot httpd 184 00:09:03.519 --> 00:09:06.960 and state latest to ensure the Apache webserver package is 185 00:09:06.960 --> 00:09:09.759 installed and up to date. Another task could ensure the 186 00:09:09.799 --> 00:09:10.559 services started. 187 00:09:10.720 --> 00:09:14.879 Okay, yammel. List of tasks calling modules seems logical. What 188 00:09:14.960 --> 00:09:18.320 about controlling how the playbook runs across multiple hosts? Does 189 00:09:18.360 --> 00:09:20.120 it just blast it out to all of them at once? 190 00:09:20.480 --> 00:09:24.960 Good question. Ansible has different execution strategies. The default is linear. 191 00:09:25.159 --> 00:09:27.720 With linear, Ansible runs the play on a small batch 192 00:09:27.720 --> 00:09:30.399 of hosts at a time, often five. By default, it 193 00:09:30.440 --> 00:09:32.600 waits for them to finish before moving to the next batch, 194 00:09:32.639 --> 00:09:34.639 but you can change that. There's a free strategy where 195 00:09:34.639 --> 00:09:37.799 ansable doesn't wait, it just runs tasks on hosts as 196 00:09:37.840 --> 00:09:40.279 fast as possible, up to the limit set by forks. 197 00:09:40.519 --> 00:09:44.799 Forks control the maximum number of simultaneous processes ansable will 198 00:09:44.799 --> 00:09:47.879 spawn to connect to hosts. The default is usually five. 199 00:09:48.000 --> 00:09:50.320 You can increase it if your control node can handle it. 200 00:09:50.759 --> 00:09:53.720 You can also control batch sizes explicitly using the serial 201 00:09:53.799 --> 00:09:57.000 keyword in a play. This is crucial for things like 202 00:09:57.200 --> 00:09:59.879 rolling updates where you only want to update say once 203 00:10:00.399 --> 00:10:02.559 or maybe twenty percent of your servers at a time 204 00:10:02.879 --> 00:10:04.559 to avoid downtime. 205 00:10:04.240 --> 00:10:07.320 Rolling updates, Yeah, that's a critical use case. What about 206 00:10:07.360 --> 00:10:10.679 the order within a batch or running a task just once? 207 00:10:10.919 --> 00:10:13.720 You can control the order with the order keyword. Options 208 00:10:13.759 --> 00:10:18.039 like sorted, alphabetical, shuffle or reverse inventory and yes, run 209 00:10:18.120 --> 00:10:21.200 down to stat true tells ansible to execute that specific 210 00:10:21.240 --> 00:10:24.120 task only once, usually on the first host in the batch. 211 00:10:24.559 --> 00:10:27.639 Useful for things like updating essential database schema during a deploy. 212 00:10:28.000 --> 00:10:29.759 You can even make a task run on a different 213 00:10:29.840 --> 00:10:32.080 host than the one it's currently targeting, using delegate to 214 00:10:32.720 --> 00:10:34.840 maybe run a task on a load balancer while deploying 215 00:10:34.840 --> 00:10:35.639 to webnes. 216 00:10:35.320 --> 00:10:37.679 That's all okay, Lots of control there Now a big 217 00:10:37.759 --> 00:10:42.080 challenge in automation is handling differences between environments dev staging PROD. 218 00:10:42.360 --> 00:10:45.960 They need slightly different settings. How does ansible manage that? Variables? 219 00:10:46.080 --> 00:10:48.960 Variables are absolutely key. They let you parameterize your playbooks. 220 00:10:49.320 --> 00:10:52.519 A variable can be a simple string, a number, a list, 221 00:10:52.639 --> 00:10:55.919 a dictionary, standard data types. You reference them in your 222 00:10:55.919 --> 00:10:59.679 playbooks using jingjit to templing syntax which looks like double 223 00:10:59.720 --> 00:11:00.559 kurl braces. 224 00:11:00.759 --> 00:11:02.519 And where do you define these variables? 225 00:11:02.799 --> 00:11:07.799 So many places? That's both powerful and sometimes confusing. You 226 00:11:07.799 --> 00:11:10.799 can define them directly in the playbook using a VARs section. 227 00:11:11.279 --> 00:11:14.039 You can put them in separate files loaded with varse files. 228 00:11:14.639 --> 00:11:18.440 You can have dedicated directories like host VARs for variables 229 00:11:18.440 --> 00:11:21.559 specific to one host, or group VARs for variables shared 230 00:11:21.559 --> 00:11:23.480 by a group. You can pass them on the command 231 00:11:23.559 --> 00:11:26.960 line with extra VARs. There's a well defined variable precedence 232 00:11:27.039 --> 00:11:29.960 order that determines which variable definition wins if the same 233 00:11:30.039 --> 00:11:34.519 variable name is defined in multiple places. Higher precedence overrides lower. 234 00:11:34.679 --> 00:11:37.960 Okay, lots of options, but what about sensitive stuff? Passwords, 235 00:11:38.200 --> 00:11:40.919 API keys. You don't want those sitting in plain text 236 00:11:41.000 --> 00:11:41.879 in your Git repo. 237 00:11:42.240 --> 00:11:46.440 Absolutely not for that Ansable provides Ansible Vault. Vault is 238 00:11:46.480 --> 00:11:49.120 a built in future that lets you encrypt sensitive data 239 00:11:49.159 --> 00:11:52.279 within your gammle files. You use the ansible Vault create 240 00:11:52.320 --> 00:11:55.360 command to make a new encrypted file or ansible Vault 241 00:11:55.480 --> 00:11:58.559 edit to modify one. It prompts you for a password. 242 00:11:59.080 --> 00:12:02.080 Then when you run your playbook, you provide the vault password, 243 00:12:02.559 --> 00:12:06.639 either interactively or through other secure means, and ansable decrypts 244 00:12:06.679 --> 00:12:08.559 the data on the fly just when it needs it. 245 00:12:08.679 --> 00:12:10.200 But you really need to keep that password. 246 00:12:10.200 --> 00:12:13.759 It safe, Oh, absolutely critical. The guide emphasizes this. If 247 00:12:13.759 --> 00:12:16.600 you lose your vault password, your encrypted data is gone. 248 00:12:16.639 --> 00:12:19.600 There's no recovery mechanism, So manage those passwords carefully. 249 00:12:19.679 --> 00:12:23.759 Okay. Volts for secrets good. As playbooks get bigger or 250 00:12:23.799 --> 00:12:26.200 you start doing the same kinds of setups often, how 251 00:12:26.200 --> 00:12:30.279 do you avoid massive repetitive playbook files? Make things reusable. 252 00:12:30.480 --> 00:12:34.759 That's where ansable rolls and more recently collections come into play. 253 00:12:35.360 --> 00:12:39.240 They are all about reusability and structure. A role provides 254 00:12:39.279 --> 00:12:44.399 a standard directory structure for grouping tasks, variables, file templates, handlers. 255 00:12:44.440 --> 00:12:47.200 We'll get to those, and even custom modules related to 256 00:12:47.240 --> 00:12:50.480 a specific well role like setting up a web server 257 00:12:50.600 --> 00:12:53.639 or configuring a database. You create this self contained unit, 258 00:12:53.679 --> 00:12:56.759 maybe a Java role or an Enginx role. Then in 259 00:12:56.799 --> 00:12:58.919 your playbook, instead of listing all the tasks, you just 260 00:12:58.960 --> 00:12:59.600 say rolls. 261 00:13:00.639 --> 00:13:04.279 So bundles all the related logic together needly exactly. 262 00:13:03.919 --> 00:13:06.519 And roles are distributable, you can share them easily. Antsible 263 00:13:06.600 --> 00:13:09.279 Galaxy is the public hub for sharing and finding roles, 264 00:13:09.279 --> 00:13:12.840 developed by the community. The ansible Galaxy command line tool 265 00:13:12.919 --> 00:13:16.320 helps you install and manage roles from Galaxy or other sources. 266 00:13:16.600 --> 00:13:20.600 And collections are like roles plus plus arns that fair. 267 00:13:20.440 --> 00:13:23.720 Kind of yeah. Collections are a newer, more flexible way 268 00:13:23.720 --> 00:13:27.080 to package and distribute ansible content. A collection can bundle 269 00:13:27.159 --> 00:13:32.000 multiple things roles, yes, but also custom modules, plugins, documentation, 270 00:13:32.639 --> 00:13:36.639 even entire playbooks. It's a more comprehensive packaging format. You 271 00:13:36.720 --> 00:13:39.600 often see things like the ansable dot poseis collection, which 272 00:13:39.639 --> 00:13:43.159 bundles modules and roles for managing common poltestic system things 273 00:13:43.200 --> 00:13:47.399 like Cylenix, firewalled mounts, et cetera, or Community dot General, 274 00:13:47.440 --> 00:13:49.919 which has a huge range of modules. They help manage 275 00:13:49.919 --> 00:13:53.320 dependencies and name spaces better, especially as the ansible ecosystem 276 00:13:53.360 --> 00:13:54.200 has grown so much. 277 00:13:54.360 --> 00:13:56.440 Makes sense. So the guide probably shows how to build 278 00:13:56.440 --> 00:13:57.080 your own roles too. 279 00:13:57.240 --> 00:13:59.840 Yep, it shows you how to use Ansible Galaxy role 280 00:14:00.120 --> 00:14:05.720 in it roll name to scaffold the standard directory structure, tasks, VARs, templates, handlers, files, 281 00:14:05.759 --> 00:14:08.919 meta defaults, and it touches on developing custom modules too. 282 00:14:09.000 --> 00:14:13.360 Explaining the key Python variables like ansible metadata, documentation, examples 283 00:14:13.600 --> 00:14:16.600 and return that Ansible uses for self documentation and integration. 284 00:14:16.960 --> 00:14:20.240 Cool let's shift gears a bit within a playbook. Sometimes 285 00:14:20.240 --> 00:14:23.639 you need more sophisticated logic than just running tasks sequentially. 286 00:14:24.000 --> 00:14:26.799 What about things like loops or running tasks only under 287 00:14:26.840 --> 00:14:27.639 certain conditions. 288 00:14:27.720 --> 00:14:32.919 Absolutely, Ansable has robust flow control for repetition. You use loops, 289 00:14:33.360 --> 00:14:35.759 you can iterate over a simple list, say a list 290 00:14:35.799 --> 00:14:39.399 of software packages to install or usernames to create the 291 00:14:39.440 --> 00:14:42.679 loop keyword makes this really clean. You can also have 292 00:14:42.720 --> 00:14:45.559 loops that retry a task if it fails initially. Using 293 00:14:45.639 --> 00:14:49.840 until retries and delay lets you handle temporary glitches like 294 00:14:49.879 --> 00:14:51.919 a network kickup or a service that takes a moment 295 00:14:51.919 --> 00:14:52.440 to start up. 296 00:14:52.600 --> 00:14:55.559 And making tasks conditional like only run this cast on 297 00:14:55.600 --> 00:14:57.080 Fedora systems that's. 298 00:14:56.879 --> 00:15:00.320 Done using conditionals with the when directive you attach when 299 00:15:00.399 --> 00:15:03.480 clause to a task, role, import or even a whole play. 300 00:15:04.120 --> 00:15:06.840 The value is a gingitow expression that must evaluate too 301 00:15:06.879 --> 00:15:09.440 true for the task to run. So you could have 302 00:15:09.639 --> 00:15:12.720 when answible fact distribution a case of a doora to 303 00:15:12.759 --> 00:15:16.960 make a task Fedora specific, or when inventory host name 304 00:15:16.960 --> 00:15:18.799 in groups webservers very flexible. 305 00:15:18.919 --> 00:15:22.440 Okay, loops retries conditions. What about handlers? You mentioned them 306 00:15:22.480 --> 00:15:24.240 when talking about rolls. What are they? 307 00:15:24.399 --> 00:15:27.080 Handlers are like special tasks, but they only run if 308 00:15:27.120 --> 00:15:30.600 notified by another task. You define a handler, say one 309 00:15:30.639 --> 00:15:34.480 that restarts the HTTPD service. Then in a task that 310 00:15:34.519 --> 00:15:38.519 modifies the Apache configuration file hggpd dot com f you 311 00:15:38.559 --> 00:15:42.480 add a notify restart a patchy directive. If and only 312 00:15:42.519 --> 00:15:46.080 if that configuration TAC actually makes a change, it notifies 313 00:15:46.120 --> 00:15:49.759 the restart Apache handler. All the notifications are collected, and 314 00:15:49.799 --> 00:15:52.039 then at the end of the play ansable runs each 315 00:15:52.080 --> 00:15:55.159 notified handler once, even if it was notified multiple times. 316 00:15:55.240 --> 00:15:57.799 Ah, so you don't restart the service unnecessarily only if 317 00:15:57.799 --> 00:15:59.279 the config actually changed. 318 00:15:59.440 --> 00:16:03.519 Efficient exactly perfect for service restarts reloading configurations. Things like 319 00:16:03.559 --> 00:16:05.919 that insures consistency and efficiency. 320 00:16:06.279 --> 00:16:10.200 Real world automation isn't always smooth sailing though things go wrong? 321 00:16:10.679 --> 00:16:12.200 How does ansible handle errors? 322 00:16:12.600 --> 00:16:15.279 Error handling is crucial, and Ansable gives you quite a 323 00:16:15.279 --> 00:16:18.279 few tools. You can simply tell a task to ignore 324 00:16:18.480 --> 00:16:22.000 errors true if its failure isn't critical to the overall play. 325 00:16:22.279 --> 00:16:24.639 Maybe you're trying to remove a file that might not exist. 326 00:16:25.080 --> 00:16:28.879 You can define custom failure conditions using failed when maybe 327 00:16:28.919 --> 00:16:32.080 a command return success exit comes zero, but you know 328 00:16:32.159 --> 00:16:34.720 it actually failed. If certain text isn't present in its 329 00:16:34.720 --> 00:16:39.360 output failed when lets you check for that? Similarly changed 330 00:16:39.399 --> 00:16:42.440 when lets you define what constitutes a change for a task, 331 00:16:42.639 --> 00:16:46.000 overriding the default behavior. For more critical plays, you can 332 00:16:46.039 --> 00:16:49.200 set any errors fatal true. At the play level. This 333 00:16:49.320 --> 00:16:52.159 means the first task failure on any host stops the 334 00:16:52.320 --> 00:16:55.519 entire playbook run immediately, or you could use max fail 335 00:16:55.519 --> 00:16:58.120 percentage to tolerate a certain percentage of host failures before 336 00:16:58.200 --> 00:17:01.039 boarding the level of control. Pretty impressive. 337 00:17:01.279 --> 00:17:04.200 Okay, that covers playbooks in their advanced features. Pretty well, 338 00:17:04.319 --> 00:17:07.839 Let's talk about common system administration tasks. Managing files must 339 00:17:07.839 --> 00:17:08.720 be a huge part of this. 340 00:17:09.000 --> 00:17:12.119 Oh, absolutely. The guide covers a whole suite of modules 341 00:17:12.119 --> 00:17:15.640 for file and folder management. There's the file module itself 342 00:17:15.680 --> 00:17:20.240 for setting permissions, ownership, creating directories, deleting things, creating sim links, 343 00:17:21.119 --> 00:17:25.200 archive and unarchive for handling compressed files like tarballs or zips. 344 00:17:25.599 --> 00:17:27.839 A symbol is cool It lets you build a configuration 345 00:17:27.880 --> 00:17:31.000 file from smaller fragments or template parts. Copy you for 346 00:17:31.039 --> 00:17:33.599 getting files from your control node to the managed nodes. 347 00:17:34.119 --> 00:17:37.319 Fetch does the reverse pulling files back. Stat checks the 348 00:17:37.359 --> 00:17:40.119 status of a file like whether it exists, its size, etc. 349 00:17:40.559 --> 00:17:43.680 Without changing anything, and line and file and block and 350 00:17:43.680 --> 00:17:47.000 file are really useful for making targeted changes within existing 351 00:17:47.000 --> 00:17:51.119 configuration files, ensuring a specific line exists, or managing a 352 00:17:51.160 --> 00:17:52.200 whole block of text. 353 00:17:52.359 --> 00:17:55.599 Those line block modules sound handy but also potentially fiddly. 354 00:17:55.640 --> 00:17:57.880 If they can fig files complex or changes. 355 00:17:57.640 --> 00:18:01.279 Format they can be, and that's why for managing entire 356 00:18:01.359 --> 00:18:05.319 configuration files, templates are often a much better approach. Templates 357 00:18:05.400 --> 00:18:08.400 use the Gingitoo templating engine. Just like variables. You create 358 00:18:08.480 --> 00:18:12.119 a skeleton config file say engine x, dot COMF dot 359 00:18:12.200 --> 00:18:15.960 J two. Inside you mix static text with ginga two 360 00:18:16.000 --> 00:18:19.319 placeholders for variables or even logic like loops and conditionals. 361 00:18:19.839 --> 00:18:22.960 Then you use the template module in your playbook ansable 362 00:18:23.000 --> 00:18:25.799 reads the dot J two file, processes the GINGA two 363 00:18:25.799 --> 00:18:28.839 parts using facts and variables available for that host, and 364 00:18:28.880 --> 00:18:32.680 writes out the final rendered configuration file on the managed node. 365 00:18:33.200 --> 00:18:35.480 So instead of editing lines, you generate the whole file 366 00:18:35.519 --> 00:18:37.160 based on variables exactly. 367 00:18:37.240 --> 00:18:40.640 It avoids maintaining dozens of slightly different config files. You 368 00:18:40.640 --> 00:18:43.279 have one template and the variables handle the differences between 369 00:18:43.319 --> 00:18:46.880 dev staging, PROD or different server roles. It's much cleaner 370 00:18:46.880 --> 00:18:48.000 and less error prone. 371 00:18:48.279 --> 00:18:51.720 Makes sense. What about managing storage discs partitions? That kind 372 00:18:51.720 --> 00:18:51.960 of thing? 373 00:18:52.319 --> 00:18:55.720 Yep, that's covered two. There are modules for managing discs. 374 00:18:55.839 --> 00:18:59.000 The filesystem module can create filesystems like X two four 375 00:18:59.240 --> 00:19:02.319 XSA fat be fat on a block device. The mount 376 00:19:02.359 --> 00:19:05.960 module manages entries and etcetera stab and controls active mount points. 377 00:19:06.480 --> 00:19:10.599 The parted module lets you configure disc partitions directly, and importantly, 378 00:19:10.640 --> 00:19:14.920 it covers logical volume management LVM. LVM adds a layer 379 00:19:14.960 --> 00:19:18.319 of abstraction over physical discs, making storage much more flexible. 380 00:19:18.839 --> 00:19:22.880 Modules like LVG for volume groups and elvol for logical 381 00:19:22.960 --> 00:19:27.759 volumes let you manage LVM setups, dynamically resizing volumes, adding discs, 382 00:19:27.799 --> 00:19:30.000 et cetera. All through ansable. 383 00:19:29.640 --> 00:19:32.720 Okay, disc management. What about running tasks on a schedule 384 00:19:32.920 --> 00:19:34.000 like chron jobs. 385 00:19:33.960 --> 00:19:37.200 Essential sissudmin task right. The ansable dot built in dot 386 00:19:37.240 --> 00:19:40.400 chron module handles that perfectly. You can use it to add, modify, 387 00:19:40.519 --> 00:19:42.880 or remove entries in a user's chron tab. Great for 388 00:19:42.920 --> 00:19:46.880 automating regular maintenance like backups, log rotation, cleaning up temporary files. 389 00:19:47.079 --> 00:19:49.359 You define the job schedule and command write in your playbook. 390 00:19:49.680 --> 00:19:51.559 And finally, security always critical. 391 00:19:51.640 --> 00:19:55.079 How does ansable help There several ways mentioned in the guide. 392 00:19:55.160 --> 00:19:57.839 For SSH and figuration. You might use line file to 393 00:19:57.960 --> 00:20:01.839 ensure specific settings are present in sisash dot config like 394 00:20:01.880 --> 00:20:05.680 setting max authrees, though be careful not to lock yourself out. 395 00:20:05.799 --> 00:20:06.359 Good warning. 396 00:20:06.599 --> 00:20:10.519 For managing software sources like YM repositories on red Hat systems, 397 00:20:10.759 --> 00:20:14.000 there's the RPM key module to import GPG keys for 398 00:20:14.160 --> 00:20:18.240 verifying package signatures, and the m repository module manages the 399 00:20:18.240 --> 00:20:21.759 actual repository configuration files in etzm dot repos dot d 400 00:20:22.440 --> 00:20:25.920 ensuring your systems only pull packages from trusted sources. And 401 00:20:26.000 --> 00:20:30.079