WEBVTT 1 00:00:00.080 --> 00:00:04.000 Ever feel like you're just drowning and repetitive it tasks, 2 00:00:04.400 --> 00:00:05.480 always fighting the clock. 3 00:00:05.599 --> 00:00:09.519 Oh yeah, configuration drift, endless deployment cycles. It's a common 4 00:00:09.519 --> 00:00:10.279 pain point. 5 00:00:10.119 --> 00:00:12.320 It really is. Yeah, you almost wish for a magic 6 00:00:12.359 --> 00:00:15.119 wand sometimes, well we don't have magic, but we do 7 00:00:15.160 --> 00:00:15.759 have antsable. 8 00:00:15.800 --> 00:00:20.920 It's pretty close. Sometimes it's this fantastic automation tool, hugely 9 00:00:20.960 --> 00:00:25.079 popular now for everything from simple server set up to 10 00:00:25.559 --> 00:00:27.600 really complex cloud stuff. 11 00:00:27.280 --> 00:00:30.359 And the community support is just massive. So today we're 12 00:00:30.359 --> 00:00:33.439 doing a deep dive aiming to make antsable really clear 13 00:00:33.719 --> 00:00:35.359 and practical for you. 14 00:00:35.479 --> 00:00:38.439 Yeah, we're leaning heavily on practical antsable dot pdf Here. 15 00:00:38.719 --> 00:00:41.119 It's like a condensed guide and we're pulling out the 16 00:00:41.159 --> 00:00:43.159 absolute essentials, the core ideas. 17 00:00:43.200 --> 00:00:45.000 Think of it as your shortcut. We're not just reading 18 00:00:45.000 --> 00:00:48.679 a manual or getting straight to the key concepts exactly. 19 00:00:48.840 --> 00:00:52.840 We'll cover getting it installed, the fundamentals like modules and playbooks, 20 00:00:52.840 --> 00:00:55.280 managing different osias, Linux, Windows, Mac. 21 00:00:55.159 --> 00:00:59.359 Os right and inventories, variables, plus how it plugs into 22 00:00:59.399 --> 00:01:02.679 cloud platforms, containers, all that good stuff. 23 00:01:02.880 --> 00:01:05.159 Our goal to give you a really solid grasp of 24 00:01:05.159 --> 00:01:08.159 ansable's basics so you can see how it could genuinely 25 00:01:08.879 --> 00:01:10.079 streamline your own work. 26 00:01:10.560 --> 00:01:14.359 Okay, let's jump in. First things. First installation, the book 27 00:01:14.359 --> 00:01:17.200 talks about the control node. What's the main takeaway there? 28 00:01:17.280 --> 00:01:19.920 The big thing is the control node is your command center. 29 00:01:20.000 --> 00:01:23.319 It's where Ansable lives, where you run your commands, your playbooks. Okay, 30 00:01:23.400 --> 00:01:27.560 but crucially, Ansable itself doesn't need to be installed on 31 00:01:27.640 --> 00:01:29.959 the machines you're managing the managed nodes. 32 00:01:30.239 --> 00:01:33.680 Ah. Okay, So the control node just needs what Python. 33 00:01:33.599 --> 00:01:36.879 Python three point nine or newer, and it's typically Linux 34 00:01:37.159 --> 00:01:40.879 or maybe FreeBSD. That agentless design is a really big deal, 35 00:01:41.000 --> 00:01:42.079 much simpler. 36 00:01:41.799 --> 00:01:45.280 Right, agentless less stuff to manage everywhere else. So installing 37 00:01:45.319 --> 00:01:48.680 on that control node looks like there are a few ways. 38 00:01:48.760 --> 00:01:51.200 Package manager versus PAP. 39 00:01:51.040 --> 00:01:54.079 Exactly your system package manager like APPED or you DNF. 40 00:01:54.280 --> 00:01:56.760 It's off for the quickest way to get going, super simple. 41 00:01:57.239 --> 00:02:00.680 But the book also highlights PIP, the Python installed The 42 00:02:00.719 --> 00:02:03.400 advantage there is consistency. You get the same install process 43 00:02:03.799 --> 00:02:06.359 regardless of the Linux distro or even on mac os 44 00:02:06.400 --> 00:02:07.120 if you have Python. 45 00:02:07.319 --> 00:02:11.439 Ah so PIP gives you more control, maybe across different systems. 46 00:02:11.080 --> 00:02:14.560 Precisely, especially if you need specific Ansible versions just one 47 00:02:14.560 --> 00:02:17.319 thing to remember. If you use PIP, you manage ansable 48 00:02:17.400 --> 00:02:19.800 updates yourself separately from system updates. 49 00:02:19.879 --> 00:02:21.680 Got it. So if I go to the PIP route, 50 00:02:21.840 --> 00:02:22.680 what's the command? 51 00:02:22.879 --> 00:02:26.280 First check your Python version Python three version, make sure 52 00:02:26.280 --> 00:02:29.199 it's three point nine plus. Okay, Then you probably need 53 00:02:29.280 --> 00:02:33.000 PIP itself, maybe apped install Python three PIP or similar 54 00:02:33.039 --> 00:02:36.560 depending on your US. Right, and then the magic pseudo 55 00:02:36.599 --> 00:02:40.719 Python three dash meter pip install antsable. That should do. 56 00:02:40.680 --> 00:02:43.479 It pretty straightforward. And if I need, say an older 57 00:02:43.599 --> 00:02:44.240 version for. 58 00:02:44.159 --> 00:02:46.639 Some reason, GIP handles that too. Just add the version 59 00:02:46.879 --> 00:02:49.759 like a Python three dol meter PIP install antsable eight 60 00:02:49.759 --> 00:02:52.280 point zero twenty zero. You pin it right there. Super 61 00:02:52.360 --> 00:02:53.719 useful for project consistency. 62 00:02:53.800 --> 00:02:57.639 Okay. Now the book brings up virtual environments or VENs. 63 00:02:58.159 --> 00:03:00.000 Why bother with those? Seems like an extra step? 64 00:03:00.560 --> 00:03:02.680 Yeah, it might seem like it, but they're really valuable. 65 00:03:02.759 --> 00:03:05.879 Think of them as like little sandboxes for your Python projects. 66 00:03:05.919 --> 00:03:06.439 Sandbox. 67 00:03:06.520 --> 00:03:08.680 Yeah, so you can have Project A needing ansile eight 68 00:03:09.000 --> 00:03:12.039 and Project B needing anspell nine, each in its own vents. 69 00:03:12.039 --> 00:03:14.759 They don't interfere with each other or with your main 70 00:03:14.800 --> 00:03:15.479 system Python. 71 00:03:15.759 --> 00:03:18.800 Ah. Okay, so it stops dependency conflicts. 72 00:03:19.039 --> 00:03:23.240 Keeps things clean exactly, keeps things clean, reproducible. It's definitely 73 00:03:23.280 --> 00:03:25.280 the best practice. You create one with Python three nine 74 00:03:25.319 --> 00:03:29.439 ers venvev my ansle project or whatever, then activate it 75 00:03:29.919 --> 00:03:32.719 like source my ansable project by activate. Then your PIP 76 00:03:32.719 --> 00:03:36.000 install antsable just installs it inside that environment. 77 00:03:36.199 --> 00:03:38.919 Okay, that makes sense, avoids headaches down the line. What 78 00:03:38.960 --> 00:03:43.039 about mac os? Is installation simple there? Usually? Yeah? 79 00:03:43.080 --> 00:03:46.400 Homebrew is the popular way. Just brew install ansable pretty easy. 80 00:03:46.479 --> 00:03:49.360 All right, let's tackle Windows. The book says direct install 81 00:03:49.479 --> 00:03:52.159 isn't really the thing, So how do we manage Windows hosts? 82 00:03:52.400 --> 00:03:55.000 Right? Yeah, direct install isn't recommended. Two main paths. One 83 00:03:55.039 --> 00:03:58.879 is WSL Windows subsystem for Linux. Okay, US install Linux 84 00:03:58.960 --> 00:04:02.120 inside Windows, then install ansable and Linux like normal. 85 00:04:02.199 --> 00:04:04.240 Works great, so you get a proper Linux environment for 86 00:04:04.280 --> 00:04:06.120 antsable and the other way. 87 00:04:06.280 --> 00:04:10.039 The other way is agentless using win RM Windows Remote Management. 88 00:04:10.599 --> 00:04:14.360 It's built into Windows. Ansable talks to it using PowerShell 89 00:04:14.439 --> 00:04:15.560 underneath win RM. 90 00:04:15.639 --> 00:04:17.360 Okay, so what needs to be set up on the 91 00:04:17.360 --> 00:04:18.639 Windows side for that to work? 92 00:04:18.800 --> 00:04:22.800 Good question. You need a supported Windows version obviously Windows 93 00:04:22.800 --> 00:04:26.240 eight point one, Server twenty twelve R two or newer. Basically, 94 00:04:26.720 --> 00:04:29.360 you need PowerShell three point zero or later, dot Net 95 00:04:29.399 --> 00:04:32.360 four point zero plus and the big one. You need 96 00:04:32.360 --> 00:04:34.160 a win RM listener configured and running. 97 00:04:34.160 --> 00:04:36.720 It's not on by default right security default, So how 98 00:04:36.720 --> 00:04:38.240 do you actually enable that listener? 99 00:04:38.439 --> 00:04:40.839 There are PowerShell commands for it. The book gives some 100 00:04:40.920 --> 00:04:43.839 examples for basic authentication, which is okay for maybe local 101 00:04:43.879 --> 00:04:45.120 accounts are testing. 102 00:04:45.000 --> 00:04:45.759 But for production. 103 00:04:45.879 --> 00:04:49.680 For production, Caberro's authentication is strongly recommended, much more secure. 104 00:04:50.079 --> 00:04:52.720 The Ansible docs have detailed guides on setting that up 105 00:04:52.759 --> 00:04:55.680 with WinRM. Okay, and you'll almost certainly need to configure 106 00:04:55.680 --> 00:04:57.920 the Windows Firewall two to allow connections on the Winter 107 00:04:58.000 --> 00:05:01.120 imports usually foy to ninet eighty five for HTCP five 108 00:05:01.240 --> 00:05:04.360 nine eighty six for hgdps. Definitely use HTTPS. 109 00:05:04.680 --> 00:05:10.160 Okay, Https for encryption makes sense. So we've got Ansible installed, 110 00:05:10.199 --> 00:05:12.279 we know how to prep Windows. Let's dig into how 111 00:05:12.279 --> 00:05:16.120 ancible actually works. That agentless architecture keeps coming up. Why 112 00:05:16.199 --> 00:05:17.199 is that such a big deal. 113 00:05:17.560 --> 00:05:21.279 It's really fundamental, no agents to install or maintain on 114 00:05:21.360 --> 00:05:23.240 your managed nodes. That's the core idea. 115 00:05:23.399 --> 00:05:25.759 So simpler setup, much simpler and. 116 00:05:25.800 --> 00:05:29.360 Arguably more secure. Fewer moving parts less attack surface on 117 00:05:29.439 --> 00:05:34.279 those nodes. Ansible just uses standard protocols SSH for Linux, Unix, 118 00:05:34.360 --> 00:05:36.120 WinRM for Windows. 119 00:05:36.319 --> 00:05:38.360 And how does it execute tests? 120 00:05:38.439 --> 00:05:41.439 Then it pushes small bits of code the modules over 121 00:05:41.480 --> 00:05:45.240 that connection. The module runs, does its thing, returns the result, 122 00:05:45.439 --> 00:05:47.160 and then it's removed clean. 123 00:05:47.000 --> 00:05:48.319 Keeps the managed nodes tidy. 124 00:05:48.759 --> 00:05:49.040 Nice. 125 00:05:49.199 --> 00:05:52.879 Now, how about anspble's own settings the ansible dot cfg file. 126 00:05:52.720 --> 00:05:55.959 Right, ansible dot cfg. That's where you tweak Ansble's behavior. 127 00:05:56.199 --> 00:05:59.480 The key thing is the precedence order. Precedence yeah, answer 128 00:05:59.480 --> 00:06:02.839 looks for it several places. First environment variable ansable can 129 00:06:02.879 --> 00:06:04.879 fig if not found to check the current directory you're 130 00:06:04.920 --> 00:06:08.920 running from, then your home directory like dot ansable dot cfg. 131 00:06:09.160 --> 00:06:12.800 And finally the system wide location at cancible saveable dot 132 00:06:12.839 --> 00:06:15.040 cfg uses the first one it finds. 133 00:06:15.360 --> 00:06:18.360 So you can have project specific settings, or user settings 134 00:06:18.439 --> 00:06:19.480 or system defaults. 135 00:06:20.120 --> 00:06:22.319 Flexible, exactly, very flexible. 136 00:06:22.360 --> 00:06:23.879 What if I just installed it and I don't have 137 00:06:23.920 --> 00:06:25.040 an ansible dot cfg. 138 00:06:25.199 --> 00:06:29.199 Common situation. Yeah, especially with PIP installs. You can easily 139 00:06:29.240 --> 00:06:32.639 generate a template. The command is ansable canfig in it 140 00:06:32.720 --> 00:06:34.639 disabled ansable dot cfg. 141 00:06:34.839 --> 00:06:35.399 Ah. 142 00:06:35.680 --> 00:06:38.279 That gives you a file with all the possible settings 143 00:06:38.319 --> 00:06:41.160 commented out the defaults. You usually find a start, but 144 00:06:41.240 --> 00:06:43.720 it's good to know how to generate and customize. 145 00:06:43.240 --> 00:06:46.279 This good tip. Okay, config file covered. What about just 146 00:06:46.360 --> 00:06:50.319 running quick one off commands? The book mentions ad hoc commands. 147 00:06:50.439 --> 00:06:54.199 Ad hoc commands are brilliant for quick tasks, simple immediate. 148 00:06:54.480 --> 00:06:56.600 You use the ansable command directly. 149 00:06:56.279 --> 00:06:58.600 So not writing a full playbook exactly. 150 00:06:58.279 --> 00:07:00.480 Just a single task. Yeah, you use for the module 151 00:07:00.560 --> 00:07:02.720 name and A for the arguments of that module. 152 00:07:02.759 --> 00:07:04.759 What would you use them for? Like, give me an example. 153 00:07:04.959 --> 00:07:06.800 Okay, so you want to quickly check a servers or 154 00:07:06.839 --> 00:07:10.639 online ansable my d servers, ansible dot built in dot ping. 155 00:07:10.920 --> 00:07:12.360 You'll get a pong back if they're. 156 00:07:12.279 --> 00:07:13.480 Up simple enough. 157 00:07:13.639 --> 00:07:15.839 What else, Maybe grab a specific fact like the OS 158 00:07:15.959 --> 00:07:18.800 version ansable, some host ansable dot built in dot set 159 00:07:18.879 --> 00:07:23.920 up a filter ansible distribution it turns just that info. Okay, 160 00:07:24.040 --> 00:07:28.120 Or install a package quickly ansible webservers, danceable, dot built 161 00:07:28.120 --> 00:07:31.839 in dot app FIM and the antivic state latest become 162 00:07:32.360 --> 00:07:34.839 to become is for running with pseudo or root. 163 00:07:34.680 --> 00:07:36.680 Privileges right for privileged escalation. 164 00:07:36.920 --> 00:07:40.160 Yeah, and if you're just curious ansible all m ansable 165 00:07:40.160 --> 00:07:43.360 dot built in dot setup dumps all the facts ansable 166 00:07:43.439 --> 00:07:47.000 knows about all your hosts. It's a lot, but useful. 167 00:07:47.040 --> 00:07:48.079 Sometimes ad hoc. 168 00:07:47.959 --> 00:07:50.839 Sounds super handy for poking around and quick fixes. Now 169 00:07:50.879 --> 00:07:53.759 ancible needs to know which machines to manage. That's inventories, right, 170 00:07:53.759 --> 00:07:54.720 what's the core idea? 171 00:07:54.920 --> 00:07:57.480 The inventory is simply your list of target machines where 172 00:07:57.480 --> 00:07:58.240 ansable should go. 173 00:07:58.600 --> 00:08:00.000 That's it, and how do you define that list? 174 00:08:00.480 --> 00:08:04.600 Most commonly with static files either IONI format, which is 175 00:08:04.800 --> 00:08:08.319 simple key value pairs and sections, or yamal format, which 176 00:08:08.360 --> 00:08:10.800 is more structured and there's always a default group call. 177 00:08:10.920 --> 00:08:14.000 All that well includes everything in your inventory. It just 178 00:08:14.040 --> 00:08:15.319 tells ansable who to talk to. 179 00:08:15.959 --> 00:08:18.839 Can you show me a really basic I NI example? 180 00:08:18.959 --> 00:08:22.079 Sure, super simple? Could be dot any, dot webservers, dot 181 00:08:22.199 --> 00:08:25.839 web one, dot example, dot com, web two, dot example, 182 00:08:25.879 --> 00:08:30.079 dot com, databases, dB one, dot example, dot com. 183 00:08:30.120 --> 00:08:32.320 Okay, just groups and host names. Can you put connection 184 00:08:32.360 --> 00:08:33.159 details in there too? 185 00:08:33.279 --> 00:08:35.919 Yep. If a host needs a specific user or port, 186 00:08:36.120 --> 00:08:38.000 you can add it right on the line, like web one, 187 00:08:38.039 --> 00:08:42.480 dot example, dot com, ansable port twenty two, twenty two, antsples. 188 00:08:42.039 --> 00:08:45.559 Or bob gotcha and yamlinventories. When would I use those? 189 00:08:45.679 --> 00:08:48.200 Jamal's great. When things get more complex, it's more structured, 190 00:08:48.200 --> 00:08:50.639 maybe easier to read. For larger setups. You can embed 191 00:08:50.759 --> 00:08:53.200 variables directly within the ammal structure two, which is handy. 192 00:08:53.279 --> 00:08:56.200 Okay, So inventory's point to the wear Now configuring those machines. 193 00:08:56.200 --> 00:09:01.039 Different settings, software versions. That's host and group variables exactly variables. 194 00:09:01.080 --> 00:09:03.919 Let you define settings that antsable can use in its tasks. 195 00:09:04.159 --> 00:09:06.559 You can define them for a specific host or for 196 00:09:06.639 --> 00:09:09.000 a whole group of hosts. What's that The main benefit. 197 00:09:08.919 --> 00:09:13.679 Reasonability and specificity. Define common settings at the group level, 198 00:09:13.960 --> 00:09:18.320 then override them for specific hosts if needed. Host variables 199 00:09:18.360 --> 00:09:21.120 always win over group variables if there's a conflict. Make 200 00:09:21.200 --> 00:09:22.320 things really flexible. 201 00:09:22.399 --> 00:09:25.639 The book mentions host bars and group bars directories. How 202 00:09:25.639 --> 00:09:26.159 do they help? 203 00:09:26.360 --> 00:09:30.000 Ah? Yeah. Instead of stuffing everything into the main inventory file, 204 00:09:30.039 --> 00:09:34.440 which gets messy fast, you create these directories. Ancible automatically 205 00:09:34.480 --> 00:09:37.279 looks for them. Inside group fars you have files named 206 00:09:37.279 --> 00:09:41.000 after your groups like webservers dot EML. Inside host fars 207 00:09:41.039 --> 00:09:44.440 files named after hosts like dB one, dot example, dot com, 208 00:09:44.480 --> 00:09:45.360 dot IML. 209 00:09:45.519 --> 00:09:49.120 So it keeps the variable definitions separate and organized. 210 00:09:48.720 --> 00:09:53.039 Totally, much cleaner, much more scalable. And another detail. Variables 211 00:09:53.039 --> 00:09:57.559 in child groups override parent groups, so you layers of configuration. 212 00:09:57.159 --> 00:10:01.519 Okay, inventories for targets, variables for configurations specifics now modules. 213 00:10:01.600 --> 00:10:04.120 What are the exact modules? Are the actual tools Ansible 214 00:10:04.240 --> 00:10:06.440 uses to get things done. They're pre built units of 215 00:10:06.440 --> 00:10:07.799 code for specific. 216 00:10:07.360 --> 00:10:08.960 Tasks like what kind of tasks? 217 00:10:09.240 --> 00:10:13.919 Oh? Tons of stuff? Managing packages apped, yeah, managing services, 218 00:10:14.360 --> 00:10:20.480 service system, creating files, file copy, user management, user interacting 219 00:10:20.480 --> 00:10:24.360 with databases, cloud resources, hundreds and hundreds of them. 220 00:10:24.399 --> 00:10:26.679 So you don't have to script everything from scratch. 221 00:10:26.559 --> 00:10:28.840 Right, you just call the module you need. That's the 222 00:10:28.879 --> 00:10:30.720 power leverage the community's work. 223 00:10:30.879 --> 00:10:33.320 How do you find the right module though? If there 224 00:10:33.320 --> 00:10:33.960 are so many? 225 00:10:34.519 --> 00:10:37.840 The official Ansible documentation is the best place. It's searchable, 226 00:10:38.120 --> 00:10:41.759 well organized, okay, or on the command line ansible doc 227 00:10:41.960 --> 00:10:45.360 slake lists all in sold modules. You can pipe that 228 00:10:45.399 --> 00:10:45.879 top to. 229 00:10:45.879 --> 00:10:49.919 Search antsable doc sl grip database maybe exactly. 230 00:10:50.240 --> 00:10:52.600 And once you find one answable doc module name like 231 00:10:52.600 --> 00:10:55.080 ansible doc ansble dot built in dot appt give you 232 00:10:55.159 --> 00:10:58.399 all the details, parameters, examples, return values, essential reading. 233 00:10:58.519 --> 00:11:01.000 Okay, modules do the work What about plugins? How are 234 00:11:01.000 --> 00:11:01.480 they different? 235 00:11:01.559 --> 00:11:06.320 Plugins? Extend ansables core functionality modules perform tasks on managed nodes. 236 00:11:06.320 --> 00:11:10.000 Mostly plugins change how ansable itself behaves or interacts with things. 237 00:11:10.080 --> 00:11:13.879 Extend filters for manipulating data and templates. Look up plugins 238 00:11:13.919 --> 00:11:17.399 to fetch data from external sources, connection plugins to talk 239 00:11:17.440 --> 00:11:19.559 to different kinds of devices, stuff like that. 240 00:11:19.600 --> 00:11:21.320 Can you create your own absolutely? 241 00:11:21.759 --> 00:11:25.360 If you need some very specific data transformation or connection method, 242 00:11:25.720 --> 00:11:28.000 you can write a custom plug in. Usually in Python 243 00:11:28.080 --> 00:11:30.159 you put them in special directories like filter. 244 00:11:29.919 --> 00:11:36.080 Plugins, got it modules, act plugins enhanced now orchestrating sequences 245 00:11:36.320 --> 00:11:40.000 of these actions. That's playbooks right the core automation definition. 246 00:11:40.080 --> 00:11:43.360 Playbooks are absolutely central. They're Yamel files where you define 247 00:11:43.360 --> 00:11:44.480 your automation workflow. 248 00:11:44.559 --> 00:11:45.440 How are they structured? 249 00:11:45.559 --> 00:11:48.159 They consist of one or more plays. Each play targets 250 00:11:48.200 --> 00:11:50.679 a set of hosts from your inventory and contains a 251 00:11:50.720 --> 00:11:51.200 list of. 252 00:11:51.120 --> 00:11:54.399 Tasks and tasks use modules exactly. 253 00:11:54.679 --> 00:11:57.679 Each task typically calls one answable module to perform an 254 00:11:57.679 --> 00:12:01.000 action on the targeted hosts. The playbook defines the sequence 255 00:12:01.039 --> 00:12:02.200 that targets the whole flow. 256 00:12:02.399 --> 00:12:04.720 Can you limit which hosts of playbook runs on? 257 00:12:04.960 --> 00:12:08.000 YEP? The limit flag is your friend. There answable, dash playbooksite, 258 00:12:08.039 --> 00:12:11.480 dot EML limit webservers runs it only on the webservers group. 259 00:12:11.559 --> 00:12:13.759 Even if the playbook targets all great. 260 00:12:13.559 --> 00:12:16.480 For testing, and when it runs, it tells you what happened. 261 00:12:16.559 --> 00:12:19.519 Yeah, you get output for each task on each host. Okay, 262 00:12:19.559 --> 00:12:22.879 if nothing changed changed, if it made a modification failed, 263 00:12:22.919 --> 00:12:26.399 something went wrong. Unreachable gives you good visibility. 264 00:12:26.559 --> 00:12:29.879 The book stresses naming tasks and playbooks. Why is that important? 265 00:12:30.039 --> 00:12:33.799 Readability? Seriously, when the playbook runs or if you're troubleshooting, 266 00:12:34.120 --> 00:12:37.919 seeing installed Jink's web server is way more helpful than 267 00:12:38.000 --> 00:12:40.679 just seeing antsable dot built in dot app makes your 268 00:12:40.679 --> 00:12:42.919 playbooks self documenting almost makes sense. 269 00:12:43.039 --> 00:12:45.840 Now, variables Again, we talked about inventory variables. Can you 270 00:12:45.879 --> 00:12:47.519 define them right inside a playbook too? 271 00:12:47.679 --> 00:12:51.840 You sure can. Playbooks have a VARs section for defining 272 00:12:51.919 --> 00:12:56.840 variables specific to that playbook's execution. Useful for things only 273 00:12:56.879 --> 00:12:57.519 needed right there? 274 00:12:57.559 --> 00:12:58.960 How do you use them in tasks? 275 00:12:59.080 --> 00:13:02.639 With jing two temp double curly braces? Can use them 276 00:13:02.639 --> 00:13:06.480 in module arguments, file names anywhere you need dynamic values. 277 00:13:06.159 --> 00:13:09.240 And JINGA two. The book mentions JINGA two filters as well. 278 00:13:09.279 --> 00:13:09.879 What do they do. 279 00:13:10.279 --> 00:13:13.960 Filters let you manipulate data right inside your templates. Convert 280 00:13:14.000 --> 00:13:18.080 data types, format strings, extract parts of data structures, parse 281 00:13:18.159 --> 00:13:20.200 json or YAML stored in variables. 282 00:13:21.039 --> 00:13:23.919 Very powerful like transforming data on the fly within the 283 00:13:23.919 --> 00:13:25.080 playbook exactly. 284 00:13:25.440 --> 00:13:28.320 The book shows examples like from Yamel to parse yaml, 285 00:13:28.480 --> 00:13:31.720 or items to Dick to create dictionaries. Lots of built 286 00:13:31.759 --> 00:13:33.679 in filters, and you can use custom ones too. 287 00:13:33.799 --> 00:13:36.759 Okay, playbooks organized tasks. But what if I have a 288 00:13:36.840 --> 00:13:39.440 common set of tasks, like setting up a standard web 289 00:13:39.480 --> 00:13:43.759 server that I need in multiple playbooks. Copy paste seems bad. 290 00:13:43.720 --> 00:13:46.919 Very bad. That's precisely where roles come in. They are 291 00:13:46.960 --> 00:13:50.720 the solution for reusable antsiple code. Reusable how you bundle 292 00:13:50.799 --> 00:13:54.000 up a related set of tasks, variables, handlers, even files 293 00:13:54.000 --> 00:13:56.519 and templates into a standard directory structure. 294 00:13:56.679 --> 00:13:59.320 That's a role like a self contained automation unit. 295 00:13:59.440 --> 00:14:01.879 Pretty much. You define the role once a common role 296 00:14:01.879 --> 00:14:04.600 for a basic server setup or an injin's role. Then 297 00:14:04.679 --> 00:14:06.360 in your playbook you just list the roles you want 298 00:14:06.399 --> 00:14:09.440 to apply to a set of hosts. So roles common 299 00:14:09.600 --> 00:14:13.039 jinks exactly like that, ansable knows how to find the 300 00:14:13.120 --> 00:14:15.960 role if it's in a standard location or defined path 301 00:14:16.360 --> 00:14:21.120 and executes its tasks. Hugely improves the organization and avoids repetition. 302 00:14:22.120 --> 00:14:24.559 Roles can even have dependencies on other roles. 303 00:14:24.799 --> 00:14:28.080 Roles sound essential for anything non trivial. Now, controlling of 304 00:14:28.080 --> 00:14:30.799 a task runs conditionals. 305 00:14:30.480 --> 00:14:34.240 The when keyword. You add when to a task followed 306 00:14:34.279 --> 00:14:37.320 by an expression. The task only runs if that expression 307 00:14:37.360 --> 00:14:38.360 evaluates to true. 308 00:14:38.480 --> 00:14:39.480 What kind of expression? 309 00:14:39.639 --> 00:14:42.519 Usually based on ansible facts, the data gathered about the host, 310 00:14:42.600 --> 00:14:46.519 or your own variables like when answible facts off family. 311 00:14:46.600 --> 00:14:48.720 Red Hat ensures a task only runs on red Hat 312 00:14:48.759 --> 00:14:52.360 based systems. Critical for handling differences in your environment. 313 00:14:52.080 --> 00:14:54.759 And doing the same task many times with different inputs, 314 00:14:54.799 --> 00:14:56.200 like creating several users. 315 00:14:56.240 --> 00:14:59.240 That's loops. Using the loop keyword, you provide a list 316 00:14:59.279 --> 00:15:01.639 of items and the task runs once for each item, 317 00:15:02.000 --> 00:15:05.840 usually substituting the item into the tasks parameters super efficient 318 00:15:05.879 --> 00:15:06.960 for repetitive actions. 319 00:15:07.080 --> 00:15:10.480 Automation isn't always perfect. Errors happen. How do blocks help 320 00:15:10.519 --> 00:15:10.759 with that? 321 00:15:11.159 --> 00:15:15.039 Blocks? Blocks block that up let you group tasks and 322 00:15:15.080 --> 00:15:18.120 add error handling. You can have a rescue section that 323 00:15:18.240 --> 00:15:20.360 runs only if a task within the block. 324 00:15:20.120 --> 00:15:22.879 Fails for cleanup or roll back. 325 00:15:22.639 --> 00:15:26.240 Exactly and an always section runs regardless of success or 326 00:15:26.279 --> 00:15:29.480 failure in the block. Good for final cleanup tasks like 327 00:15:29.679 --> 00:15:32.519 even get temp files or logging. Completion gives you much 328 00:15:32.559 --> 00:15:35.519 more robust error handling than just letting the playbook crash. 329 00:15:35.720 --> 00:15:38.759 And if the playbook does crash or just isn't working right, 330 00:15:39.120 --> 00:15:40.200 is there a debugger? 331 00:15:40.480 --> 00:15:40.720 Yes? 332 00:15:41.399 --> 00:15:44.200 Ansable has a built in debugger. Run your playbook with 333 00:15:44.240 --> 00:15:47.120 step It pauses it each task, or you can set 334 00:15:47.120 --> 00:15:48.480 it to pause only on failure. 335 00:15:48.600 --> 00:15:49.879 What can you do in the debugger? 336 00:15:50.240 --> 00:15:53.399 You can inspect variables, p task dot orgs, rerun the 337 00:15:53.399 --> 00:15:56.919 failed task with changes, continue executions step by step. It's 338 00:15:56.960 --> 00:15:59.279 incredibly helpful for figuring out why something failed. 339 00:15:59.360 --> 00:16:02.720 Okay, the book mentions asynchronous tasks too. When would you 340 00:16:02.799 --> 00:16:04.200 run something async for. 341 00:16:04.200 --> 00:16:06.720 Long running tasks you don't want to wait for kicking 342 00:16:06.799 --> 00:16:09.519 off a system update, a backup job, maybe provisioning a 343 00:16:09.559 --> 00:16:10.720 slow cloud resource. 344 00:16:10.799 --> 00:16:11.480 How does it work? 345 00:16:11.720 --> 00:16:14.039 You use the acink keyword on a task with a 346 00:16:14.080 --> 00:16:17.519 time limit and poll set to zero. Antsable starts the 347 00:16:17.559 --> 00:16:19.480 task in the background and moves on immediately. 348 00:16:19.679 --> 00:16:21.000 How do you know when it's done? 349 00:16:21.240 --> 00:16:23.440 You can use another task later with the ansable dot 350 00:16:23.519 --> 00:16:26.159 built in dot acing status module to check up on 351 00:16:26.200 --> 00:16:27.679 the jobs progress or completion. 352 00:16:28.159 --> 00:16:31.279 Right, what about updating lots of servers safely. 353 00:16:31.240 --> 00:16:36.240 Ruling updates essential for minimizing downtime. The serial dot keyword 354 00:16:36.279 --> 00:16:39.080 in a play lets you control how many hosts antsable 355 00:16:39.080 --> 00:16:43.039 works on simultaneously. Cereal one does one at a time, 356 00:16:43.399 --> 00:16:46.200 Cereal five does batches of five okay, And you can 357 00:16:46.200 --> 00:16:49.519 combine that with max fail percentage. If say twenty percent 358 00:16:49.519 --> 00:16:51.960 of hosts in a batch fail, antsable can stop the 359 00:16:52.039 --> 00:16:55.279 rollout before it affects more machines, much safer deployments. 360 00:16:55.559 --> 00:16:57.639 Sometimes you need a task to run somewhere else, right, 361 00:16:57.720 --> 00:16:58.720 not on the target host. 362 00:16:58.799 --> 00:17:02.080 Yeah, that's task delegation. Using delegates frecho, you tell a 363 00:17:02.080 --> 00:17:04.880 task to run on a different host specified in your inventory. 364 00:17:05.359 --> 00:17:08.200 Common for interacting with load balancers or monitoring systems from 365 00:17:08.200 --> 00:17:09.759 an app server, for example. 366 00:17:09.440 --> 00:17:11.759 And ensuring a task runs only once total, no matter 367 00:17:11.799 --> 00:17:12.480 how many hosts. 368 00:17:12.759 --> 00:17:17.279 That's ronounce true, useful for things like initializing a database 369 00:17:17.279 --> 00:17:20.680 schema or registering with the central service. Just be aware 370 00:17:21.000 --> 00:17:23.880 if you use cereal, it runs once per batch. 371 00:17:24.119 --> 00:17:27.319 Can I use ansable to manage the machine I'm running 372 00:17:27.319 --> 00:17:29.000 it from? The control nerd itself. 373 00:17:29.039 --> 00:17:32.319 Absolutely, you don't target local hosts necessarily, though you can. 374 00:17:32.720 --> 00:17:36.200 The key is setting Ansible connection local for that host 375 00:17:36.200 --> 00:17:39.480 in your inventory. It tells Ansible run these tasks right here. 376 00:17:39.720 --> 00:17:43.039 No SSH needed. Good for local setup or bootstrapping. 377 00:17:43.119 --> 00:17:45.640 Tag team handy for big playbooks. How do they work? 378 00:17:45.759 --> 00:17:49.039 Tag? Let you label plays or tasks. Just add tags 379 00:17:49.240 --> 00:17:52.400 some tag another tag. Then when you run answable playbook 380 00:17:52.559 --> 00:17:55.119 you can use tags some tag to only run things. 381 00:17:54.920 --> 00:17:56.519 With that tag or skip tags. 382 00:17:56.599 --> 00:17:59.240 Yeah, skip tags. Another tag does the opposite, and list 383 00:17:59.279 --> 00:18:02.599 tasks shows you all tasks and their tags for running 384 00:18:02.599 --> 00:18:04.759 specific parts of a large workflow. 385 00:18:04.839 --> 00:18:08.119 Finally, for fundamentals, Ansible vault. What problems that solve? 386 00:18:08.319 --> 00:18:12.599 Secrets management? Storing sensitive stuff like passwords, API keys securely 387 00:18:12.599 --> 00:18:15.279 within your ansable project instead of in plain text. Not 388 00:18:15.440 --> 00:18:18.799 vaulting crypts files or individual variable strings. You need a 389 00:18:18.839 --> 00:18:22.880 password to encrypt and decrypt them. Ansible automatically decrypts them 390 00:18:22.920 --> 00:18:26.519 during playbook execution when needed. If you provide the password, 391 00:18:26.680 --> 00:18:28.359 it keeps your secrets safe at rest. 392 00:18:28.680 --> 00:18:32.240 Okay, that's a solid foundation. Let's shift to how Ansible 393 00:18:32.240 --> 00:18:36.559 fits with modern tech containers. First, Docker Podman. 394 00:18:36.279 --> 00:18:39.720 Yeah, Antsible integrates really well. There are dedicated modules like 395 00:18:39.759 --> 00:18:43.160 community at Docker, dot Docer container and containers dot Podman 396 00:18:43.240 --> 00:18:44.319 dot Podman containers. 397 00:18:44.319 --> 00:18:45.160 What can you do with them? 398 00:18:45.279 --> 00:18:48.559 Manage the whole container life cycle? Start stop, build images, 399 00:18:48.559 --> 00:18:53.720 create networks, volumes, run containers with specific commands. Basically anything 400 00:18:53.720 --> 00:18:56.440 you do with the Docker or Podman coli you can 401 00:18:56.480 --> 00:18:57.880