Terraform Associate: HashiCorp Certified: Terraform Associate Certification Video Training Course

Terraform Associate: HashiCorp Certified: Terraform Associate certification video training course by prepaway along with practice test questions and answers, study guide and exam dumps provides the ultimate training package to help you pass.

Read, Generate, Modify Configurations

23. Terraform Settings

Hey everyone, and welcome back. Now in today's video, we'll be discussing the Terraform settings. There is now a special TerraForm configuration block type that is used to configure some of the TerraForm's behavior, such as requiring a minimum version of TerraForm to apply your configuration. So the block looks something like this.

So this is basically a simple Terraform block, and within it there are multiple configurations that you can do. So let's quickly look at one of the configuration settings that are associated with the TerraForm version. So there is a specific argument of "required underscore version," which accepts a version constraint string that specifies which version of Terraform needs to be used for your configuration to be applied.

So if you see over here under the TerraFormConfiguration block, you have the required version, which in this case is greater than zero point 12.0. If any user attempts to run the configuration while using a TerraForm version less than zero point 12.0, he will receive an error. All right, so this is one of the important Terraform settings that will be very useful. The second important configuration setting is associated with the provider version. So in this case, you specify the required underscore provider block, which specifies all the providers that are required for the module and also the associated version over here. So this also proves to be useful. So let's quickly jump into the demo so that we understand it better way.

So currently I have a file named "settings.tf," so this only has a provider and a resource block. So let's do a quick terrain in it, and then we'll go over things in more detail. So, let's quickly Terraform it from here. Great. So far, the provider has been downloaded; the version is 3.50. So now let's quickly add a TerraCom block. So I say TerraCom, and the first one is the required version, and within this range, let's say the version should be less than 00:11.

We'll go ahead and say this, and from the CLI, let's quickly do a TerraForm plan. So here you see that you got an error about an unsupported TerraForm version, and it states that this configuration does not support the TerraForm version 00:13 that we are currently using. So, depending on the TerraForm version that you require, you can explicitly specify a required version here.

Now, one of the use cases here is that since there have been a lot of changes between 00:11 and 00:12, you can say explicitly within the required version that Auser needs to have a 00:12 version or higher. So depending upon the code, some codes are specifically designed for the 00:11 version, and some codes are specifically designed for other versions like 00:12 or 00:13.

So you can specify the exact version required over here. So I hope, at a high level overview, you understood the settings associated with the Terraform version. The next one is the provider version. So let's quickly try this out.

So let's specify the required providers. The provider that we need is AWS, and let's specify its version number of 20. Along with that, let's remove the required version now. and let me save the change. Now, in the folder where we actually are running this configuration file, let's quickly look at the exact version of the provider. So the exact time is 3:50.

So, from the CLI, let's quickly do a Terraform in it. So you can see that it is attempting to find a specific provider within this range of 20 and is installing a provider of 270. Great. So our Terraform has been successfully initialized. Now, one more important part to remember is that with the provider version, you can even specify within the provider block something similar to this. But from 00:20 onwards, this is something that is not recommended. And you can make it part of the TerraForm settings themselves.

24. Dealing with Large Infrastructure

And welcome back. Now, in today's video, we'll be discussing dealing with larger infrastructure in TerraForm. Now, whenever you have a larger infrastructure, whether you manage it through TerraForm console or any other scripts or infrastructure as code tools, you will run into issues with AI API limits for a specific provider.

So, let's take an example. So let's assume that on the left hand side, you have an infrared TF file, and within that file, you have four resources that you have specified. You have an ECQ; you have a RDS; you have a security group; and you have the VPC infrastructure. So let's assume that all of these things were created. Now, whenever you do a Terraform plan, the first thing that happens is the update of each resource. So a Terraform refresh would occur, and depending on the amount of resources, the number of calls to the overall AWS provider may also increase. Now, there are two disadvantages here. The first is that the total number of API calls may grow. The second one is that it can slow down the operations for you.

Now, I'll give you one of the examples. So, I used to take care of the AWS hardening with the help of TerraForm for one of the organizations. And the organization used to have hundreds of accounts. So for 99% of the account, things went pretty well, but only for 1% of the account, which had thousands of servers. We were not allowed to run our hardening scripts there. So there was a stumbling block primarily because the API limits in that AWS account had already been reached. And if we ran a TerraForm hardening code there, it used to generate a slew of things like VPC flow, logs, security hubs, AWSconfig, cloud trails, and so on.

As a result of these factors, there was a chance that the API limit would have reached the threshold and production would have decreased. So for those 1% of the accounts, we were not allowed to directly run our hardening code there. And there were a lot of optimizations and compromises that we had to make in order to get it running for those pending accounts. So, whenever you're working at a larger infrastructure level, you need to take care of so many other things as well, apart from just writing the TerraForm code. Now, when you discuss dealing with a larger infrastructure for the exams, the primary aim here is dealing with a larger infrastructure that is part of the same project.

