Read, Generate, Modify Configurations

12. Data Sources

Hey everyone, and welcome back. Now, in today's video, we will be discussing the data sources in TerraForm. Now, data sources allow data to be fetched and computed for use elsewhere in the TerraForm configuration. So this definition can be better understood with this diagram over here. So let's say that you want to create a new EC2 instance in AWS. Now, depending upon the region in which you want to launch the EC Two instance, the overall AMI ID differs accordingly. So for the mobile region, the AMI ID might be AMI 1234. If you plan to launch it in the Singapore region, the AMI ID would be different. If you plan to launch it in the Tokyo region,the AMI ID would be different and so on. So this becomes a challenge. And the next update is that Amaid can also keep on updating at a regular interval. So let's do one thing. Let's quickly jump into a small demo so that we can understand the specific configuration.

So till now, if you have noted that within the resource block, we had manually hard coded the AMI ID and this was the AMI ID that was associated with the US West Two region. So if you use this AMI ID in a different region, it will not work at all. So let's try it out. So I'll do a TerraForm plan. So far, this seems to be working well. So now let's try and replace this with AP South One, which is the Mumbai region. And now when you do a TerraForm plan again, it seems to be working well, primarily because we have not applied the configurations yet. But as soon as you apply it,it should give you an error. Let's try it out. So when you do a TerraForm application, let's do a yes. And now you see, you immediately got an error saying that an invalid AMI ID was not found. So, basically, the particular amid that we mentioned in the Oregon region does not exist in the Mumbai region. Now, let me actually show you that on console as well. So currently I'm in the Oregon region. So when you go ahead and launch an instance here, you see that it depends upon the operating system. So you have Red Hat, you have Ubontwo, you have Microsoft, and so on. Depending upon your operating system, the AMI ID has a difference. So this is the AMI ID associated with the Oregon region. So this ends with etc. So now if you go to a different region, let's select Mumbai. We'll be using Amazon Linux. There are only two AMI. And now you see the AMA ID changed completely.

So this is very similar to how if you want to launch an instance, let's say from Ubuntu, the AMA IDchanges depending upon the region that is selected. So it becomes a little difficult because a developer might launch it in Mumbai, a developer might launch it in Tokyo, a developer might launch it in Hong Kong and so on. So there are multiple ways to address this scenario. The first one is that you hardcore theAmiid within your telephone configuration. But that again is not the best approach because of the AMI ID, which keeps on changing. So the better way is to make use of the data sources here. So from the data source, what happens is that the data source will compute the AMI ID of a specific region depending upon the configuration that you give. And then you can fetch the AMI ID that has been computed by the data source within your resource configuration, in this case the AMI. So what happens here is that the datasource is defined under the database. So you see that you have a database over here.

Then it reads from a specific data source. So there can be multiple data sources. Since we are using AWS, there is a data source called AWS underscore AMI, which is responsible for fetching the AMI ID. And then you export the result to the app underscore AMI name that you give. Now, once you do that, from the AMI section of the AWS instance, you reference the data. So you have data. AWS emphasises the AMI app and the ID. So you have to download a Mi app and underscore AMIID so that you get an AMI ID. So this is what a data source does. Now, if you see over here, once you specify the data source, in this case, the data source that is being used is AWS underscore AMI. You also specify a certain configuration because there can be multiple Amirs. Some can be from Microsoft, some can be officially from Amazon, some can be from Ubuntu and so on. So you specify the owner.

In this case, the owner is Amazon. So these are the official images. Then you also filter because Amazon, in turn, has multiple images. So then you specify that you need the Amazon Linux Two base AMI. And you also need the most recent minimum score, which is equal to two. So this will set the most recent AMI for a specific region. So this is what it looks like at a high-level overview. Let's jump into a quick demo so that this can be better understood. So for today's demo, I already had the data source configured. So, if you notice that this is very similar to what you saw in the screenshot where you are using an AWS AMI data source, you are telling Amazon that you need the most recent AMI from Amazon and then you have a filter that AMI should have, amazon Two hyper AMI, hyper HVM stars. You're referencing the data again in the resource section, which is data AWS AMI app underscore AMI ID. So now, depending upon the region, the data source will fetch the latest AMI ID for Amazon LinuxTwo and the same will be passed to theAMI section under the resource block.

