<p>about your learning experience to help us improve.</p>

You've completed

cleanFiles/bookmap_Getting_Started_with_Terraform_on_SAP_BTP_en-US_learning-sap-com_lsc-prod.zip (MMCP-DROPZONE) - 2025-02-18T09:44:29.000Z

Using Locals in a Terraform Configuration

Lesson Content

Getting Started with Terraform on SAP BTP

SAP_MOOC_terra1_unit4_lesson2_LOCALS_Video.mp4

Hello and welcome to Unit 3, Lesson 2, where we'll be using locals in a Terraform configuration. So as we see here in our journey, we will be enhancing the Terraform configuration we started in the previously lesson by using variables. And this time, we will be using so -called locals and see how to use them to achieve the goal of our persona. In this lesson, you will understand what locals are and how they can improve your configuration and make your code also more versatile. You will get also an impression on how to use locals to create your own values, maybe as a combination from different variables inside a Terraform configuration. And you will also learn how Terraform functions can be used with locals. Christian, can you explain please what locals are? Yeah, sure. From a terminology perspective, locals are short for local values. Technically that means that by defining a local value you assign a name to a Terraform expression. Transferring that to programming, locals are temporary local variables of a function. As we already mentioned, locals are super useful when you must use the same value or expression all over your configuration. And you don't want to copy and paste the code again and again, right? So, you want to make your code DRY. You don't want to repeat yourself. And locals are the perfect tool for that. In addition, and that's why functions were mentioned before, you can also use locals to transform or combine variables into new local values and then use them as attributes for your resources. Now, I would say enough theory. How does this look like in code, Rui? So, we can see here on the screen how such a locals block is defined. It starts with locals, and within this local block we see the definition of a variable called cost center, where a number has been assigned. And once you did that within your Terraform script, you can access this variable by using a dot structure where you would just write local dot and then the variable name. In this case, it's the cost center that we defined above. This is quite nice because you define these variables at the beginning of your script and then you can access them within your Terraform file. So, Christian, how can we use locals in our Terraform scripts now hands on? Yeah, right. Let us enhance our Terraform configuration a bit, introducing some locals to transform our variables and maybe even combine several variables into local. by using Terraform functions. Let's take a look at that. Okay, as usual, we are back in our GitHub repository for Unit 3, Lesson 2 in the Read Me MD and now here we see what we'll be doing with the locals in our Terraform configuration. And we start with understanding the local values how to use it. and maybe to see where we actually can apply the concept of locals in our setup. So we want to actually clean up the variables TF and remove the variables for subaccount, name, sub-domain and beta-enabled. And for that, Christian, we will be taking the project name first. Because we will actually combine now those three name subdomain and beta enabled. Exactly. So when we take a look at variables at the moment, what we see is we have quite some redundancy here, right? So we have the subaccount name, the subdomain, which is basically the same just following a different pattern, lower cases with dashes. And we also have what you mentioned, the subaccount beta enabled. Now probably we want to connect that to the subaccount stage, right? So if it's a prod, we don't want the better. For DEV, of course, we want. So we make again our variables TF also more better readable on the one-hand side and also have less code in there and rather put this into a naming convention into code, right? Yeah, exactly. So as we said before, it's all about who consumes that script, who is the caller? And the caller wants to give a project name. He doesn't really care about naming conventions, right? So let's do this. So let's do that. We add this new variable. called project name and we remove the subaccount name as well as the subaccount subdomain because we will construct that we will now also remove the beta enabled because we want to derive that at a later stage. Now as we have removed that of course the main.tf file immediately went red which is fair. Because something is now gone. So we have all subaccount name, subdomain and beta enabled is no longer available as variable. Yep. So we have to do something there to make things go again. So first things first, we introduce a local for the subaccount name. And as you can see, it's a locals block. So that's something that we now put into the main .tf file. At the very top, ideally. at the very top. And what we do is we use some template things. So we say, okay, we combine the subaccount stage and the project name into the subaccount name. But now you could ask, wait a second, if we have subaccount name defined, why does it show up still as an error on line 7? Exactly. That's because we still reference the variable, right? So what we have to do here is to enter local. Now, be aware, the block is called locals. And the reference is called local. Debatable if that makes sense, but that's how it is. So one red line less. So what do we have to do next? We created the... We want to create the subaccount domain, right? Yep. And the subaccount domain is something that needs to be unique, right? Yep. So maybe we should use another resource there. which is built into Terraform to create a UUID. So this resource is called random UUID, and we will now introduce that into our code. Let's put it at the very, very beginning. And now we have the random UUID. And here it follows the same approach, like having the resource name or the name of the resource random underscore UUID, and then again the address or the name of that, resource that we will use in the code, right? Yep. So with that, we will now do a bit more of magic. We will add a second local variable, which is the subaccount subdomain. Now here you can see, that's already quite extensive. Let's make it a bit easier. So, let's go from inside out. What we do is we combine the subaccount stage with the project name via dash. That's a new stream. Then there might be spaces within those names. And what we do is we replace those spaces with a dash. Once that is done, we want to have everything in lower letters. That's the lower function that we apply here. And then we want to join the UUID that we created. And that's that one here. So it's random UUID, that's the type, the address, and then the field that we want to have, the result. And join that with the string and a dash. Looks super complicated, but if you take a closer look, it's not that difficult to do that. With that, we have the subdomain in place, and let's replace that one end. Happy extension, we already can do that via type ahead. Last thing is now the stage topic. So what logic do we want to have? We want to have better enabled if it's not a prod account, right? Yep. So when you do programming, you would probably use a ternary expression, so to make it easy, so you don't want to have if then else. That makes no sense. So, and that's exactly what we do here. Let's copy the code for better. enabled. For better enabled, let's put it into our locals block. And there we see, now I won't intentionally intend it. Let's keep this, yeah. Let's keep it like that. And we say, okay, if the subaccount stage, the variable sub account stage says, I'm prod, then set the value of beta enabled to false, otherwise set it to true. So here we have to replace again. the variable for beta enabled to local dot beta enabled. And now all red curly lines are gone. That doesn't look to bad. Now, I guess we can continue with applying the changes. Let's do this. So... We introduced a new resource, so let's be safe. Yeah, first Terraform format. Let's first initialize it because we have this random UUID. Yeah, yeah. So that looks good. We also see that the random UUID is been uploaded as well or downloaded as well. Has been fetched, yeah. So that is good. Now let's do the Terraform FMT. To format. Let's see what happens. And it said, hey, I changed something in the main TF. And as you can see, beta enabled is now intended the right way. Now let's do a validation because, yeah, that makes sense. We did not make any mistakes, that's good. We did not make any mistakes, at least not static ones. Now let's shortly think what we did. We changed now several parameters to values that have not been there before, right? So the subdomain definitely changed because there we have a random UID. That was not there before. Yeah. So what would we expect that that happens now in the planning phase? So terraform plan out equals we are in lesson 3, unit 3. Unit 3, right? Yes. Let's shortly check to be consistent. Yep. And now. Let's do a terraform plan. Oh, what happens? Now something happened. And what we see is that the project sub -account must be replaced. And why is that the case? Well, because we changed the subdomain. And as you can see here from the plan, it's really easy to understand. We said, okay, subdomain is Dev Project ABC. This forces the replacement because we changed it. And we have one additional resource that will be created. Yeah. Because we create a UUID. So, yeah. That's something that we have to do now, right? Yeah, not doing a Terraform apply for Unit 3-2. And then things will happen. It will first destroy this up account. And that's why it's also important we learned before. When applying these changes, you really need to know what the implications are. That's why the Terraform plan is always important to look at, look at, so that you know what will be happening. because we will see now also once the changes are done, that the subaccount is first destroyed and then recreated. Exactly. Which has quite a big impact, right? This has quite some impact if you do that at a later stage where you have already resources in there. So what's also important now to stress is if you start with Terraform, it's something where you have to wrap your head around things like naming conventions, like how to structure things, a bit before you start and deploy to production. So because destroying a productive sub-account and then setting it up might not be a thing that you want to do. Specifically, if you have set up all kinds of service instances already with productive data inside, that's nothing you actually want to do, right? At the end of your development phase to change something so important like a sub-domain ID, right? Exactly. So now the apply is complete. So let's shortly check what is now in our state. Now we have indeed one more resource, such as the random UUID and our subaccount. And if we switch to the browser and go to our sub account, we have of course to reload the page to see the changes. We have again a new subaccount. And if we navigate into this subaccount, what we see is now the subdomain definitely looks different so we have this EU ID attached to it, better features are still enabled and the labels are the ones that we wanted to have. And I would say with that, we successfully introduced locals in our configuration. Now that we went through the hands-on exercise with you, some additional tips. Ideally, you should not distribute local blocks all over your configuration, so rather have one specific block maybe at the very beginning like we did in the hands-on session of your main TF file. Because if you start spreading these local blocks in your code, it will negatively affect the readability of your configuration because you don't know where to find which local. And you should as well not overdo the usage of locals. Just use it whenever a value or result is used in multiple places and is like to be changed, but you should apply the concept of locals in your Terraform scripts because that keeps also your configuration clean and crisp. Christian, how about our key takeaways now for this lesson? Well, as we saw, locals are one option to make your Terraform configuration DRY, don't repeat yourself, and avoid repetitive work and copy-pacing all over the place. In addition, what you have seen in our hands-on is that locals can be used to construct new values, for example to ensure naming conventions within your organization. So locals are a powerful tool, but don't overdo it. Always stick to the principle that your configuration should be easily readable and understandable. Use locals where it makes sense, but don't overdo it. And with that, we are at the end of this lesson. Thanks for watching and looking forward to seeing you in the next lesson. Bye.