Gain in-depth knowledge for passing your exam with Exam-Labs Terraform Associate: HashiCorp Certified: Terraform Associate certification video training course. The most trusted and reliable name for studying and passing with VCE files which include HashiCorp Terraform Associate practice test questions and answers, study guide and exam practice test questions. Unlike any other Terraform Associate: HashiCorp Certified: Terraform Associate video training course for your certification exam.

Deploying Infrastructure with Terraform

1. Creating first EC2 instance with Terraform

Hey everyone and welcome back. Now in today's video, we are going to start with our exciting journey into launching our first infrastructure resource, TerraForm. So I hope you are excited, because I am pretty excited here. In today's video, we'll be launching the AWS Easy To Instance infrastructure resource. Now, whenever you want to launch certain resources via Terraform on a cloud provider, there are certain important considerations that you need to remember. So for today's video, we are taking an example of a cloud provider, AWS. Now the first consideration is how you will authenticate with that cloud provider. Let's say you have both a Terraform and an AWS account. So TerraForm instructs AWS to launch an EC. Two instance. However, this request will be rejected if there is no authentication in place. So, the first part is the authentication. How do you authenticate with AWS here? The second is which region the resource needs to be launched in. The third question is which resource you want to launch. So after you have all three questions answered, you can configure TerraForm to launch the resource accordingly. So, with this, let's get started. So currently, I am on the TerraForm Registry website. The URL is registry.terraform.io. From here, we can investigate what is required to launch a resource with a cloud provider or any other infrastructure supported by TerraForm. Now, from here, you can go ahead and open up the browser providers here. So all of these are the ones that are supported by TerraForm. Again, the list is pretty huge here. However, the focus for today is on AWS. So let's quickly open up AWS here. So here, you basically get the information related to what this provider is all about. and you can also go ahead and click on documentation. So this documentation is something that we really need. And for any resource that you create in TerraForm, the documentation is very important. Now, within the documentation, you basically have a short description. Then you have an example usage. So this is an example usage, and then you have various other information here. So if you look into the first question here, which states, "How will you authenticate to AWS?" For example, currently I'm logged into AWS. Over here, I have authenticated with the username and password. However, TerraForm. How will TerraForm authenticate? And there are various ways in which authentication is supported. One is static credentialing. So in static credentials, you create an access secret key, and through that, TerraForm authenticates with AWS. Then you also have various things, like environment variables. You have a metadata service, the IAM role, and various others. So, for today's video, we'll keep things simple. We'll be using the static credentials since this is a pretty straightforward and easy way to begin with. So from AWS, let's go to IAM's service, IAM. Let's go ahead and create our first user from IAM. The username is, let's just call it, TerraForm. The access type will just be "Programmatic Access" under the permission. just for simplicity. Since we are starting, let's give administrative access, and let's go ahead and create a user. So now at the end, you get the access key ID. You get the secret key ID, which the TerraForm can use to authenticate with AWS. Now, before we start writing TerraForm code, let's go ahead and create a new folder. The name of the folder will remain "Kplash TerraForm." And initially, the code that we write would be put in this specific folder. So from the Atom editor, you can go ahead and add the project folder. So the folder that we will be adding is Kplab's TerraForm. Great. So this is the folder here. Now under this, let's go ahead and create a new file. Let's just call it that. First EC, then TF. Now, if you look into the TerraForm documentation here under the example usage, they have shown you how you can go ahead and configure the provider. Please keep in mind that this section will vary depending on the provider you use. Now, let me give you an example. Let's go back to the providers here. So let's assume that tomorrow you're planning to write TerraForm based on Azure. So you'll be opening up the Azure provider documentation. Under the documentation here, if you go a bit down, you have an example usage very similar to that of AWS. And here you see that you have a provider in Azure. However, for AWS, you have a provider of AWS. So Provider basically tells Terraform that this is the provider configuration that is needed. So when I specify AWS over here, TerraForm knows that we are going to start writing the AWS provider-related configuration within our code. All right? So this is one important part to remember. The second important part to remember here is that you see that you have examples of usage based on TerraForm 0 point 13 and later and TerraForm 0 point twelve and earlier. Now, the major difference that you will see is this specific block. As a result, 0:113 later recommends using this block. However, 00:12 and earlier do not really require this block. Now, we'll be discussing in great detail in the upcoming videos why this is required. However, for various standard providers like AWS and Azure, even if you do not add it, things would work pretty well. So to begin with, let's keep it very simple. We'll use the provider block here, and then we'll proceed further, understanding things in more detail. So let's start. so I'll say provider. The provider is AWS. The next thing is the region. Now, even in AWS, let's say that you want to go ahead and launch the EC2-two instance. So in which region you want tolaunch the EC Two instance into? So here, you see that there are a lot of regions that are available. So for simplicity, we'll be making use of the US West II region. So I'll refer to the region as "Us, West 2." Now, the next part, if you go to the PPT, is how we authenticate to AWS. As we are seeing, under authentication there are multiple ways in which you can authenticate. The access secret key is the simplest place to start. So let's go ahead and copy this up, and within here, I'll paste it. Now first thing, let's copy the access key that we have created. So let's copy the access key. I'll add it here. Let's copy the secret access key. I'll add it here. So this is the base configuration. So with this information, TerraForm knows that the code that is written would be based on the AWS provider, the resource that needs to be created, and the US-two region, and TerraForm will use this key for authentication. So this is what the provider block is. Now, just by specifying this, the resources would not be created. For example, our aim for today's video was to create an EC II instance. So with this, we cannot really create an EC-2 instance. So the next part within our code would be an easy instance-related configuration here. So if you go back to the documentation on the left-hand side of the AWS provider, we know that AWS supports a lot of services. So depending upon the services that you need, you can go ahead and select the appropriate category. So for example, we are more interested in the EC2 instance, so it comes under the EC2 category, and here we are more interested in the AWS underscore instance. So as we already know, the overall formatting of the documentation is very systematic. So first, you will see the basic description of what this allows us to do. As a result, it provides a resource that is simple to use. So it says this allows instances to be created, updated, and deleted. So this seems to be a good fit here. Then you have an example of usage. Now, this example usage has a lot of things that we do not really require to begin with. The one that we are interested in is this specific block. So, let's look into what this is. First, we are specifying a resource. So the resource basically says that I want to create a resource based on an AWS underscore instance. As we already know, the AWS underscoreinstance resource and TerraForm allow instances to be created, updated, and deleted. So this is what we need. So this is what the resource is, and then you specify the name, whatever name you want to give here. So first, let's go ahead and try it out. So I'll say resource, and the type of resource that we need is an AWS underscore instance, and let's just call it my easy do. Now, under here for example, let's go aheadand launch an easy to instance in AWS. Now, one of the first screens that comes up is Step 1 of choosing an AMI. So whether you want to go ahead and create an EC2 instance based on Amazon Linux, Mac, or Red Hat, which operating system do you need? So this is an important factor here. So let's assume that once we have selected an operating system, the next important part here is to choose an instance type. So whether you want to use tWO micro, tWO medium, tWO large, and so on, So these are some of the important configurations that you have to select. Similarly, in Terraform, if you are saying that I want to create an instance, the next part is: "What is the operating system that I need?" What is the instance type that you need? So you have to tell that to the telephone as well. So if you look into the documentation, you are specifying the AMI and the instance type. So these are a few important things that you have to add. For example, let's say AMI, and let's say instance type. Let's just call it T-2 Micro for now. You can use any instance type that you need, and for AMI, you have to select according to the region. This is critical because, for example, there are specific AMI IDs available for Amazon Linux 2 AMI. So these AMI IDs are region specific.Assume this AMI ID ends with three BS and we are in the Oregon region. So if you switch to any other region, for example, North California, you see that the Amiid has completely changed. So depending on the region and depending upon the operating system that you need, the AMI ID will also change. So for today's video, we'll be using one specific AMI ID based on Amazon Linux 2 that is based on the US West 2 region. However, you can go ahead and use any AMI that you intend to have for your infrastructure. To begin with, I'll recommend that you use the same configurations that we have, and at a later stage you can customise it according to your requirements. Now, one more important part to remember is that once you select the AMI ID as well as the instance type, there are a lot of other options that it is showing, like IAM, role placement groups, subnets, and all. However, all of these you can either ignore or use. If you ignore it, then the defaults will be chosen. So, for example, in this specific configuration, you are not really specifying any other thing. The only thing that you are specifying is the AMA and the instance type, and that is what is required. So if you want to configure various other things under the argument reference, it basically shows you what is required and what is optional. As we already know, AMI is required, which is why we set it, whereas various other things are optional. So you have optional, optional, optional, and all. The next thing required is the instance type. So we have used both of them. Once your base code is ready, you can go ahead and save the change. So now that you have saved the changes, let's go ahead and open up the terminal. And within this folder, we need to go into the same folder where we have written our first TerraForm file. Do note that this file ends with the extension ".tf." So this file is currently on my desktop under the folder "Kpop TerraForm." So let's clear up the change. Now if I do a DIY, it basically shows you that this specific file is present. If you're using another operating system, such as Mac, you can simply type LS instead of Dir here. So our file is present. Now the first thing that we need to do is run a TerraForm init command. So what this command does is go ahead and read your configuration and identify that you will be working with the AWS provider. And now it will go ahead and start downloading the AWS-related TerraForm plugins. That's great. So here you see it stays installed hashic of AWS. So things seem to be working perfectly well. The next step is to run the TerraForm plan, and within the output you will see information about what TerraForm intends to create. For example, if you see over here that it is trying to create what it is trying to create, it is trying to create an AWS instance, and the AWS instance would be based on a specific AMI that you have specified within your configuration, and it would be based on an instance type of TWO micro. Because you haven't specified anything else here, a lot of other areas become known after applying. So "after apply" basically means "after the resource is created." So whenever you are writing Terraform, it is better to do a Terraform plan, which will show you what exactly Terraform will create if you go ahead and proceed further. So now this seems to be good. So what we'll do now is do a Terraform application. So what Terraform allows us to do is go ahead and actually create the resource that we have written within the configuration. So it basically tells you what kind of resource will be created and asks you whether you want to accept or reject it. So I'll just put it as "yes," and as soon as you do it, TerraForm will go ahead and start to create the EC-2 instance. Now in this case it is statingerror launching invalid AMI ID form. All right, so let's do one thing. Let's go ahead and switch back to the US WestTwo region, and let's take the latest AMI ID here. So this is the latest AMI ID. Let's copy this under the AMI. Let's go ahead and replace it with the latest AMI ID. And now let's do a TerraForm apply. Yet again, let's vote yes. That's great. So after 47 seconds, it states "apply complete" and one resource is added. So that basically means ourEC two instances successfully created. Now, to verify, let's go ahead and go back to the EC Two console. Under instances, you can see that one instance with the instance type T-2 micro is running over here. That's great. So I hope at a high leveloverview, you understood the basics of providerand you understood the basics of resource. Now, in the upcoming videos, we'll be going ahead and discussing these in more detail for a better understanding. Now, do note that if you're comfortable with the basic syntaxes of TerraForm, irrespective of what provider you use, things will become much easier to go ahead and start writing the code based on them. For example, let's say that next week you are starting to write Azure-related configuration. Then the provider will be changed from AWS to Azure. We will have to set the appropriate authentication credentials, and then we'll have to choose the appropriate resource that we want to create the Azure instance based on. That's great. So let's look into some of the important learnings for today's video. The first is that each provider has resources that are divided into multiple categories. For example, for the AWS provider here, if you go to the documentation, you see that there are multiple high-level categories based on which resources are based on.So that is what the first point states. Second point: Resources require certain sets of arguments based on the use case. Take, for instance, the EC resource as an example. So this specific resource requires certain arguments over here, like the AMIID instance type, and so on. And similar to that, irrespective of which resource you choose, let's say you choose a resource called elastic IP. So even this resource will have certain sets of arguments that are either optional or that would be required. So that is what the second point states. So in TerraForm, irrespective of what provider you choose, maybe Kubernetes, AWS, or Azure GCP, the overall documentation format remains the same. You'll get the resource, you'll get the description, you'll get the example usage, and you'll get the argument reference, which are either required or optional based on what you think.