So let's try it out. So let's clear the screen and let's do a TerraForm plan based on our new configuration. So let's currently look into the AMI here. The AMI is de TOC is now the same, we can verify. So let's go to the Oregon region that has been configured. So you should see that it is the TOC. So this is the latest AMI that is available. So let's do some more modifications. Let's try the AP-SE, which is basically the Singapore region. Let's run the TerraForm plan yet again. Let's go a bit higher. So here it is, B 706. So from the edge console, let's go to the Singaporeregion and you will see it is B 706, exactly whatour data source has been providing to us. Now, there are a few things to remember over here. So when you look into the data sources,you can have multiple owners over here. So in our case, we made use of the owner of Amazon. But a lot of organizations have their own hardened MI which has all the security controls preinstalled within it. So they do not really want the Amazon LinuxAMI because these Amis are not hardened. So what they can do is they can create their own AMI with an AWS account and they can set the owner to be equal to themselves. So what will happen is that the data source will search for the EMI from the same AWS account. So again, there are multiple configurations that can be used for the data source that you are using.

13. Debugging in Terraform

Hey everyone, and welcome back. Now in today's video we'll be discussing the debugging aspects of TerraForm. Now TerraForm has detailed logs which can be enabled by setting up the TF underscorelog environment variable to any value. Now you can set the TF underlog to one of the log levels. That includes tracing, it includes debugging, it includes info oneor error to change the verbal city of the logs. So you may notice that things are not working as expected in TerraForm or that TerraFormbinary is giving you problems.

So in order to look into it in more detail, you need more detailed logs. So that a detailed number of logs can be set with the help of the tascore log environment variable. So let's quickly look into it. So for today's demo we have a very simple file called EC to hyperdepark TF. Now if you look into the file, it is very simple. All you have is a provider block, and you have a simple resource block that goes ahead and creates an EC2 instance. So let's go ahead and quickly do a TerraForm plan. So remember that, till now, we have not really enabled debugging. So when you do a TerraForm plan, just have a note on the amount of output that is generated. So let's quickly wait a moment. So if you quickly look into it, So this is the output. As a result, not much detail is shown over here. So now let's go ahead and set the OneScore log environment variable. So I'll say tanscore log is equal to let's keep it trace. So we are running it on a Linux box. Now, once you have done that, let's go ahead and run the TerraForm plan again. And, as you can see, the number of logs generated is enormous when compared to the default setting, when no logs are enabled. So this is something that will allow you to see in detail what exactly TerraForm is doing.

And it will also show you the issues that you might be facing that may be related to TerraForm binary or any other aspect. So if things are not working as expected, or if you might want to file a bug report, this is something that is expected for you to share. Now one of the questions that comes is whether such a big report has been visible on the output of the screen. You can also decide to store it in a specific file. So let's try it out. So I say export TF underscore log underscore path and let's call it Temp TerraForm crash log. All right. So once you have done that, if you do an aTerraForm plan, you will see that all of those big messages are no longer visible on your screen. So what will happen is that all of the trace related messages will directly go to the TerraForm crash lock file that we have created. So let's verify that. So I'll do a nanoteemTerraForm crash log and now you see within a single file you have all the traits and the associated logs. So before we get confused, let's look into some of the important pointers for today's video. The first one is that trace is the most verbose and it is the default if the underscore log is set to something other than the log level name. So, among all of these traits, the most verbose mode. The second is to persist log output. You can set the TF underscore log underscore path in order to force a log to always be appended to a specific file when the logging is enabled. This is also something that we have already seen.

