Input variables - Terraform Tutorial

- [Instructor] Input variables are used to generalize a configuration so that it can be used in a variety of scenarios. Terraform supports variables of several types, including a string, numerical values, a bool or boolean, lists and maps. We'll focus on strings and booleans for now. Go ahead and switch back over to Visual Studio Code. And before we switch branches, let's take a look at the main.tf file. All the values in these stanzas are hard coded including the project name, the region, and the zone. This configuration is good for exactly one scenario. We can introduce variables to make it adaptable to a variety of scenarios. Open your integrated terminal and execute git checkout 02_01 . This will switch to the branch with the code for this chapter. We have a new file in our configuration, variables.tf. All of our variable declarations are in this file. Open the file by double clicking it. Separating the variable declarations from the main configuration items in main.tf makes it easier to find elements of the configuration. Terraform will combine all files with a .tf extension into the root module of the configuration. We'll get more into modules later. All you need to know for now is that we can split this configuration into multiple files with a .tf extension and Terraform will combine them for us. With both main.tf and variables.tf open, right click the variables.tf tab and select Split Right, then select the main.tf file on the left. Now we can see both files at the same time. The first variable declaration in variables.tf here is for the project-id. This is about as simple as it gets for a variable declaration, the variable reserved word, the name of the variable, and its type. The next declaration defines a region variable. This declaration is just a little different from the first. It has a default value. When a variable has a default value, that default value will be used unless we override it at runtime. The project-id, however, does not have a default value. This effectively makes the project-id required. If we don't supply a value for the project-id variable, Terraform will prompt for it at apply time. Here we have several more variables. We have a subnet-name, we have the subnet-cidr which is the IP address range for the subnet, and we have private_google_access which will determine how the subnet can access Google APIs. Now let's take a look at the differences in main.tf. In the main branch, they were all hard coded. In this branch, the attributes of the stanzas are updated to refer to the variable values. The var.varnum syntax is used to refer to a variable value in Terraform, so var.project-id matches the project-id name here. And same for the region and the zone. Our configuration can now be applied to any project and in any region and zone by setting the project-id region and zone variables. When I created this branch, I added the variables.tf file, added the variables to that file, and updated the main.tf resource attributes. When I finished with those changes, I used the terraform validate command to confirm that the configuration is still syntactically correct. You can try that now. Enter terraform validate. The validate command will check the syntax of the entire configuration and report any errors. Anytime you make a change to a configuration, it's a good practice to run the validate command to check for errors before you commit the change to your repository. The last thing we need to talk about before we can generate a plan is how to set variable values. There are three methods. The first is the terraform.tfvars file. The next are command line options. And lastly, environment variables. Each of these methods is best for different scenarios. We'll use a combination of a .tfvars file and the command line. Create a new file in the same directory as main.tf by clicking the icon here, and we'll call it terraform.tfvars. You'll notice that it's grayed out because it's part of the .gitignore file. Now enter subnet-cidr, we'll get a little IntelliSense here, and we'll enter 10.127.0.0/24. This is the IP address range for our subnet. Save the file, and now we're ready to create a plan. We're going to add a new command line option this time. Remember that the project-id variable is required because it has no default. We'll use a command line option to set that value. The command will be terraform plan out, -out s1.tfplan -var="project-id=, and then your project id, in my case, it's advancedterraform". If we emitted the project-id setting, we'd be prompted for the value. This is not a problem when running interactively as we are now, but it won't work when we're automating Terraform. Let's take a look at the plan. You'll see that the value you entered into the terraform.tfvars file for the variables have been set for the subnet. So if we scroll to the subnet here, it's right here, and we have the ip_cidr_range matches the value that we set in the tfvars file. We'll hold off on applying this configuration for now as we've got more to learn about variables. So let's keep going.