2. Understanding Resources & Providers – NEW

Hey everyone and welcome back. Now in today's video, we will be discussing the providers and resources. Now in the earlier video, we had configured our first EC2 instance via TerraForm, and in her TerraForm code, we had made use of both the provider and resource. So let's go ahead and understand both of these in more detail. Now, the first important area here is the providers. Now, as we already know, TerraForm supports a lot of providers. So you have a provider for AWS, Azure, and Kubernetes. You have Alibaba, Cloud, and so many others. Now, depending on what type of infrastructure you want to launch, you will have to make use of an appropriate provider accordingly. So for example, let's say that tomorrow you want to launch Azure infrastructure. Then you will have to make use of Azure's provider. If you want to create an EC2 instance, then you'll make use of an AWS provider, and so on. Now, if you go to the TerraForm registry, the URL is registry TerraForm IO. Here, you see that there are 756 providers. And this is the beauty of TerraForm. It supports a wide range of providers, depending on the type of infrastructure you want to build. So for example, if you go to "browse providers" here, you can see the list of providers that are available. Again, they are categorised into multiple high-level categories: official, verified, and community. We'll be discussing these in greater detail at a later stage. However, this is only a list of providers for informational purposes. Again, it runs into multiple pages that you can go ahead and work around. That's great. So I hope you understood what providers are. The second important part that we should know is the initialization phase. Now, whenever you add a provider, it is important to run TerraForm's init command, which in turn will download the plugins associated with the provider. So when you create a terraform in it, it will go ahead and download all the plugins associated with the provider that you have configured within your terraform file. So let's quickly look into it. Now, within our first underscore EC 2 TS, we already know that we have used the provider of AWS. Now, just specifying the provider within the TF file is not enough. You also have to download the plugins associated with this provider. So within your project, under the TerraForm directory, let's go to providers. Under Hashico, you have the AWS ones. And if you explore this under the windows, you'll see that you have a TerraForm provider, AWS. This is the actual provider plugin that is very important. And this behind the scenes it interacts withthe AWS and the infrastructure is created. One thing to keep in mind is that whenever you add a provider to your project, the next thing you should do is a Terraform in it. So, for example, let's go a little further. So we have been working with AWS. Let's take an example from Azure. So this is the Azure provider here. Let's go to the documentation here. And if you go a bit down here, you'll see you have a provider named Azure. Let's go ahead and replicate this. I'll copy. And within our first EC, let me go ahead and paste it. Now, all of these highlighted things are optional. So you can essentially just make use of this as well. So let's say this. Now that I've added the Azure provider, you can do a Terraform in it. And now what will happen is that TerraForm will detect that your configuration file has a new provider named Azure, and it will go ahead and download the appropriate plugins accordingly. So here you see that it is installing the hash of Azure-related plugins here. That's great. And after the installation has completed, it will say that TerraForm has been successfully initialized. Now, if you go back up under the hash of directories this time, you will see AWS and Azure. And under Azure, you see that you have an appropriate plugin related to the Azure provider. So whenever you are creating some Azure-related resource, TerraForm in turn, behind the scenes, will make use of the appropriate plugin to interact with the Azure APIs. That's great. So, hopefully, you now understand the initialization phase as well. The third important area here are the resources. So resources are basically a reference to the individual services that the provider has to offer. So for example, let's say that you are making use of an AWS provider. Now, under AWS, you see that there are a lot of services that are available. Now, depending upon which service you want to use, you will be making use of an appropriate resource. For example, if you want to go ahead and create an EC2 instance, you will use the resource AWS underscore instance. So this is associated with EC instance two instance.If you want to go ahead and create an application load balancer, then you have a different resource for AWS, ALB, and so on. Now, let me also show you that. So let's go back to the providers. Here we'll open up the AWS provider. Let's go to the documentation. And the services that are directly supported are listed on the left side of this section. So let's go a bit lower. Let's open the EC2 one, and there are many subresources under EC2. For example, let's go to the EC2 service, and under the EC2 service here, you see that you can do a lot of things apart from launching the EC2 instance. And similarly, even under EC2, there are a lot of things like AMI; you have EBS volume. So if you look over here, under the Elastic Block Storage, you have the EBS volume and so on. Now again, this is not directly one-to-one mapping here, but you get the basic idea of what the intention here is. So let's go ahead and go a little bit down here. We have an AWS underscore instance. So if you see you have a resource of "AWS underscore instance," if you want to go ahead and create an elasticIP, then you can go to "AWS underscore EIP" under the resource here, you see you have AWS underscore EIP.Great. So I hope this gives you a basic understanding of what resources are. So, referencing our first underscore EC2 TF, we used an AWS instance resource and then specified various attributes related to the type of EC2 instance we want to create. Now, one important part to remember, primarily because this is one of the newer updates: From zero point 13 onwards, TerraForm requires explicit source information for any providers that are not HashiCorp-maintained, using a new syntax in the required provider nested block under the TerraForm configuration block. Again, this is a little confusing on its own, but keep in mind at a high level that in TerraForm there are certain providersthat are maintained by Hashicop, there are certainproviders that are not maintained by Hashicop. So what this basically means is that if you try to make use of a Hashcop-maintained provider, then if you directly make use of this block, it will work. However, if you try to make use of this specific block for the providers that are not directly maintained by Hashcop, then you will get an error. So, for example, you have a provider of Digital Ocean, so this is not directly Hashicop maintained.So this is something that you must define under the required provider block under the TerraForm configuration here. One more thing to remember is that in the newer version, it is recommended that you use this newer approach to defining the provider under the TerraForm configuration. So let me give you an example here. Let's go back to the providers. Let's open up the AWS provider here. Let's go to the documentation now under the example usage here for TerraForm 00:13 and later, where, apart from this provider of AWS, they have also specified this specific configuration block. Now, in the later parts of the videos, we'll go into more detail about what this is, but for now, just a high-level overview. Note that under the required provider, you are specifying the path of the provider. So this path is nothing but the path that you see in the URL, which is Hashicop AWS, and the same thing that you see over here. And after you have mentioned this, then you can go ahead and specify the provider. Now, from Terraform zero point twelve and earlier, you can directly specify the provider AWS block, and things will work perfectly fine. In fact, even for the newer versions like zero-point-14 and all, if you are specifying this kind of block for a hashtag of maintenance providers, Specifically, things will work perfectly well. So, for example, we have been using a simpler cloud provider, AWS, and things are working pretty well. And this is because this is a HIPAA-maintained provider. Now, let's try to specify a provider for Digital Ocean. Let me make a sale, and if you try to do a TerraForm in it, you'll notice that you immediately get an error stating that it failed to query the available provider package and which package it couldn't find. It is unable to locate hashicopdigitalocean. Now, within Google, if you just type "digitaloceanprovider" for TerraForm, you will get the digital ocean provider here. Now, if you look into this specific provider, again, you have a provider in Digital Ocean. So this will work perfectly well if you're using 0 point twelve.However, with the version from 00:13 onwards, if you click on this use provider block, it will basically tell you the exact code here. So the code is, if you look into the source, "DigitalOcean DigitalOcean," which is very similar to the Uri. Under the providers, you have DigitalOcean, and the same thing has been specified under the source block. And after you have specified this, then things are normal. Then you can directly specify Digital Ocean's provider here. So let me also show you. So if I copy this and let me specify it, I'll save the configuration, clear the screen, and run a Terraform in it. And now our command was successful. So if I have to explain it in a meme format, For TerraForm zero point 13 and onwards, it is recommended that you make use of a provider block, something similar to what you see here, and not the older approach. However, the first approach will also work for the official hashtagoffmaintainedproviders. Now, since you are learning TerraForm, it is very important that you know both the older approach and the newer one, primarily because a lot of organizations are still working on the older version of TerraForm. and it is important for us to not.