So, instead of defining all four resources within the infrared PM, and knowing that if we do a TerraForm plan, there will be a refresh, that will happen for all of the resources that were part of the infrared TF. That will take a long time. So instead of that, what you can do is divide all of these files into separate projects altogether. So you can have one folder for EasyTwo, one folder for RDS, one folder maybe for Security Group, and one folder for VPC. So this is just an example. So in such a case, what would happen is that when you do a Terraform Plan, only the resource related to the EC Two needs to be refreshed. The other resources, like RDS, Security Group, and VPC infrastructure, would not need to be refreshed, and that can save you a good amount of time. So one of the key things that you need to remember here is that it is important to switch to a smaller configuration where each can be independently applied. This is one of the keys here.

Now one of the questions that comes up is, "What happens if someone has already done that?" Assume an organisation has an infrared TF that is already specified, a VPC, Security Group, RDS, EC-2, and a variety of other things within the same project. So how can you deal with such an offering? So what you can do is, in order for TerraForm to be prevented from querying the current state for all the resources during the operation, like TerraForm Plan, you can stop the refresh with the help of hyper. Refresh is the same as false flag. So this is something that you can do, and it can make sure that things become much faster here. All right? So when you do a TerraForm Plan with refresh, the result is equal to false in this configuration. This specific update state on each resource that used to happen during the Terraform refresh phase will occur in this first configuration. This will not happen.

All right? As a result, the number of API calls will decrease. So this is one way. The second way is that you can directly specify the target. So the target is equal to the resource flag, which can be used to target a specific resource. So for example, let's say that you modified something in the EC Two. Now in the TerraForm plan, if you are associated with the TerraForm plan, a TerraForm refresh will run, which will go ahead and fetch the current state of all of the infrastructure. So instead of doing that, what you can do is specify a target that is equal to EC 2.

As a result, it will only investigate the EC-2 resource. No other things will be looked at. All right? As a result, if it is present, this is typically used to operate on an isolated portion of a very large configuration. So let's do one thing: dive into the practical and see what this might look like. So for today's demo, we have few resources. One is the VPC resource, the second is the security group resource, and the third is the EC2 instance resource. So let's do one thing: let's go ahead and do a Terraform apply post, in which we'll be discussing things in more detail. So let's create a TerraForm application with auto approval quickly. Great. So all of the resources are created. So, as you can see, a total of 21 resources were created. Now, let's assume that you want to add one more rule. So let's create one more rule over here.

So this rule would be for https. Let's change the port from 80 to 443. Now we'll save the change, and from the CLI, let's quickly do a TerraCom et's createSo it is stating that there is one change. However, the primary thing that we are looking for is this refreshing state. So we have already seen that there were 21 resources that were created. Now, what would happen is that any time you do a TerraForm plan, it will go ahead and refresh the state associated with all 21 resources. Now assume that there are hundreds of resources that you have created as part of the same folder. So before you do a Terraform plan, it will refresh the 100 resources that were created. So not only will it slow down your overall operation, but it can also increase the overall API calls that have been made to the provider. So this is what we are looking at in today's video. So what are your options if you have already done that? So let's explore.

So I'll clear the screen. So the first thing that we have seen is that you can go ahead and specify that refresh is equal to oday's videoSo now, if you go a bit here, you see that there was no refreshing of the state of all of the 21 resources that had taken place in the previous test. So this is one important part to remember. Along with that, also remember this because it is important for the exams. So this till day essentially means that an update is in place. So sometimes in an exam, there can be a question that states that you are seeing this day mark within your TerraForm plan. So, what does this all mean?

This basically means that there is an update that is going into place. Anyways. So coming back to the topic, I hope you understand what happens when you specify refresh as false. The second thing is that you can look at the target directly. So you can also specify a target. However, before we do that, let me quickly show you one thing.

So let's also modify the instance type. Let's say from t 2 medium to t 2 small. So now let's go ahead and do a TerraForm plan. And now you see that there are two changes. One is related to the security group, and the second is related to the instance type. In fact, the instance that we had created was based on T two medium.So, while committing the code to GitHub, I'll change it to two micro. As a result, when you create a resource, it is assigned to the Freed Year account.

So that is something that we'll do anyway. So now, even though the refresh is false, it is showing you the update related to all the changes that have been made to the configuration file. So now, with the help of target You can specify the exact target. Let's try it out. So I'll say target, and within the target, let's use the AWS security group followed by allow sshcon.

I'll say allow sshcon; let's press Enter. And now you see that only one resource is up for change. So this is related to the security group, and there is no change. It is showing as part of the EC2 instance, and you also see a warning that resource targeting is in effect, and if you look into the description, it also gives you a little warning stating that the target option is not for routine use and is provided only for exceptional situations.