14. Terraform Format

Hey everyone, and welcome back. Now in today's video we'll be discussing the TerraForm format. Now, anyone who is into programming knows the importance of the overall formatting of the code for the readability aspect. Now, if you look at this screenshot, the code is valid, but things are not arranged in a systematic way so that it is easy to read. So if you see here you have an equalto, then you have to go a little less. So the indentation is not the best of what can be achieved here. So what TerraForm allows us to do is, with the help of the TerraForm FMT command, it rewrites the TerraForm configuration file to take care of the overall formatting of your TerraForm code. So this can be better explained with this screenshot here, where you have a before FMT. So this is the code that is before FMT. And after you do a TerraForm FMT, if you look into the overall indentation, it is much better, and it is much easier to read. So this is what the TerraForm FMT allows you to do. Now, let me quickly show you a quickdemo so that this can be better explained.

Now I'm in the CLI and we currently have an archive for today's demo, which is Test Hiphop FMT TS. Now, if you quickly open this up, this is our sample code. And if you see that things are not really invented in a proper manner over here, So what we can do is we can run the TerraForm FMT command and that's about it. So here it will show you the file that has been modified. And now if you quickly do a cat or test FMTover here, you see that there is so much of a difference. So here the region was slightly on the right, but here the region the access key and secret key version are in a proper line and so is the equal to. Over here, all the equals are in the same line. So overall, if you look into the modifications in the resource section, you do not really see any major modifications. Here the primary modification is within the providers section. However, if you have not configured even the resource section properly, this would also have been modified.

15. Validating Terraform Configuration Files

Hey everyone, and welcome back. Now in today's video we will look into how we can validate the TerraForm configuration files with the help of the TerraForm Validate command. Now, TerraForm Validate primarily checks whether a configuration file is synthetically correct. Now it can check for various aspects like unsupported arguments, undeclared variables and others. Now this can be better explained with this diagram where on the left hand side you have the entire TerraForm code. And when you do a TerraForm Validate, itbasically shows you the output over here. So within the output here you see that there is an error which states that there is an unsupported argument and it also shows exactly what the unsupported argument is. That is, ki is equal to blue, so this sky is equal to blue is not supported under the AWS underscore instance resource. So this way, you can quickly identify if there are any mistakes, if there are any undeclared variables, and so on. So let's quickly jump into the practical so that this can be better explained.

So for today's demo we have a TerraformidateTF file and this is a genuine file where everything is working as expected. So from the CLI, if you do a TerraFormValidate, in the output it shows success, the configuration is valid, so everything seems to be fine. You can now try the same example that we showed in the screenshot, where you add an unsupported argument that is not supported by the AWS instance's resource.

So let's save this up. Let's clear the screen and run the telephone validate command yet again. So immediately now you see it giving an error stating that there is an unsupported argument. It also shows you exactly what the argument is that is unsupported. So this is one part. The second part is that even if you have undefined variables, that is also something that it will be able to verify. So let's use that as part of our demo. So instead of specifying the exact value here,let's define a new variable of instance typeand let's go ahead and save this now From the CLI, let's do a TerraForm Validate. And now you see, it is basically giving a new error saying that the reference to undeclared inputvariable and it also shows you exactly which input variable has not been declared. So this is one great approach in which you can quickly verify that the configuration that you have written is a working configuration or not. Now to remember here is that whenever you do a TerraForm plan, the validation happens based on your concern configuration file. So you see, when you do a TerraForm, ultimately behind the scenes, the validation happens and you will see the same type of error when you are running a TerraForm Validate command.

16. Load Order & Semantics