3. Understanding Resource & Providers - Part 2 NEW

Hey everyone and welcome back. Now, in the earlier video, we were discussing in great detail the basics of providers and resources. Now, one of the questions that generally comes up is, "Hey, I'm comfortable with writing and getting the TerraForm code for the AWS provider." Now, after one year, I shift to a new organization, and that new organisation is completely based on Azure. So will I have to learn TerraForm again? And the answer is no, it does not. If you are comfortable with writing the TerraForm for any one of the providers, irrespective of what other providers you use, the overall TerraForm format and syntax will be very similar. So it will be very easy for you to go ahead and write the resources for other providers as well. Now, this is what I wanted to emphasise in more detail about.So, what we'll be doing today is also creating one more resource based on the provider of GitHub. Now, for today's demo, I have a GitHub account that I created. So in case you do not have an account, you can go ahead and quickly create one here. And our intention is to create a TerraForm repository in this specific GitHub account. Now, within a Google search, if you just do "TerraForm GitHub provider" under the registry TerraForm IO, you will be directed to the GitHub provider over here. Now, if you look into the overall example usage, it is very similar. You define a provider block, and you define a resource block. This is very similar to that of AWS, and with underresourcing, you can create a lot of things here. So you have a GitHub branch, you have a GitHub repository, you have a GitHub team, and so on. So, depending upon what resource under GitHub you want to create, you will have to create the appropriate resource. And similarly, in the newer documentation, if you click on Use Provider, you have this newer format. Let's go ahead and copy this into our code. Let's go ahead and create one more file called GitHub TF. And let me paste things over here. Along with that, we'll also remove the earlier-created code associated with the Digital Version and Azure, which we do not really need. So now we have a first underscoreEC, two TFs, and a GitHub TF. Now, since you have a provider that is configured here, the next important thing here is the token. Now, do note that depending upon the provider that you use, the way in which you can go ahead and authenticate will also differ. Now, let me also show you an example. So, if you quickly go to providers here, let's take three providers as an example. We'll be using GitHub, AWS, and Kubernetes. So under AWS, if you go to the documentation here, let's go a bit down. Under the authentication here, you see that you can authenticate with an access key and a secret key. So this is for AWS. If you discuss Kubernetes, let's go to the documentation here. You will be making use of a queue config file, which primarily contains your authentication credentials. And if you use a GitHub provider, you will have to specify a token. So, depending on the provider you use, the way you must authenticate will differ, as will the information you can obtain directly from the documentation. Now, we already know that for GitHub, the approach of a token is used. So what we'll have to do, we'll have to create a token. So in the GitHub account, let's go to settings, and within a year, we'll go to developer settings. Here under the personal access token, you can go ahead and quickly generate a token. So it is asking for credentials. Let me go ahead and confirm the password. And now whenever you generate a token, you can also define the scope of access here. So first, let's go ahead and underline that we'll just say "terraform." And if you CTRL F on repository here, you can select the operations related to repos as well as delete repos. So this specific token can go ahead and do these operations. Now, if you want your token to go ahead and do various other operations related to GitHub, you can go ahead and add the configurations accordingly. For simplicity, let's go ahead and create a token with these specific scopes. So in the output you basically get this specific token, and this is what we need. So let's copy this and specify the token within our GitHub providerlet, and I'll pace the token here. That's great. So now at this stage, we have specified the provider configuration. The next thing that we want to do is go ahead and create a new repository on GitHub. So going back to our GitHub documentation, we need to open up the resource associated with the GitHub repository. So here, it will basically give you an example usage. So this becomes much more simple. So you have a GitHub repository; this is the local name, and here you specify the name of the repository, the description, and the visibility. So let's go ahead and copy this up, and then let me paste it. Now in this code, you see that there are a lot of other things like templates that are also available. So whenever you're working with a resource, there are certain things that are mandatory and certain things that are optional. So let's look into that. So if you go a bit down under the arguments, you will see "name" is required. So this name is required, the description is optional, and let's do a CTRL F on template, and the template part is also optional. So let's go ahead and remove the optional part here. Primarily, let's remove the template; let's remove the description and visibility. Set it to private thename and call it the TerraForm repository. All right, we'll go ahead and save it. Now, we already know that since we have added a new provider to GitHub, the next thing that we need to do is add TerraForm to it. So from the CLI, let's do a TerraForm in it. That's great. Now let's clear the screen and do a TerraForm plan. That's great. So now here it states: "One, two, ad." Now, if you go a bit down, it is stating that it is trying to create a new resource, a GitHub repository. and your local name is Example. And here is the name of the repository: TerraForm Repo. and the visibility is private. So this seems to be good. You can go ahead and submit a Terraform application. So now, you see, it was able to successfully create a GitHub repository. Now, in order to verify if things are working as expected, let's go back to our homepage. And here you can see another repository called TerraForm Repo. That's great. So, the primary goal of today's video was that if we learn Terraform for one of the providers, such as AWS, it will be very easy for you to go ahead and deploy various other provider-related infrastructure, such as GitHub, Kubernetes, and so on. Now, one important part to remember is that you need to know what exactly the resource does. For example, if you are working with GitHub providers, you should know what a GitHub repository is. So this is one thing that is important. However, apart from that, various other things like the provider, the resource, the argument, the reference, and various other things are very similar across providers. As a result, using Terraform across multiple structure technologies becomes very simple in the long run. And this is precisely one of the reasons why TerraForm has become very popular in the industry nowadays. So with this, we will conclude today's video.