So that's a very high-level overview of some of the challenges that you can face if you have a larger infrastructure that is configured within the same directory. Now again, one important part to remember is that the things that we are discussing, like "refresh," are equal to false or maybe a target. You can consider it more of a hacky way if you have already made a very large infrastructure configuration in the same directory. However, for production use, it is critical that you do not set the refresh to false and that the target does not equal the resource. This is not really meant to be used extensively within the production environment. However, for exams, it is important to know how you can act if the infrastructure is made in a way where a lot of resources are part of it.

25. Zipmap Function

Hey everyone, and welcome back. Now in today's video, we'll be discussing the zip map function in TerraForm. Now, at a high-level overview, the zipmap function constructs a map from a list of keys and a corresponding list of values. So let's take an example. So let's say you have a list of keys and the keys are pineapple, orange, and strawberry, and then you have a corresponding list of values. The values are yellow, orange, and red. So these are basically the colours associated with the given fruit. And then, if you make use of zip map, then from both of these lists, zip map will go ahead and construct an appropriate map over here.

So let's take an example. So let's say you have a list of easier fruits like pineapple, oranges, and strawberries, and you have a list of values for yellow, orange, and red. So if you use it along with the zip map, you'll see that you get a corresponding map within the output. So, first and foremost, let's go ahead and try it out, and then we'll go over everything in greater detail. Now, if you look into the documentation associated with the azip map function, this is the high-level syntax. So you have a zip map followed by a keyless entry and a value list. And within the example here, it becomes pretty easy to understand. So you have a list of keys, you have a list of values one and two, and then a map is constructed out of it. So let's try it out.

So from the CLI, let's open up the data form console, and in fact, let's copy this example here. And when I press "enter," you see an output similar to this. Now, similar to the example that we have within the PPT, if we make use of a zip map for pineapple, oranges, and strawberries with yellow, orange, and red, if I press Enter, I get a corresponding output here. So this is the high-level overview of what the zip map function does. So let's take a sample use case that allows us to understand where it might be used. So, for example, let's say that you are creating multiple IAM users and you need the output that contains a direct mapping of IAM names and arns. So you see that you have a zip map with the names of the IAM users and the ARN associated with those IAM users, and this type of approach becomes much easier to go through, specifically if you have it as part of the outputs.

So let's try it out. So for today's example, we are basically creating three IAM users, so the count is three, and within the output, we have a RN as well as their name, which would be displayed. So, let's exit the TerraForm console and perform a TerraForm application with auto-approval. So now, within the output, after the three im users are created, you get a separate output containing the arms, and you get a separate output containing the names. This can cause some confusion, especially if you have other resources such as SQS queues and others that you are creating as part of your project. So now what you can do is make sure that things are much easier to read. You can associate the im user name with the appropriate ARN.

So this can be done with the help of a zip map. So now what you can do is have a combined output of combined. So this is just an example. and the value here would be a zip map. And similar to the syntax that has been shown, where you specify a key list and a value list, we can go ahead and copy this up. Let's paste it. We'll add a comma, and then we'll copy the second one, which is associated with the ARN. Let's save this and run a Terraform application with auto-approval from the CLI. And when you look at this combined section, it becomes much easier. So im user zero has a unique ARN, im user one has a unique ARN, two has a unique ARN, and so on. So I hope that at a high level, with the help of this demo, you understand how the zip map function can be used.

Terraform Provisioners

1. Understanding Provisioners in Terraform

Hey everyone, and welcome back. Now, in today's video, we will be discussing TerraForm provisionals. Now, provisional is a great feature of Terraform; in fact, this basically makes it much better than various other infrastructures, such as codetools, which are available in the market. So let's go ahead and understand what provisioners are. Now, for the time being, we have been primarily working on the TerraForm code, which is used for the creation and destruction of the resources. So we do TerraForm apply, and we do TerraForm destroy, so we play around the creation and destruction processes. However, this is limited to that.

So let's take an example here. So let's say we created an easy-to-instance web server with Terraform. So this will basically create an instance, and it will also have a security group associated with it. Now, the problem with this approach is that it only creates this EC2 instance. That EC-2 instance is empty. So it does not have any web server software installed. So, like web server software, you have NGINX, Apache, and others. Now, one question that comes up is: what if you want a complete end-to-end solution in such a way that TerraForm should not only create the EC2 instance, but it should also automatically configure a specific application, or in our example, a specific web server, in the newly created EC2 instance?

As a result, once the EC2 instance is up and running, our application is automatically configured. So that's where the Terraform Provision comes in. So, provisioners are used to execute scripts on local or remote machines as part of the resource creation or destruction process. So we were discussing an example where, whenever a new EC2 instance of web server gets created, TerraForm should automatically execute a script that instals NGINX web server or maybe Apache web server. So, if you want to look at the diagrammatic form, So the first part is the creation of the EC-2 instance.

