WEBVTT 1 00:00:00.120 --> 00:00:03.000 Welcome to the Deep Dive, the show that's really your 2 00:00:03.160 --> 00:00:06.400 shortcut to being genuinely well informed. We try to pack 3 00:00:06.400 --> 00:00:09.400 it with surprising facts and you know, just enough humor 4 00:00:09.439 --> 00:00:10.199 to keep you hooked. 5 00:00:10.320 --> 00:00:11.199 Yeah. Absolutely. 6 00:00:11.800 --> 00:00:14.439 In today's IT world, it often feels like you're trying 7 00:00:14.439 --> 00:00:17.440 to build a castle while riding a roller coaster. I mean, 8 00:00:17.480 --> 00:00:20.519 things move so fast. Oh definitely, and staying on top 9 00:00:20.559 --> 00:00:23.239 of the tools that truly matter isn't just about keeping up. 10 00:00:23.239 --> 00:00:26.559 It's almost like gaining a superpower. We're talking about a 11 00:00:26.679 --> 00:00:29.559 fundamental shift in how we build and manage our digital 12 00:00:29.640 --> 00:00:32.799 environments infrastructure as code or IAC. 13 00:00:33.119 --> 00:00:36.679 That's right. Imagine defining your entire digital landscape, you know, 14 00:00:36.679 --> 00:00:40.759 from the smallest virtual machine to sprawling global networks, not 15 00:00:40.840 --> 00:00:45.479 through manual clicks and endless configurations, but as elegant, version 16 00:00:45.560 --> 00:00:46.439 controlled code. 17 00:00:46.560 --> 00:00:46.840 Right. 18 00:00:47.079 --> 00:00:51.399 This brings all the power of software development, things like consistency, repeatability, 19 00:00:51.920 --> 00:00:54.920 and automation directly to your infrastructure. 20 00:00:55.079 --> 00:00:58.479 And today you're getting a deep dive into one of 21 00:00:58.479 --> 00:01:03.560 the most powerful tools in that IAC, arsenal Terraform. We've 22 00:01:03.600 --> 00:01:06.560 gone through the brand new Terraform cookbook by Karamsaturli and 23 00:01:06.640 --> 00:01:10.640 Taylor Dolazol just published October twenty twenty four. Treating it 24 00:01:10.719 --> 00:01:14.959 like your personal distilled guide to mastering this incredible tool. 25 00:01:15.519 --> 00:01:19.680 Our mission to arm you with practical, actionable knowledge, cutting 26 00:01:19.680 --> 00:01:22.280 through all the complexity to give you the nuggets you 27 00:01:22.359 --> 00:01:24.319 need to be truly well informed. 28 00:01:24.519 --> 00:01:26.159 And by the end of this deep dive, you'll not 29 00:01:26.200 --> 00:01:29.280 only understand what terraform is, but maybe more importantly, when 30 00:01:29.319 --> 00:01:30.640 and why to actually. 31 00:01:30.400 --> 00:01:31.480 Use it exactly well. 32 00:01:31.480 --> 00:01:33.280 Break down its core building blocks, show you how to 33 00:01:33.280 --> 00:01:36.560 write top tier secure code, and even reveal how it's 34 00:01:36.640 --> 00:01:40.200 driving advanced real world deployments. Get ready for some genuine 35 00:01:40.359 --> 00:01:42.079 aha moments, I think. 36 00:01:41.959 --> 00:01:44.519 Okay, let's unpact this. Then, the book describes Terraform as 37 00:01:44.519 --> 00:01:47.640 an excellent declarative way to manage many things, But what 38 00:01:47.760 --> 00:01:50.799 does that truly mean in practice? Where does terraform really shine? 39 00:01:50.959 --> 00:01:54.879 Well, what's fascinating here is how Terraform becomes like the 40 00:01:54.920 --> 00:01:59.400 conductor for your digital orchestra. It truly excels when you're 41 00:01:59.439 --> 00:02:04.879 managing complex infrastructure made up of many interconnected resources. This 42 00:02:04.959 --> 00:02:09.039 becomes especially invaluable when your operations span multiple cloud providers 43 00:02:09.159 --> 00:02:13.240 think AWS and Azure together, or even integrate with your 44 00:02:13.240 --> 00:02:14.360 on premises. 45 00:02:14.000 --> 00:02:16.080 Environments, right, the hybrid stuff. 46 00:02:15.879 --> 00:02:21.240 Exactly, think about managing multiple environments, dev staging production across 47 00:02:21.280 --> 00:02:25.240 different vendors. Terraform offers a single unified language for all 48 00:02:25.280 --> 00:02:28.199 of that, simplifying what used to be, frankly a nightmare 49 00:02:28.199 --> 00:02:29.719 of different tools and manual steps. 50 00:02:29.919 --> 00:02:33.479 That makes perfect sense for those big distributed, multi vendor systems, 51 00:02:34.159 --> 00:02:38.240 But in my experience, no single tool is a silver bullet. 52 00:02:38.680 --> 00:02:41.759 Are there scenarios where Terraform might be overkill or maybe 53 00:02:41.800 --> 00:02:42.960 even the wrong choice. 54 00:02:43.159 --> 00:02:45.560 Yeah, that's a really important question. You don't always need 55 00:02:45.560 --> 00:02:48.199 a sledgehammer to crack a nut, right. For instance, if 56 00:02:48.240 --> 00:02:51.960 you're only managing a single server, maybe simpler configuration management 57 00:02:52.000 --> 00:02:55.280 tools like ansable or Puppet might be far more straightforward, 58 00:02:55.719 --> 00:02:59.360 easier learning curve too. Similarly, if you're sticking to just 59 00:02:59.439 --> 00:03:03.599 one cloud, say only AWS for a relatively small amount 60 00:03:03.639 --> 00:03:08.639 of infrastructure, they're native tools like AWS Cloud Formation or 61 00:03:08.719 --> 00:03:12.039 Azure Resource Manager if you're on Azure, could absolutely suffice 62 00:03:12.159 --> 00:03:16.280 the integrate really seamlessly. And here's a common one. If 63 00:03:16.319 --> 00:03:20.080 you're heavily using platform as a service or plause solutions 64 00:03:20.080 --> 00:03:23.719 like Netlafi or Google App Engine, the underlying infrastructure is 65 00:03:23.759 --> 00:03:27.680 often managed for you, so Terraform becomes unnecessary for that 66 00:03:27.719 --> 00:03:28.560 specific layer. 67 00:03:28.879 --> 00:03:32.840 Those are crucial distinctions picking the right tool for the job. Now, 68 00:03:32.879 --> 00:03:35.400 before we go too deep into the technical bits, we 69 00:03:35.520 --> 00:03:37.479 kind of have to address something that sparked quite a 70 00:03:37.479 --> 00:03:40.960 bit of discussion in the community recently, Terraform's license change. 71 00:03:41.120 --> 00:03:44.400 Ah. Yes, the license change. In August twenty twenty three, 72 00:03:44.520 --> 00:03:48.719 Hashikorp shifted Terraform's license from the Mozilla Public License the NPL, 73 00:03:49.000 --> 00:03:52.520 to the Business Source License or BSL. This change definitely 74 00:03:52.599 --> 00:03:56.080 led to significant community discussion and importantly the creation of 75 00:03:56.120 --> 00:03:59.080 open tofu. That's an open source fork that remains under 76 00:03:59.120 --> 00:03:59.960 the NPL license. 77 00:04:00.240 --> 00:04:02.840 Okay, so there's an alternative exactly now. 78 00:04:02.879 --> 00:04:06.120 While the Terraform cookbook in therefore are deep dive today 79 00:04:06.639 --> 00:04:09.919 focuses on Hashi Kor's Terraform, it's important to note that 80 00:04:10.000 --> 00:04:13.360 the examples in core concepts were discussing they work pretty 81 00:04:13.400 --> 00:04:16.040 much seamlessly with open tofu as well. Good to know 82 00:04:16.279 --> 00:04:18.240 the main difference you'd see is just the commands you 83 00:04:18.279 --> 00:04:23.480 taught terraform versus tofu. For clarity today, though, we'll stick 84 00:04:23.519 --> 00:04:25.720 to the core Terraform concepts as they're laid out in 85 00:04:25.759 --> 00:04:26.079 the book. 86 00:04:26.279 --> 00:04:30.000 Okay, sounds good. With that important groundwork laid, let's move 87 00:04:30.040 --> 00:04:34.680 into the core building blocks of Terraform. First up providers. 88 00:04:35.160 --> 00:04:38.480 How exactly do these let Terraform connect to and control 89 00:04:38.839 --> 00:04:39.560 the real world? 90 00:04:39.920 --> 00:04:43.040 Right? Providers imagine Terraform needs to talk to aws or 91 00:04:43.079 --> 00:04:46.040 Kubernetes or even GitHub. Doesn't just inherently know how to 92 00:04:46.079 --> 00:04:48.360 do that. Okay, that's where providers come in. They're like 93 00:04:48.360 --> 00:04:53.040 specialized translators, enabling Terraform to speak the specific API language 94 00:04:53.040 --> 00:04:53.720 of each service. 95 00:04:53.800 --> 00:04:54.519 Ah, got it. 96 00:04:54.720 --> 00:04:57.759 This lets you create, read, update, or delete resources in 97 00:04:57.800 --> 00:05:01.879 their environment, but using a consistent Terraform syntax across the board. 98 00:05:02.160 --> 00:05:06.040 So they're the communication layer speaking all those different infrastructure dialects. 99 00:05:06.360 --> 00:05:09.800 And I've heard managing different versions of these providers can 100 00:05:09.839 --> 00:05:13.560 be a bit tricky. You want updates, but you fear 101 00:05:13.639 --> 00:05:16.800 breaking changes. Is there a simple rule of thumb there? 102 00:05:17.240 --> 00:05:19.680 You're absolutely right to bring that up. It's crucial. You 103 00:05:19.759 --> 00:05:24.199 need to specify version constraints for your providers, something like 104 00:05:24.240 --> 00:05:25.040 five point zero. 105 00:05:24.879 --> 00:05:27.079 In your configuration, the tilled greater then. 106 00:05:27.439 --> 00:05:32.240 Exactly the pessimistic version constraint. This prevents unexpected or accidental 107 00:05:32.319 --> 00:05:35.360 upgrades to a new major version that could introduce breaking 108 00:05:35.439 --> 00:05:38.040 changes to your infrastructure. Okay, but it still allows for 109 00:05:38.120 --> 00:05:41.639 bug fixes and minor updates within that major version, keeping 110 00:05:41.639 --> 00:05:44.720 your deployment stable and predictable without fear of a sudden 111 00:05:44.759 --> 00:05:47.079 chaotic change breaking everything makes sense. 112 00:05:47.319 --> 00:05:50.160 Keep things stable that still get fixes. Okay. Next up, 113 00:05:50.199 --> 00:05:52.560 let's talk about Terraform modules. I hear these are all 114 00:05:52.600 --> 00:05:55.279 about reusability, But what exactly are they and how do 115 00:05:55.319 --> 00:05:56.279 they make life easier? 116 00:05:56.360 --> 00:05:59.600 Okay? Modules. If we think of Terraform as a programming 117 00:05:59.639 --> 00:06:03.319 language for infrastructure, then modules are kind of like functions 118 00:06:03.399 --> 00:06:06.560 or subroutines in traditional code. They encapsulate a block of 119 00:06:06.680 --> 00:06:09.720 Terraform code with a specific purpose, and they're designed to 120 00:06:09.759 --> 00:06:13.879 be reusable. The primary benefit modules help you organize your 121 00:06:13.920 --> 00:06:17.240 resources and reuse code, which is vital for consistency and 122 00:06:17.240 --> 00:06:19.720 managing complexity as your infrastructure grows. 123 00:06:19.920 --> 00:06:22.959 Okay, So you can define a standard way to deploy, 124 00:06:23.240 --> 00:06:25.040 say a web server setup. 125 00:06:24.800 --> 00:06:28.040 Exactly, and then you just reuse that module across different 126 00:06:28.040 --> 00:06:31.639 projects or environments instead of copying and pasting code everywhere. 127 00:06:31.720 --> 00:06:34.720 That's a fantastic analogy. So instead of writing the same 128 00:06:34.759 --> 00:06:36.680 block of code over and over, you just create a 129 00:06:36.759 --> 00:06:39.600 module once and I hear there are public modules available 130 00:06:39.680 --> 00:06:40.839 that can save even more time. 131 00:06:40.920 --> 00:06:44.199 Oh definitely. A great example of the book highlights is 132 00:06:44.279 --> 00:06:48.800 using the public AWS EKS module that's available on the Terraform. 133 00:06:48.439 --> 00:06:51.680 Registry EKS the Kubernetes service on AWS. 134 00:06:51.920 --> 00:06:54.879 Right, with just a few lines of code calling that module, 135 00:06:55.160 --> 00:06:58.800 you can provision a fully configured Kubernetes cluster. This not 136 00:06:58.839 --> 00:07:01.519 only saves you immense time, but also ensures that you're 137 00:07:01.560 --> 00:07:06.120 automatically applying best practices and configurations that have been battle 138 00:07:06.160 --> 00:07:09.800 tested by the community. And when you create your own module, 139 00:07:10.040 --> 00:07:13.079 it typically includes a main dot TF file for the 140 00:07:13.120 --> 00:07:16.720 actual resources variables, dot TF for flexible inputs so people 141 00:07:16.759 --> 00:07:21.360 can customize it outputs, dot TF for values the module returns, 142 00:07:21.800 --> 00:07:26.959 and crucially, a reme dot MD for documentation. Got to 143 00:07:27.000 --> 00:07:30.680 have that documentation, absolutely, That documentation is key so others 144 00:07:30.720 --> 00:07:32.720 know how to use it. Okay, that sounds like a 145 00:07:32.720 --> 00:07:37.199 lifesaver for boostrapping complex infrastructure. Speaking of what Terraform knows 146 00:07:37.240 --> 00:07:39.839 about your infrastructure, let's talk about the state file. What 147 00:07:40.040 --> 00:07:42.720 is it and why is remote state such a big 148 00:07:42.759 --> 00:07:44.319 deal especially for teams. 149 00:07:44.639 --> 00:07:47.800 Right, the state file, it's essentially terraforms memory it's the 150 00:07:47.879 --> 00:07:50.879 master record of every piece of infrastructure it's responsible for 151 00:07:50.959 --> 00:07:53.959 in the real world. Okay, it tracks the exact attributes 152 00:07:53.959 --> 00:07:58.160 and relationships of all your deployed resources. Now, for team environments, 153 00:07:58.240 --> 00:08:01.279 storing this state remotely, not on laptop is a critical 154 00:08:01.319 --> 00:08:02.160 best practice. 155 00:08:02.240 --> 00:08:02.759 Why is that? 156 00:08:03.360 --> 00:08:06.199 Well, First, it ensures the state is centralized and accessible 157 00:08:06.199 --> 00:08:09.439 from anywhere. This prevents conflicts when multiple team members are 158 00:08:09.480 --> 00:08:12.040 working on the same infrastructure. You don't want two people 159 00:08:12.120 --> 00:08:15.920 applying changes based on different versions of the state. Ah yeah, 160 00:08:16.000 --> 00:08:17.160 that sounds bad. It is. 161 00:08:17.480 --> 00:08:20.360 And what's maybe even more important is the security aspect. 162 00:08:20.759 --> 00:08:25.360 Remote state provides additional security by keeping potentially sensitive information 163 00:08:25.439 --> 00:08:28.680 out of your version control systems like GET where it 164 00:08:28.759 --> 00:08:31.160 might otherwise inadvertently end up in plain text. 165 00:08:31.480 --> 00:08:34.200 So it's not just about collaboration, but a vital security 166 00:08:34.200 --> 00:08:37.120 measure too. Okay, what are some of the popular options 167 00:08:37.120 --> 00:08:39.240 for these remote back ends? Then? Where do you store 168 00:08:39.279 --> 00:08:39.720 this state? 169 00:08:40.240 --> 00:08:43.440 Popular remote back ends include Hashi Coore's own managed service 170 00:08:43.600 --> 00:08:48.159 HGP Terraform. There are also robust cloud storage solutions like 171 00:08:48.200 --> 00:08:53.240 Amazon S three for AWS, Google Cloud Storage, Azure blob storage, 172 00:08:53.480 --> 00:08:55.679 or even a self hosted option like the console key 173 00:08:55.720 --> 00:08:58.639 Value store lots of choices. Yeah, plenty of options depending 174 00:08:58.679 --> 00:09:00.960 on your setup. And for those those moments when you 175 00:09:01.039 --> 00:09:04.039 need to quickly peek into or debug your state without 176 00:09:04.039 --> 00:09:07.279 applying changes, the terraform console command is incredibly powerful. 177 00:09:07.679 --> 00:09:08.200 What does that do? 178 00:09:08.600 --> 00:09:11.240 It lets you introspect your terraform state in real time. 179 00:09:11.639 --> 00:09:14.919 You can type in expressions, look at resource attributes, all 180 00:09:14.960 --> 00:09:19.159 without modifying your actual configuration files. It's perfect for rapid 181 00:09:19.200 --> 00:09:22.279 experimentation and just understanding the current values of things. 182 00:09:22.360 --> 00:09:26.120 That's a true aha moment right there. Interactive state inspection 183 00:09:26.200 --> 00:09:29.919 without touching your config Okay, Now let's move into crafting 184 00:09:30.000 --> 00:09:33.960 quality and secure code. What are the first fundamental steps 185 00:09:34.039 --> 00:09:37.720 for basic code hygiene? What should everyone be doing right? 186 00:09:37.879 --> 00:09:42.000 Every good code base infrastructure code included begins with cleanliness 187 00:09:42.000 --> 00:09:47.279 and correctness. First up is Terraform FMT. It's your automatic formatting. 188 00:09:46.840 --> 00:09:49.080 Tool FMT for format exactly. 189 00:09:49.279 --> 00:09:52.440 It automatically formats your code to the recommended style guidelines. 190 00:09:52.480 --> 00:09:54.559 Makes it easier to read and maintain for everyone on 191 00:09:54.600 --> 00:09:56.679 your team. Consistent style helps a lot. 192 00:09:56.840 --> 00:09:58.080 Okay, so that's readability. 193 00:09:58.600 --> 00:10:02.000 Then there's terraform validate. This checks for syntax and semantics. 194 00:10:02.200 --> 00:10:06.320 It catches things like syntax errors, missing required arguments for resource, 195 00:10:06.679 --> 00:10:10.879 incorrect references between resources. The basic structural. 196 00:10:10.399 --> 00:10:11.559 Stuff seems essential. 197 00:10:11.679 --> 00:10:15.320 It is, but here's a crucial point. You must run 198 00:10:15.399 --> 00:10:19.279 terraform in it first. Why is that because validation requires 199 00:10:19.360 --> 00:10:22.639 terraform to download and understand the providers you're using. It 200 00:10:22.679 --> 00:10:25.840 needs that provider context to know what arguments are valid for, 201 00:10:25.919 --> 00:10:29.519 say an AWRS instance. Without in it, it can't truly 202 00:10:29.600 --> 00:10:30.919 validate your code properly. 203 00:10:30.960 --> 00:10:35.200 Got it in it first, then validate. So FMT is 204 00:10:35.240 --> 00:10:39.840 about readability, validate is about basic correctness, But what about 205 00:10:40.039 --> 00:10:43.759 deeper issues like potential security flaws or maybe just not 206 00:10:43.919 --> 00:10:47.480 following best practices. That sounds like where linters and security 207 00:10:47.519 --> 00:10:48.200 scanners come in. 208 00:10:48.320 --> 00:10:51.480 Absolutely, you've got the basics covered with FMT and validate, 209 00:10:51.759 --> 00:10:54.159 but you need to go further. Tools like t flint, 210 00:10:54.200 --> 00:10:57.120 which is a popular third party linting tool, catch issues 211 00:10:57.200 --> 00:11:01.320 terraform validate might miss entirely, like what like unused variables 212 00:11:01.360 --> 00:11:05.519 cluttering your code, duplicate resource definitions, maybe incorrect resource properties 213 00:11:05.559 --> 00:11:09.679 that aren't technically syntax errors but are just wrong. And importantly, 214 00:11:09.799 --> 00:11:13.519 it can even flag potential security risks like overly permissive 215 00:11:13.559 --> 00:11:14.799 security group rules. 216 00:11:14.919 --> 00:11:16.399 Okay, so it's smarter than validate. 217 00:11:16.639 --> 00:11:19.720 Yeah, it has more checks, more opinions based on common practices. 218 00:11:20.279 --> 00:11:24.480 Then there's TSSEC, another excellent third party security scanner. This 219 00:11:24.519 --> 00:11:29.399 one specifically focuses on identifying insecure patterns, misconfigurations, and non 220 00:11:29.440 --> 00:11:33.440 compliant settings in your terraform code. Mean example, Sure, it 221 00:11:33.480 --> 00:11:36.480 can warn you about things like unencrypted s three buckets 222 00:11:36.840 --> 00:11:39.679 or security groups with ingress rules that are way too 223 00:11:39.720 --> 00:11:43.080 broad like allowing access from anywhere on the Internet. You 224 00:11:43.080 --> 00:11:46.200 can even tell tfsec to ignore specific checks if you 225 00:11:46.279 --> 00:11:49.840 have a documented, justified reason using an inline comment like 226 00:11:50.080 --> 00:11:51.799 hashtag tfsec dot ignore. 227 00:11:51.720 --> 00:11:54.360 Ah, so you can overwrite it if needed. That's handy. 228 00:11:54.840 --> 00:11:58.080 So these tools act like extra sets of vigilant eyes, 229 00:11:58.320 --> 00:12:01.120 scrutinizing your code before you even think about deploying. How 230 00:12:01.159 --> 00:12:03.919 do we move from just checking code to actually enforcing 231 00:12:03.960 --> 00:12:07.440 policies and compliance across our infrastructure deployments like preventing bad 232 00:12:07.480 --> 00:12:08.240 things from happening? 233 00:12:08.320 --> 00:12:11.440 Right enforcement. This is where policy is code really shines, 234 00:12:11.600 --> 00:12:14.919 often leveraging tools like Open Policy Agent or OPA. Yeah, 235 00:12:15.000 --> 00:12:18.240 open Policy Agent, it's a general purpose policy engine within 236 00:12:18.320 --> 00:12:22.080 terraform itself. You can define preconditions using validation blocks inside 237 00:12:22.080 --> 00:12:25.840 your variable definitions. This ensures that specific conditions are met 238 00:12:25.840 --> 00:12:27.840 before terraform even attempts to apply. 239 00:12:27.679 --> 00:12:29.159 Changes, like what kind of condition. 240 00:12:29.720 --> 00:12:32.919 For example, you could enforce that an instance type variable 241 00:12:33.000 --> 00:12:35.799 must be either T two dot micro or T two 242 00:12:35.840 --> 00:12:39.600 dot small and nothing else. Terraform checks this before planning 243 00:12:40.159 --> 00:12:43.080 post conditions. On the other hand, verify the state after 244 00:12:43.120 --> 00:12:45.039 a resource is created or updated. 245 00:12:45.120 --> 00:12:46.399 Okay, and opa. 246 00:12:46.399 --> 00:12:49.080 OPA takes it a step further. It lets you write 247 00:12:49.200 --> 00:12:52.519 much more complex policies as code. You could restrict allowed 248 00:12:52.519 --> 00:12:56.039 EC two instance types across your whole organization, or enforce 249 00:12:56.120 --> 00:12:59.120 that all EACY two instances must have a specific name 250 00:12:59.200 --> 00:13:02.720 tag powerful. And what's truly powerful is that OPIA can 251 00:13:02.720 --> 00:13:06.120 be integrated directly into your CICD pipelines. This means it 252 00:13:06.120 --> 00:13:09.120 can check your terraform plan and prevent non compliant changes 253 00:13:09.159 --> 00:13:11.679 from ever being applied to your production environment automatically. 254 00:13:11.960 --> 00:13:16.200 That's incredibly powerful, preventing bad configurations from ever reaching production 255 00:13:16.720 --> 00:13:20.240 like a gatekeeper. And what about keeping our documentation up 256 00:13:20.240 --> 00:13:23.399 to date or our provider versions. That sounds like a 257 00:13:23.440 --> 00:13:26.360 lot of manual, painstaking work without automation. 258 00:13:26.600 --> 00:13:29.600 It used to be, but not anymore. There are great tools. 259 00:13:29.639 --> 00:13:34.360 Now for docs, there's Terraform Docs. It automatically generates documentation 260 00:13:34.440 --> 00:13:40.240 for your modules, detailing inputs, outputs, providers, resources, everything automatically. Yep. 261 00:13:40.519 --> 00:13:43.159 You can integrate this into get pre commit hooks or 262 00:13:43.200 --> 00:13:47.000 your CICD pipeline to ensure your documentation is always fresh 263 00:13:47.039 --> 00:13:49.960 and reflects the actual code. No more stale. 264 00:13:49.720 --> 00:13:52.960 Read mase nice and providers for. 265 00:13:52.960 --> 00:13:56.360 Keeping your provider versions current githubs. De pendabot is fantastic 266 00:13:56.679 --> 00:14:00.200 could automatically create poll requests to update your Terraform provider version, 267 00:14:00.639 --> 00:14:03.559 ensuring you leverage the latest available features and bug fixes, 268 00:14:03.919 --> 00:14:06.200 all within the version constraints you specified earlier. 269 00:14:06.360 --> 00:14:08.679 Ah, so it respects the five point zero kind of 270 00:14:08.679 --> 00:14:09.480 thing exactly. 271 00:14:09.600 --> 00:14:12.240 It automates the mundane but important task of staying up 272 00:14:12.279 --> 00:14:15.000 to date safely. It's all about automating these chores so 273 00:14:15.039 --> 00:14:17.840 your team can focus on the truly critical and innovative work. 274 00:14:18.120 --> 00:14:22.159 That's brilliant. And speaking of consistency and automation, how can 275 00:14:22.200 --> 00:14:25.559 teams ensure everyone is working with the exact same development 276 00:14:25.639 --> 00:14:28.360 setup you know to solve that dreaded well, it works 277 00:14:28.360 --> 00:14:30.399 on my machine problem exactly. 278 00:14:31.080 --> 00:14:35.360 That phrase is the bane of many developers' existence. This 279 00:14:35.440 --> 00:14:38.360 is where tools like getub code spaces and dev containers 280 00:14:38.440 --> 00:14:41.240 are absolute game changers. How do they help They provide 281 00:14:41.240 --> 00:14:45.679 a consistent, pre configured development environment defining code. This ensures 282 00:14:45.720 --> 00:14:48.559 all contributors have the exact same tool set, the same 283 00:14:48.679 --> 00:14:53.240 Terraform version, same lenters, the same helper scripts, everything, regardless 284 00:14:53.240 --> 00:14:57.360 of their local machine setup, whether they're on Mac, Windows, Linux. 285 00:14:56.960 --> 00:14:59.279 So everyone's using the same environment precisely. 286 00:15:00.000 --> 00:15:03.639 This significantly reduces those frustrating it works on my machine issues. 287 00:15:03.919 --> 00:15:07.279 By standardizing the development environment across your entire team, it's 288 00:15:07.360 --> 00:15:10.000 like everyone getting the same perfectly pre tuned race car 289 00:15:10.080 --> 00:15:13.200 before they even hit the track. Makes collaboration much smoother. 290 00:15:13.480 --> 00:15:16.480 Okay, we've covered the why, the when, the core blocks, 291 00:15:16.519 --> 00:15:20.240 and keeping code clean. Now let's dive deeper and master 292 00:15:20.399 --> 00:15:25.840 terraforms language itself, starting with something practical. Cleaning up messy 293 00:15:26.000 --> 00:15:29.600 user inputs. You know, those annoying extra spaces or maybe 294 00:15:29.679 --> 00:15:32.919 unwanted prefixes that can throw off an entire deployment if 295 00:15:32.960 --> 00:15:33.679 you're not careful. 296 00:15:33.799 --> 00:15:36.120 Yeah, this is really common practical challenge you hit pretty 297 00:15:36.200 --> 00:15:40.279 quickly in real world configurations. Terraform offers functions for this 298 00:15:40.759 --> 00:15:43.799 there's trim space, which neatly removes leading and trailing spaces 299 00:15:43.799 --> 00:15:45.399 and new lines from a strength. 300 00:15:45.799 --> 00:15:49.759 Very handy, okay, simple enough? What about prefixes or suffixes? 301 00:15:50.000 --> 00:15:53.279 For removing specific prefixes and suffixes, you can achieve this 302 00:15:53.399 --> 00:15:56.720 by intelligently using the replaced function. You basically tell it 303 00:15:56.720 --> 00:15:58.840 to replace the unwanted part of the string with an 304 00:15:58.879 --> 00:16:02.840 empty string. It allows for much cleaner and more predictable data, 305 00:16:03.000 --> 00:16:04.759 preventing subtle errors downstream. 306 00:16:05.279 --> 00:16:08.759 That's super useful. Little cleanup functions save a lot of headaches, 307 00:16:08.799 --> 00:16:11.879 and sometimes you need more sophistic kid. String manipulation like 308 00:16:11.960 --> 00:16:15.759 pattern matching, does Terraform handle regular expressions rajex? 309 00:16:15.879 --> 00:16:19.840 It absolutely does. Terraform supports functions like rejex rejects all, 310 00:16:20.200 --> 00:16:22.519 and you can use rejects within the replace function two 311 00:16:22.840 --> 00:16:25.519 for powerful pattern matching and string manipulation. 312 00:16:26.039 --> 00:16:28.399 Can you give an example, sure, think of a vivid one. 313 00:16:29.200 --> 00:16:32.080 You could use a regular expression with replace to mass 314 00:16:32.159 --> 00:16:35.840 sensitive data like a social security number, preserving only the 315 00:16:35.919 --> 00:16:39.600 last four digits while replacing the rest with excess. That's 316 00:16:39.639 --> 00:16:42.840 a common security and data handling requirement you can implement 317 00:16:43.000 --> 00:16:44.080 right in Terraform. 318 00:16:44.159 --> 00:16:47.679 Very cool, okay, and what about just standardizing string inputs, 319 00:16:47.679 --> 00:16:50.840 like for naming conventions, maybe you need everything lowercase or 320 00:16:51.000 --> 00:16:52.399 maybe title case for tags. 321 00:16:52.679 --> 00:16:56.399 Terraform has you covered there too. Simple functions title upper 322 00:16:56.480 --> 00:16:59.799 and lower They help standardized string inputs, which is particularly 323 00:17:00.159 --> 00:17:04.079 ful for maintaining consistent naming conventions across your resources, or 324 00:17:04.119 --> 00:17:07.000 when you're integrating with external systems that might have case 325 00:17:07.039 --> 00:17:10.759 sensitive requirements. Easy enough it is. It's important to note, though, 326 00:17:10.759 --> 00:17:14.119 that their primary focus is on English text, so complex 327 00:17:14.240 --> 00:17:17.480 unicode casing might behave differently good caveat. 328 00:17:17.799 --> 00:17:20.440 Okay, so we're talking about making our code more robust. 329 00:17:21.119 --> 00:17:25.759 What about handling potential errors gracefully when data might be 330 00:17:25.799 --> 00:17:29.880 missing or maybe in an unexpected format That happens surprisingly 331 00:17:29.920 --> 00:17:31.200 often in complex systems. 332 00:17:31.279 --> 00:17:33.640 Right, oh all the time. This is where they can 333 00:17:33.680 --> 00:17:37.039 and try functions become incredibly valuable. They allow you to 334 00:17:37.039 --> 00:17:40.519 handle potential errors gracefully during terraforms processing. How do they 335 00:17:40.559 --> 00:17:42.640 work well? For I? Lets you attempt a series of 336 00:17:42.680 --> 00:17:45.000 expressions and returns the results of the first one that 337 00:17:45.079 --> 00:17:47.920 doesn't err. You can provide a final default value if 338 00:17:47.920 --> 00:17:52.319 all attempts fail. Can simply checks if an expression would 339 00:17:52.319 --> 00:17:55.000 succeed without actually returning its value just gives you a 340 00:17:55.039 --> 00:17:57.400 tru or false AH, so you can use these to 341 00:17:57.440 --> 00:18:00.480 provide default values when necessary, or to check if an 342 00:18:00.480 --> 00:18:04.079 optional attribute exists before trying to access it. This leads 343 00:18:04.079 --> 00:18:07.559 to much more robust and resilient configurations that won't just 344 00:18:07.640 --> 00:18:10.440 crash and burn if a piece of data isn't exactly 345 00:18:10.440 --> 00:18:13.359 where you expected to be, make sure deployment's far more reliable. 346 00:18:13.559 --> 00:18:17.079 That's a definite game changer for building reliable infrastructure in 347 00:18:17.119 --> 00:18:22.000 the real world. Okay, shifting gears to networks, especially in 348 00:18:22.119 --> 00:18:26.599 vast cloud environments, precise calculations for dividing up IP address 349 00:18:26.640 --> 00:18:31.680 blocks CIDR blocks into smaller subnets are absolutely essential and 350 00:18:31.799 --> 00:18:36.000 kind of fiddly to do manually. Does Terrorform simplify that complexity. 351 00:18:36.079 --> 00:18:39.680 It does beautifully with the sid subnet function. This function 352 00:18:39.799 --> 00:18:44.160 allows for precise, repeatable calculations to divide a large CIDR 353 00:18:44.200 --> 00:18:45.720 block into smaller. 354 00:18:45.400 --> 00:18:48.440 Subnets, like taking a big block and slicing. 355 00:18:48.000 --> 00:18:51.720 It exactly, for instance, breaking a sixteen network address block 356 00:18:51.960 --> 00:18:55.799 into multiple twenty four subnets for different purposes. It automates 357 00:18:55.799 --> 00:18:59.759 in scales network design, eliminating manual calculation errors and ensuring 358 00:18:59.759 --> 00:19:02.720 a fit ip address utilization. It's like having a perfectly 359 00:19:02.759 --> 00:19:04.920 precise digital slicer for your network. 360 00:19:04.960 --> 00:19:07.759 Cake nice analogy, so it's like slicing a big network 361 00:19:07.799 --> 00:19:11.960 into perfect smaller pieces. Very neat. What about conditional logic? 362 00:19:12.279 --> 00:19:15.119 Creating resources only when certain conditions are met, or maybe 363 00:19:15.160 --> 00:19:17.200 processing a list of data in a specific order. 364 00:19:17.319 --> 00:19:20.759 Terraform handles conditional logic primarily using the count meta argument. 365 00:19:20.839 --> 00:19:22.599 It's a bit of a classic terraform pattern. 366 00:19:22.680 --> 00:19:24.279 How does count work for conditions? 367 00:19:24.920 --> 00:19:28.440 You set count based on a boolean expression, for example, 368 00:19:28.640 --> 00:19:32.039 count var dot create and instance spitting one bin and zero. 369 00:19:32.480 --> 00:19:35.279 This means terraform will create one instance of the resource 370 00:19:35.519 --> 00:19:38.480 if the variablevar dot create an instance is true, and 371 00:19:38.680 --> 00:19:42.119 zero instances if it's false, effectively turning the resource on 372 00:19:42.319 --> 00:19:42.680 or off. 373 00:19:42.880 --> 00:19:45.440 Simple on off switch. What about processing lists? 374 00:19:45.920 --> 00:19:49.880 For sequential processing, especially when iterating over lists or maps, 375 00:19:50.200 --> 00:19:53.519 you often use count in conjunction with its index. Count 376 00:19:53.519 --> 00:19:56.880 dot index gives you the current iteration number zero, one, two. 377 00:19:57.480 --> 00:20:01.119 This is incredibly useful for resources that have index based dependencies, 378 00:20:01.480 --> 00:20:04.480 like creating a series of numbered subnets, or maybe assigning 379 00:20:04.519 --> 00:20:07.359 im roles sequentially for a set of applications based on 380 00:20:07.400 --> 00:20:07.759 a list. 381 00:20:07.799 --> 00:20:10.359 Okay, so count is quite versatile. That's a deep dive 382 00:20:10.400 --> 00:20:14.319 into the language itself. What about dynamically generating configuration files 383 00:20:14.319 --> 00:20:17.480 on the fly, or even consuming external data like from 384 00:20:17.519 --> 00:20:20.480 an API and using that to influence your infrastructure. 385 00:20:19.920 --> 00:20:24.359 Build This is where Terraform gets truly flexible and powerful. 386 00:20:24.400 --> 00:20:27.240 Connecting to the outside world. You can use the template 387 00:20:27.319 --> 00:20:29.920 file data source. Well that's the older way. Now it's 388 00:20:30.000 --> 00:20:32.759 usually the template file function to generate configuration files or 389 00:20:32.759 --> 00:20:35.799 scripts dynamically based on input variables. 390 00:20:35.519 --> 00:20:37.000 Like generating a custom. 391 00:20:36.680 --> 00:20:39.960 Script exactly like producing a customized Bash script or a 392 00:20:40.000 --> 00:20:43.319 configuration file for an application on the fly, injecting values 393 00:20:43.359 --> 00:20:45.839 from your Terraform variables right into the template. 394 00:20:45.559 --> 00:20:47.039 Cool and external data. 395 00:20:47.119 --> 00:20:50.559 For integrating external data, the HTTP data source is really useful. 396 00:20:50.599 --> 00:20:53.319 It allows you to fetch data from an external API 397 00:20:53.799 --> 00:20:58.039 endpoint maybe ipminfo dot io to get your build agent's public. 398 00:20:57.799 --> 00:20:59.960 IP address, for example, and then use that data. 399 00:21:00.160 --> 00:21:03.480 Yep. You can then use that fetched information directly within 400 00:21:03.519 --> 00:21:08.200 your Terraform configuration, perhaps to configure a security group rule dynamically. 401 00:21:08.680 --> 00:21:12.440