<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 Variables in a Terraform Configuration

Lesson Content

Getting Started with Terraform on SAP BTP

SAP_MOOC_terra1_unit4_lesson1_VARIA_Video.mp4

Welcome back to Unit 3, Enhancing the Terraform Configuration, Lesson 1, using variables in a Terraform configuration. When we look at our journey with Terraform, we now finish the first pillar and have prepared the basic setup. Now we continue with enhancing the Terraform configuration, and as a starter, we will introduce variables. Consequently, the learning objective of this lesson is explaining the concept of variables in Terraform and understanding how variables can make your Terraform scripts more flexible. In addition, we will also learn how variable values can be validated. To get started, how can we define variables in Terraform? Well, a variable in Terraform is defined by a variable block. You can see it down below in the slide. You see a variable called subaccount name, which is put into quotes, and then you can configure the variable first by using one of three basic types like string, number, or bool. There are also some more complex types like list maps and so on, but we will talk about those complex types later. Then you should also provide a description that explains what the variable is actually good for. Optionally, you can provide a default value in case it makes sense. So in essence, every variable can be defined that way. But I think, Christian, we can even do more in variables, except just setting up the type, the description, and the default value, right? Yeah, that's true. There is one more thing that's really important when it comes to defining variables, and that can help the consumers of your terraform code, namely validations for variables. On the slide, you see how to do that. Within the variable block, you have another keyword called validation. In the corresponding block, you define the rules that are applied when the variable is provided by the caller. The validation comprises the condition, which is the rule which is applied to the variable. If this condition fails or cannot be fulfilled, the error message is displayed to the caller. As you can see in the example, you can have multiple validations. In the condition of the first validation we see a regular expression for the subaccount name combined with Terraform functions. If we look at the second validation, the condition is based on a list of values that must be fulfilled. Besides that, there are also two more configuration options for variables that we did not explicitly point out. First one is, you can mark a variable as sensitive, which means that whenever this variable is shown within the terminal or in a CICD pipeline, it gets obfuscated, so you don't see its value. And the second one defines if a value is nullable, so if it can be provided with a null value or not. This configuration can be quite handy in some situations. Now, having said a lot about the theory of variables, I think we should make our hands dirty, right? Yeah, exactly. So we want to apply what we have just learned in something tangible to cover the use case of our target persona, for this course. What will we do? We will create a file which contains the definition of the variables, which is called variables.tf. And with that variable's definition, we will extract variables for our main.tf file and the provider tf file. We can make our code more versatile by using those variables to configure our script. Finally, we will as well add some basic validations via functions so that we can integrate some compliance rules for our target persona to set our infrastructure in SAP BTP subaccounts. So let's dive into it. Okay, so let's do the hands-on. As usual, everything is available in the GitHub repository and the main goal is to make our setup more flexible. So we want to introduce variables. We want to introduce some basic input variables for the configuration that we have defined. And, well, as we already laid out, there are a lot of parameters that we can add to these variables. But what we want to do now is really clean up the configuration that we have in place. Now, first thing first, what we did is we defined a provider configuration and there we hardcoded our global account value. That's kind of not very cool. So what we want to do now is we want to create a Variables.tf file. So you're just creating it here right now, Variables. Exactly. And now you will be adding the global account as a variable. Exactly. That's the idea. So I will now create this variable. And as you can see, there is a description that always makes sense to have some reasonable description so that call us know what does this variable mean. It's the subdomain of the global account. So we have to find that. And now we have to replace our hard-coded value via war.comal account. We can already see here if you have an extension installed. It already gives you a heads-up about the variables that you can use, right? Exactly. So that's super helpful. you have an extension installed, then a lot of type of mistakes might be prohibited that way. Now, what else do we want to have? We have in the main.tf a lot of hard-coded values that we want to replace now. So the subaccount name, the sub-domain, the region, the better enabled feature, the stage as well as the cost center. So let's take that code snippet and bring it into our variables .TF. Just copy and pacing it. Okay. And now you can see that for several variables, we have defined default values for the subaccount, sub-account name, and so on and so forth, which match the settings that we had before. Now, of course, we also have to exchange that in our setup. In our main tf file. Exactly. So within our Terraform configuration and as I don't want to make any typos, I copy the source from here and just replace it here. Now, as you can see, name, subdomain and so on have been replaced by variables. Nothing is hard-coded anymore. For the variables on subaccount level, we have reasonable default values, so nothing to provide. But we don't have a default value for the global account, right? So let's shortly check if we missed something. Ah, we need to provide values for the variables, right? So how can we do that? Within the documentation, We laid out several options how to do that. Now, what we will do is we will use the mechanism of a terraform.tfvars file. That's actually taken by terraform by default. If it finds a terraform.tfvars file, it knows, okay, I can look up here some variable values. That's right. So let's do the terraform .tfvars file. Let's put that into our directory and let's fill in the value and the one that is missing is the global account. Once again we have to replace that with our value for the subdomain. So we just add to the one that we have in our site right here. So meaning for you need to take the one of your trial account. Just copy and pasting it over here. Save. And, well, I would say... This should be everything. For everything else, we have already default values. Yep. So let's shortly go back to the ReadMe. Okay. So we have now introduced variables. We have replaced them within our configuration and we have provided a non-optional value. via the Terraform.tfvars files so that we can get it when we execute Terraform. Now, we discussed one more thing in this lesson, and that's validations. And as we said, the validation has two parameters or two attributes, condition and error message, and we want to validate a little bit of things that we have created. For example, as we are on the trial account, we want to validate the subaccount region. So I copy that once again, I switch here to the subaccount region, and replace it with the code. So as you can see, we still have the type, we still have a default value, but we now also have validation that the region must be one of the trial regions. So meaning, for example, if you would, in the Terraform.tfvars file, provide a region or the variable sub-account region with the value US11, it would actually throw up the error message we see here on line 24, right? Yep, yep, that would be the case. So anything else that we want to validate? Let's take the stage. Ah, the stage, yeah, that makes sense, right? So we don't want to have wild west stages there. We want to have well-defined stages. So we also add a validation here. and from the concept, it's the same as before. So we use the contains terraform function in order to say, hey, the sub-acom stage must be either dev, test or prod. Otherwise, throw the error message that is printed here. And then last but not least, what would be an IT course without regular expressions? We validate the project cost center with a regular expression. We want to be sure that the cost center is always a five digit number in our case right and only containing numbers correct so um now I think we really have everything in place and we can do our muscle memory exercise right um we checked first if everything is well formatted so let's do that looks good yeah then we validate If we made any error when typing in, you know it. Variables, you can mix up letters and so on. But that looks good. Now, we can do a Terraform plan, right? Yeah, and give it a name. Let's see what Terraform plan does. I mean, we didn't really change something, right? Exactly. So that's why it says nothing to do here. Nothing to do. We just replaced the variables, or we just replaced the hard-called values, with variables. Which is also now a sign for us that we didn't mess up anything on the updating of the variables, which is good. Exactly. So if you do that when going along and you have some changes here, well, then take a closer look at the variables that you brought into the game because there might be some mismatch. So nothing should change with this setup that we made here. And yeah, with that, I think we are done. with this exercise. Wonderful. As we are back from the hands-on, there are some tips that we want to mention. First of all, we recommend to create a separate file for the definition of the variables. We already applied this, but we want to explicitly stress it here. Terraform doesn't care how you name your files or how you distribute the content over different files, but if somebody else wants to collaborate with you, it makes sense to have a structure that follows the good practices. Second point is default values. They are quite tempting because they make the calling of the Terraform module easy. But be aware that default values make the variable optional. So only use default values if they really make sense in your setup. And finally, it's also important to think about defining fitting validations for each variable. That of course depends on the variable that you're using, but always think about this. from the perspective of the collar of your module and make their life easier when providing values for the variables. And with that, we are already at the end of this lesson, so we can do a wrap-up, right? Yeah, exactly. So, what are the key takeaways for this lesson? We saw that variables make the setup of your infrastructure much more flexible. So it's beneficial to define variables. And in addition, validations in the variables help you ensure that you set up your BTP infrastructure correctly. Everything is provisioned in a way which is compliant to the rules of your company. With that set, thank you very much and looking forward to see you in the next lesson. Bye-bye.