And once this EC2 instance gets created, TerraForm should automatically go ahead and install NGINX here. So this part can be achieved with the help of provisioners. So, let's do one thing: let's jump into the demo and look into this interesting feature. So, I have a file called "provisional TF," and this file has a resource of EC two instances. So this is a very simple EC-2 resource over here. When we run a Terraform application, Terraform will proceed to create an EC2 instance from this specific AMI. The instance type would be T-2 micro, and the key of that EC-2 instance would be TerraForm. Now, this will go ahead and only create two EC two instance.So now, if you look at the diagrammatic aspect, it will just create the EC-2 instance here. Now, what about the second part, where Terraform should automatically also install NGINX once the EC2 instances are created? So let's do one thing. I'll add one code here of type "provisioner."

And what this code is basically doing is automatically installing and starting NGINX. Now, you don't really have to worry much about this since this is a demo video. I just wanted to show you how a provisioner would really work. We'll go into more detail about these aspects in the later videos. So, now that this has been saved from TerraForm, let's do a TerraForm plan. So this will go ahead and create a resource of type EC-2 instance. Let's do a TerraForm application, and I'll say yes; as you can see in the diagram, the TerraForm will create an EC2 instance. Now, once this EC2 instance is created through Terraform Provisional, Terraform will go ahead and install the NGINX web server inside this EC2 instance and also automatically start it. So let's quickly wait for a moment here. So now you see, once the EC2 instance is created, TerraForm will try to connect to that server via SSH. So this is the server to which it is trying to connect.

And once this specific server is connected, you can see it is automatically installing NGINX and its associated dependencies. So it now says that the application is finished. We now have this newly created EC2 instance in the EC2 console. And we already know that the NGINX Web server has automatically been installed. So let's copy the public IP. And now, you see, as soon as I pasted the IP within the browser, we have a default engineer page that got created. So that's the high-level overview of TerraForm Provisional. So I hope you understand at a high level what provisioners are for. In today's example, we used a demo related to engineers. But for organizations, they can go ahead and configure the entire application with TerraForm provisions as soon as the server is created.

2. Types of Provisioners

Hey everyone, and welcome back to the Kplaps course. So in today's lecture, we'll be discussing various types of providers that are available in Terraform. So in the early lecture, we already understood what provisioning was all about. Now, basically, there are two main types of provisioners. The first is called local executive, and the second is called remote executive. So these are the two main ones that are frequently used in most organizations.

So let's go ahead and understand what local executive provisions are all about and what remote executive provisions are all about. Now, a "local executable," as the name suggests, is a provision that basically allows us to execute some executable locally within this. So this is a sample code where you have a resource of type EC2 instance. So, once the EC2 instance is created, if the provisioner is of the type local exec, this command will be executed on the local machine from which the Terraform application was launched.

So this will not run remotely. In the earlier demo, we had run a few commands on the remote server, so that is remote execution. However, if you want to run certain commands on the local server or on the local machine where the TerraFormApplies have been done, that is called a local execution. So, in this example, once this EC2 instance is created, there is a provisioner named typelocalexec, which has the command echo, and this is the attribute associated with this specific resource. And it will be saved in the private IP TXT. So what this will do is take the IP address, or, I would say, the private IP address, of the EC2 instance that got executed in this specific resource, and store it in the private IP TXT. Now, don't just assume that the local exec provisioner can just do this; they are really powerful.

Now, one of the important uses of local provisions that I have seen is the execution of an acceptable playbook. So many times, you want the Ansible playbook to run automatically on the specified resource after it is created. And this is generally done with the help of local executive provisioners. We'll be looking into this as well. This is one of my favourite topics, so we'll discuss it in detail. Anyway, just kidding, we discussed most of the topics in great detail. So the next type of provider is a remote-exec provisioner. Now, the remote execution provision basically allows us to execute a script or commands on the remote server. So we have already discussed what remote execution is all about. So, once the resource is created, you create a remote exec provisioner and specify various commands such as yam, install, engineer, and serviceengineertar, and all of those provisionals will be executed on the remote server.

And this is the reason why it is called a remote executive provision. So these are the two major types of provisions that are available in Terra Form. Now again, it is not just limited to two provisions. Let me just quickly show you the documentation.

So if you see under the provider, there are various provisions that are available. The local executive is one, and the remote executive is another. You also have various interesting ones like ChefConnection, File, Null, Resource, Salt, and various others. So, as time goes on, the number of provisionals will also increase. However, local executive and remote executive are two provisional types that are commonly used in most organizations, and we will examine some of these provisioners from a practical standpoint to see how we can use them for our infrastructure.

Prepaway's Terraform Associate: HashiCorp Certified: Terraform Associate video training course for passing certification exams is the only solution which you need.