4. Destroying Infrastructure with Terraform (NEW)

Hey everyone and welcome back. Now in today's video we will look into how we can go ahead and destroy the resources that we have created with TerraForm. Now, one important part to remember here is that we have been creating various infrastructure structures and resources, like EC2 instances, via TerraForm. So if these resources keep on running, then you'll also get charged for them. So it is very important that we also know how we can go ahead and delete the infrastructure resources that we have created via TerraForm. So as of now, we have primarily been working with EC2 instances and GitHub. So a GitHub repository will not really cost anything, but the EC2 instance will. So let's go ahead and look intohow we can terminate the resources. Now there are multiple approaches in which we can go ahead and delete the resources. Let's go ahead and look at the approach taken by TerraForm destroy.Now when you go ahead and run the TerraFormdestroy command, what will happen is all the resourcesthat are created as part of the project. So let's say that you have a directory of KP Labs TerraForm, and inside this directory you run the TerraForm destroy command. So all the resources that have been created under this directory will get terminated here. So Terraform's strategy is to destroy. Now one of the questions that comes up is, "Hey, I do not really want all of the resources to be deleted; I just want the EC-2 instance to be deleted." The GitHub repository still needs some use it.So, in this case, we can use a hyphen target flag in conjunction with the Terraform destroy. So now what we can do is specify. So if you see TerraForm destroy target, then you are specifying the target of AWS underscore instance mysit. We'll be discussing what exactly this means, but at a high level, we just note that if you run this command, only the easy-to-instance objects will get deleted. The other resources that are part of the project will continue to exist. So let's do one thing. Let's go ahead and quickly try it out. So I'm currently in Kblabs TerraForm's folder. And as we already know, this folder contains first the EC2 TF and the GitHub TF, both of which are created. Now, if you do a Terraform destroy, the plan says you should destroy two things, primarily because we only have two resources. The first one is this GitHub repository. So it's stating that this GitHub repository will be destroyed. And second, it is stating that the AWS instance will be destroyed. Now if you say yes over here, both of these resources would be removed. So for an example, let's just say no. So that is the approach one takes. The second part was the approach that we used to specify the target flag. So let's go ahead and understand this in more detail now The target option can be used to focus Terraform's attention on only a subset of resources instead of all the resources. If you look at the screenshot, you can see that we only want to go ahead and terminate the resource of an AWS underscore instance, so if you have such a use case, you can use the target flag. The target flag is used in conjunction with the resource type and the local resource name, so this is important for us to remember. the second one is the local resourcename so this is the name of the specific resource typethat you specify so in case of the AWS instance thelocal name here is my easy to you can have thisas a customer value you can say customer sample or whateveryou want to specify so the second part is referred asa local resource name for AWS instance it is my easyto for the GitHub it is example so when you goahead and make use of a TerraForm destroy with the targetflag then you have to specify the resource type plus localresource name so the resource type is AWS underscore instance thisis already we know and also note that the separator betweenboth of them is a dot so AWS underscore instance myctuso dot is a separate between the resource type and localresource name in fact if you go a bit up herealso you will see that GitHub underscorerepository example so this is the combination is what it is showing so this combination isbasically the way in which this specific resource is referenced tosimilarly to reference to this specific resource we make use ofawsunderstance myec two and here if you go a bit upyou will see awsinstance myec two so when it states AWSinstance myec two will be destroyed it basically means that thereis a resource type of AWS instance with a local resourcename of MYC two in your TerraForm configuration and that willbe destroyed that's great so let's go ahead and try itout so I'll say TerraForm destroy with the target of awsinstanceMYC two and now you see it stays only one resourceto destroy so if you go a beta only this specificresource has been destroyed the GitHub repository is not part ofit so to test it out let's say yes that's greatso it took around 48 seconds for the apply to becompleted now if you go to the AWS console you willsee that our instant state is terminated. That's great. So, I hope you understand the fundamentals of Terraform destruction at a high level. We considered the approach of simply typing Terraform destroy and destroying all of the resources in a directory. And the second approach, where we also specify a target flag, Now, one more very important part that we should know is that when you do a TerraForm plan yet again, you see that it is trying to add the resource. And what resource is it trying to add? It is trying to add the "easy to instance" resource. Now, the question is why? Now, one important part to remember is that after you have removed the specific resource, it is assumed that you do not really need the EC-2 instance. However, within the configuration file, you are telling TerraForm to go ahead and create this instance. And this is the reason why when you do a Terraform plan, it will go ahead and create the instance yet again. So in case you do not need the resource altogether, you can go ahead and remove the entire configuration block altogether.So for example, let me just comment this part out; let's save it. And now, if you run a TerraForm plan, you'll notice that no changes are required. Now, also note that although we have been making use of Terraform destroy, let's say that we have a GitHub repository that is created and you comment out the entire GitHub code from the configuration, all right? So either comment it out or remove the file altogether. So if you comment it out or you remove the file altogether, this informs TerraForm on the next plan that you do not really need the resource, and if you do a TerraForm plan, it will do a similar operation to that of destroy. So since we have commented out the GitHub repository part, the TerraForm will assume that we do not really need it. So now, if you do a Terraform plan, it will go ahead and initialise the destruction process of this resource. So it says here that it wants to destroy and that its GitHub repository dot example will be destroyed.