Hey everyone, and welcome back. Now today we'll be discussing the topics of load, order, and semantics. This is an important topic because it will help you write cleaner code when writing a TerraForm configuration in production. So let's get started. TerraForm now loads all configuration files in the specified directory in alphabetical order. One thing to keep in mind is that the file must end in either PA or PA JSON to specify the format. So let's say that you have a folder called TerraFormKpops. Inside this folder you have four TerraForm configurations file.Now whenever you do a TerraForm plan, all of these four configuration files will be loaded.

So it's not like you have to write all your TerraForm configuration within a single configuration file. Even if you split it up into different configuration files, it is not an issue at all. So let's quickly look into it, which we'll be discussing in more detail. So, for today's video, I have an album called "Load Hype and Order." And within this folder I have a file called "semantics TF." Now if you look into this file, there are two resource blocks. There is one variable block and there is one provider block. In general, this appears to be fine when testing or during a tutorial because you can quickly reference everything within the single file. However, whenever you are writing production code,it is recommended that you do not put everything into a single file. So even though if you put everything in a single file, it will work perfectly well, it will not be a cleaner code because, generally, production of codes is a little bigger. And if you put everything within a single file and if there is one issue with the variable, then you'll have to search hundreds of lines to look into the data there. So what happens here in production is that it is recommended that you split the code across multiple configuration files. Let me quickly show you.

So the first block that we have here is the provider block. So for you, what you can do is you can create a new file called provider TF and you can move this provider block within the provider TF file. all right? So now you have one file, and then you have one word block. So this is associated with the variable. So for variables, it is recommended that you go ahead and create a file called variables TSand move all the variables over here. Similarly, for the resource block, this seems to be good. However, it is better to have a proper naming convention. So if you see over here, we have resources of two different types. One is the Im user and the second is the EC two instance. So, for the production, it is recommended to give a proper name. So let's call it EC two PS and let's move this file over here and for the remaining file where we have the resource of the user, let's go ahead and remove the contents that are part of semantics. Let's close it. So now let's close all the files. So now if you look into the structure over here, you have EC two TF, you have imuser TF, you have provider TF, and you have variables TF.

So tomorrow, a requirement comes that you have to add one more IM user. What you can do is simply open the imuser TF and add one more resource block. If there is a requirement to add one more ECtwo instance, you know that all the ECtwoinstancerelated resource blocks are in ECtwo TF. So simply, you can add one more resource block over here. So it's much easier just by looking at the names; tomorrow, if another team member joins and needs to add another user, he can just look at the names and know exactly where he needs to add his own configuration file. All right, so this is something more of an atip that you can make use of whenever you are writing the TerraForm code in production. The second important thing that I wanted to show you today is the local name of a resource, so currently the name of the resource is, for instance, my EC two. Let's do one thing before we proceed further. Let's do a TerraForm plan to verify if this structure is working well. Let's do a TerraForm plan quickly. So far, you can see that everything is working properly, even though you have split it across multiple files. Now, coming back to the topic of the resource local names, let's do one thing Let's copy this block two times over here So we have the same block which is defined twice, so will it work or will it not work? Let's try it out.

So I'll do a TerraCom plan and immediately get an error saying that the AWS underscore instanceresource named MYP two was already declared. Now it is important to remember that you have a resource, so this is an important part to remember. Let's quickly write it down. So you have a resource of type AWS underscore instance and this resource has a name of my EC two. This uniquely identifies this specific resource. So if you have one more resource block with the same name, then it will not work because then it is difficult to identify a block unity. Whenever you are writing a resource block multiple times, it is important that you give a new name to the resource block solet's When you create a TerraForm plan now, everything should go smoothly. All right, so you see, everything is working as expected. Great, so these are the two primary learnings that I wanted to share in today's video. I hope this video has been informative for you and I look forward to seeing you in the next video.

Prepared by Top Experts, the top IT Trainers ensure that when it comes to your IT exam prep and you can count on ExamSnap HashiCorp Certified: Terraform Associate certification video training course that goes in line with the corresponding HashiCorp Terraform Associate exam dumps, study guide, and practice test questions & answers.