5. Understanding Terraform State files (NEW)

Hey everyone and welcome back. Now in today's video, we will be discussing the TerraForm State file. Now, this is a very important topic as far as TerraForm is concerned. So in this video and also in the upcoming few videos, we'll be going ahead and discussing the TerraForm State file in great detail. Now, in the earlier video, we had commented out the code associated with the GitHub as well as the code associated with the EC2 instance. So let's go ahead and remove our comment. Now, we already know that we have destroyed the resource associated with the EC Two instance. However, we did not destroy anything on GitHub. So our GitHub repository still exists. When you do a TerraForm plan here, you'll notice that it says one to add. And what TerraForm is trying to add, itis trying to add the EC Two instance. Now, the question that comes up is, "How did Terraform know that our EC2 instance was destroyed and the GitHub repository is still existing?" So how does it determine those aspects here? And that is what we'll be learning in today's video. Now, one important part that we should know is that Terraform stores the state of the infrastructure that has been created from the TerraForm files. And this state allows TerraForm to map real-world resources to your existing configuration. We'll be discussing this in more detail in theupcoming few videos, but at a high level overview. Just keep this in mind whenever you create a resource, for example, an EC Two instance. TerraForm, behind the scenes, also stores the information associated with this resource in a file called the TerraForm State file. And through this specific state file, TerraForm tracks your infrastructure-related data. For example, if you create an easy to instance and a GitHub repo TerraForm behind the scenes, it will store information associated with both in a TerraForm State file. As a result, these are represented as a state file on the right side. Now, if you go ahead and destroy any of the resources, the associated state file for those resources is also removed. So this way, whenever you do a TerraForm plan, TerraForm will know that the GitHub repository state information is present. That means that the GitHubrepository is created already. However, since the state information of our EC2 instance is empty, it means that an EC2 instance is not yet created, and hence it will go ahead and try to create the EC2 instance yet again. For example, whenever we did a Terraformplan, it was able to detect that the GitHub repository was already present. But the EC2 instance it is trying to create primarily is not present because the associated state of the EC2 instance is not present. So, under the project where we are writing your TerraForm file, there is one more file. If you'll notice here it is called the TerraForm TF Statefile, and this is what we are interested in. Now, within the Atom editor, if you look over here, we have one more file of TerraForm TFstate, and this is what the file looks like. Now again, we'll be discussing things in more detail, but as of now, just note that under the resources, it is just showing that there is a resource of type GitHub repository. So if you go to GitHub, there is a resource type of GitHub repository that has been stored here, and it also has the exact provider-related data and also the data related to the created GitHub repository. Demo Kplab TerraForm Repo is the full name. This is the get-clone URL, as well as other resource-related information. Now, since you do not really have any resource type of AWS underscore instance here, TerraForm is able to easily detect that this specific resource is not yet created. Or maybe it was created, but it is destroyed now. So let's do one thing. Let's go ahead and do a TerraForm destroy first. So as expected, you have one resource that was part of the state file. So TerraForm knows that this resource was created. So it will go ahead and destroy this resource only. That's great. So after this resource has been destroyed, ifyou look into the TerraForm State file here,you see there are no resource. That basically means that everything is empty here. So now, when you create a Terraform plan, Terraform will create not only an easy to instance, but also a GitHub repository. So let's try it out. So let's do a TerraForm plan. As expected, it is stating "two" to add and adding the GitHub repository as well as the EC2 instance. So let's do a Terraform application, and let's say, "Yes, that's great." So both of the resources are created, so let's quickly verify that. So let me refresh the EC-2 console, and our new EC-2 instance is initializing. And now, if you look into the TerraForm TF State file under the resource, you have one resource with the type of "AWS underscore" instance, and the name is MYEC too. So I hope you know the difference between the resource type and the resource's local name. So this is the first one, and if you go a bit down, you have one more associated with the source type of GitHub and the name of example. Now, one more important thing that you should know is that the state file contains the information associated with the resources that are currently live. For example, not only will it contain the information related to the instance and the local resource name, but it also contains a lot of information other than that. So for example, let's go a bit down. So it is stating that the IP address of the instance is 34, 2, 1, 9. And if you look over here, the IP address along with the security group state that it is using the default security group. And under the security group here, you see the name of the security group is "default," and the security group ID ends with "BA," and the same information you can see over here. So the exact data about the resource that is running is also stored within the TerraForm TF state file. And this is also one of the reasons why it is generally recommended to not really touch this specific TF State file. So if you're playing around with the TF statefile through the Atom editor or any other thing, the chances are that things will really get messed up. So I prefer not to directly go ahead and start editing this specific file. Also note that it is very important that you store the backup of the TF state file because if this file is not present, TerraForm has no way of knowing the details about the infrastructure that is being created. So let's do one thing, let's do a mess upand let's see on what would be the impact here. So for example, let's go ahead and remove the TF state file that is part of the folder. So this includes the TF state and the TF state backup. So I'll go ahead and delete it. So now, when you do a Terraform plan, you see that it is trying to add both of the resources, not only our GitHub repository but also our EC2 instance here. So let's do one thing. Let's go ahead and manually remove the repository here. So let's delete this depository. And now let's go ahead and do a TerraForm application. So the two resources are being created. Let's do a yes; that's great. So now, under "easy two," let's quickly refresh the console. You see that there is one instance here. So this is the instance that is under the initialization stage, and this instance is managed via TerraForm. You can also verify. If you look at the instanceID, you'll notice that it ends with two two E. And if you look a little further down in the state file, it ends with two two E. That's great. So I hope, at a high level, you understand the importance of a state file.

Pay a fraction of the cost to study with Exam-Labs Terraform Associate: HashiCorp Certified: Terraform Associate certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including Terraform Associate: HashiCorp Certified: Terraform Associate certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.

Hide