3. Implementing remote-exec provisioners
And welcome back. Now in today’s video, we will be discussing remote execution provisions in terms of their practical aspects. Now, from the official documentation here, if you look at the example usage, the first resource block is the AWS underscore instance. Now, even if you look at the diagram and the demo that we discussed, since the remote executable provision needs to run on a remote resource, you will have to ensure that the remote resource is created first. That’s why you have a resource block associated with the EC to instance. So let’s do one thing. I have a file called remote exec TF, and I’ll copy the EC to instance resource that we had created in the earlier practical. So this is a simple EC2 instance resource here. Now the next thing is the actual provider section. So what happens in provisional? Since we’ve already discussed the various types of provisional available, they can be local executives, remote executives, chefs, and so on. So, in addition to defining the provisioner, you must also specify the type of provisioner that you intend to use.
So let’s add that up. So I’ll define the provisioner. The type of provider would be a remote exit, and within this, we have to add an inline. So inline basically allows us to add a list of commands that will be executed in the EC to an instance. So let’s add it inline. So you can put a list of commands here. So I’ll say “command one,” you have “command two,” and so on. So I hope you understand why this inline block is required. To install NGINX on an Amazon Linux instance, use scudo amazon Linux extra install hyphen. One, one, two, Hynix. So this will go ahead and install NGINX.
Now that you have this installed, the next step is to start NGINX. So I’ll say, “System CTL start NGINX.” Remember that if you’re using Centuries, this command will be changed to yum hyphen y install NGINX. All right, so let’s do anything; let’s remove this extra block. Now that you have specified the commands that need to be executed, the next thing that needs to be done is provide Terraform with the username, password, or private key so that it can connect to the EC instance. So as we are discussing, once this EC2 instance is created, TerraForm should be able to log into this EC2 instance, and then it will run the command.
So you will have to specify those details. So what is the username of that EC2 instance, what is the password, what is the private key, and so on? As a result, that aspect is usually included in the provider connections. So this is the simple connection block. Now, if you look into the connection block, you can specify the type. So the type is SSH, then you have the username, then you have the password. So you can also have a private key in case your EC instance supports key-based authentication. So let’s add this up. So let’s add a connection block here. Now, as far as types go, there are two that are supported, as stated in the documentation: SSH and Win RM. Now, if you do not really specify the type, that is also fine because, by default, it will take the type of SSH. So you can even directly start with the user block. So let’s do something for the sake of completeness. I’ll also include the type block. The second block that you need is the user block.
So the user for Amazon Linux would be the easiest to use. So if you’re using something like Sends, then the user might change. You can verify that aspect. Now for the Amazon Linux-based instances, we will have key-based authentication and not password-based authentication. So let’s do one thing: let’s go to the keypad and create a new keypad. I’ll call it TerraForm, or let’s call it KPLabs hyphen TerraForm, and I’ll go ahead and create it. So this will also go ahead and download this kplabs-hyphenated TerraForm PEM file. So from the downloaded location, I’ll go ahead and copy this file, and within a section three folder where we are basically doing the practical’s, I’ll paste the Kplabs TerraForm file. So now the next thing that you will have to use is the private hyphen key. So this private hyphen key should refer to the private key through which the EC instance will be created. So now let’s specify the private hyphen key, and within here you will have to make use of the file function, which can be used to load a specific file. So this is pretty simple. So we can use file followed by specifying the name of the file. So, if it is the plans hyphen TerraForm pen, So if you want to confirm within the documentation, it already has a link to the file function. So you can open it up in a new tab where you will get the syntax associated with it, where you have to specify the file, and you can also specify the path where the file is present.
So you have the file, and then you have the path where the file can be found. So let’s add a proper path. All right. And one more thing that you have to specify is the host. So coming back to the documentation, host is basically the address of the resource to connect to.
As a result, this can be the IP address of the EC instance to which Terraform will establish an SSH connection. So for host, we’ll say “self-public underscore IP.” So since this is part of the resource block, There is self- and public underscore here. IP is the attribute that is associated with the EC To instance. So that’s the high-level overview. Now, there are a few more things that you will have to change. The first thing is that since this EC2 instance is getting created, you will have to create it with a KP Labs Hyphen TerraForm file so that TerraForm will be able to connect to it. As a result, I’ll use the underscored name Key. I’ll go with Klaus Hyphen TerraForm.
So this EC2 instance gets created with this specific key. All right? So that’s the high-level overview. Now, since we have not really specified a security group here, TerraForm will automatically use the default security group. So, coming back to the IEC-2 console, let’s go to the security group, and you have the default security group over here. As a result, the default security group will not permit anything. So, for simplicity, right now I’ll basically allow all the traffic from everywhere. All right? You should not be doing this in production, but just for simplicity and demo, we are allowing it temporarily. Now, once you have done that, let’s do a TerraForm plan. All right? As a result, it makes an unsupported claim. This is because of a typographical error. So instead of “private hyphen key,” it should be “private underscore key.” So let’s do a TerraForm plan. As expected, it has given us a list of resources that will be created. Things seem to be fine. Let’s create a Terraform application. I’ll say yes.
Now, once the EC-TO instance is created, the next step, if you can see it, is to run the remote exit provisioner. So here, it is basically trying to connect via SSH to the public IP address associated with the EC2 instance. And as you can see, it was able to connect. Now, once the connection was established, your provisioner was basically going ahead and installing NGINX. So this is the installation of NGINX that is happening here. Great. And now you see it says “application completed.” One resource has been added. So, in order to confirm, let’s go to the EC, for instance. So, I’ll copy the EC’s public IP address to example, and as soon as I paste it into the browser, you’ll see that you have the default engine page, which has been created. So that’s the high-level overview of remote execution provisioning. I hope you understood the aspects that are required to create a remote executable provisioner. So, with this, we’ll conclude this video. I hope this video has been informative for you, and I look forward to seeing you in the next video.
4. Implementing local-exec provisioners
Hey everyone, and welcome back. In today’s video, we’ll talk about Terraforms local EXP provider. Now the local executable provisioner basically allows us to invoke a local executable after a resource is created, so this local executioner basically executes this local executable, which is running in the workstation. Various Terraforms have been invoked, so remember that. Now, when you compare it with remote execution, Now, remote exec basically runs a piece of code inside the server. However, local execs will not run the code inside the server. It will run the code on the same machine where Terraform has been invoked from.
That is one of the distinctions between a local executive and a remote executive. Now, if you look into the sample code associated with local exec, you have the word “provisional” followed by the name of the provisioner, which is “local exec.” And then you are basically running a command, which is doing an echo. And this is basically referring to the attribute “private” associated with an easy-to-instance resource, which is stored in a file called “Private IP TXT.” So this command will run on the laptop or the workstation where you are executing Terraform from. Now one of the uses of local executive that I’ve seen in a lot of organisations is that they basically use it to run Ansible playbooks. Now that your server has been created, the local executable can invoke the Ansible playbook so that whatever contents are present there will run against the EasyToInstance that got created. So let’s do one thing. Let’s look into how we can configure a local exec provisioner.
So I have a file called local exec TF, and what we’ll do is copy a sample resource code to create an EC2 instance, all right? So this is a simple EC2 instance, and now let’s do one thing: let’s go to the official documentation of local exit. Now if you look at the example usage here, this is a simple example associated with the local exit. Let’s copy this up, and I’ll go ahead and paste it. Now if you look at the syntax, the syntax is quite similar to the remote execution where you have the provisional and you define the type of provisional, which is local execution in our case, and then you have the command, which is basically the command. Now, do remember that whatever command you are running here, make sure that it works within the workstation where you are executing Terraform from. So currently, we are basically using the echo command.
So Echo works well with Linux, but if you are running this from Windows, you have to make sure that Windows also has the Echo executable, which is available. So from my window, let’s run echo. And currently, it says “Echo is on.” That basically means the executable is currently present. So what this code will basically do is that once this EC2 instance gets created, it will take the private IP address of that EC2 instance and store it in the private underscore IP TXT. So this is the basic attribute. As a result, we’ll have to change the name. So in our case, the name that we have defined for this resource block is my EC 2. So I’ll change this aspect to my Eco, and this specific part is the attribute associated with the EC Two instance. Now that we are here, we do not really need the connection block because the local exec provisioner is not going to go ahead and connect to the easy instance. So the connection block is not needed in the local executioner.
So now let’s go ahead and do a Terraform plan and verify things are as expected. Great! You have no errors. Let’s go ahead and do a Terraform application. I’ll say yes. Great. So, once the EC2 instance is created, you will notice that the local exec provisioner has been running and is now executing the command that you have specified. So if you see “echo followed by the IP address,” that’s because So this IP address got computed, and this IP address is stored in the file called “private underscore IP TXT.” So, if you go to private underscore IPTXT from the section folder where you have the local executable TS, you will see that the private IP associated with the EC To instance is present here. So that’s the high-level overview of the Local Exec Provisioner in Terraform. I hope this video has been informative for you, and I look forward to seeing you in the next video.
5. Creation-Time & Destroy-Time Provisioners
Hey everyone, and welcome back. Now in today’s video, we’ll be discussing the Terraform provisional types. Now there are two primary types of providers that are available. The first one is called the creation time provisional.
The second is known as a destroy time provider. As a result, provisioner is only run once during the creation process and is not run again during the updating or any other lifecycle step. Now one more important part to remember is that if the creation time provisioner fails, the resource is marked as tainted. Now we’ll be doing all of this practically. So first, let’s quickly review the theoretical concept. The second is the shattered time provisioner. So the provisioner runs before the resource is destroyed via Terraform during the destroyed time period. So consider the simple case of a destroyed time provider. So this is a local executive provider within this company. Now, within local exec, you have a parameter where the key is when and the value is destroyed. When you specify this, the entire provisioner, which is the local exact provision, transforms into a destroy time provisional. And it will only run when you destroy a Terraform.
So that’s the basic idea behind both of them. So let’s quickly jump into the practical and understand it in more detail. So for today’s video, we have a few resources that we are creating. The first is the security group, which allows us to access the EC instance. Or maybe the provisioner can log into the EC2 instance, so that’s the security group. If you look into the security group here, we are allowing port 22 for connection and we are also adding an egress rule so that the EC2 instance can connect to the internet. Then we have a resource of an EC2 instance that has been created, and this EC2 instance has been associated with the security group that was created earlier, and we have a provisioner. So, as you can see in the first provisional, we’re installing the Nano editor for today’s demonstration. So this is a remote executable provisioner, and this provisioner is basically a creation-time provisioner.
We now have one more provisioner, and if you look at the provisional, it’s another remote execute with a destroy time provisional. And what we are doing here is going ahead and removing the package. So what will happen first? When the ECTO instance gets created, this provisioner will go ahead and install a nano package. And when you go ahead and destroy the EC instance, TerraForm will go ahead and remove the Nano package. Again, in the production environment, Nano may not be included in the destroy time provisioner. We used to do a variety of things, such as install an antivirus agent. So, whenever you terminate an instance, the antivirus agent is automatically uninstalled from the EC to instance, and from there, the central portal of our antivirus server removes that instance automatically. So that’s the basic idea.
So you see, you have connection parameters so that the remote user can log into the instance and run these specific commands. So, first and foremost, let’s have a full demopost that goes over everything in greater detail. Now, from the CLI, let’s go ahead and do a TerraForm plan. Great. So you see that there are two resources that it is creating. This seems to be good. Let’s create a Terraform application. We’ll simply use auto-approval. So here, when you do an auto-approve, you do not really have to manually type A. During the TerraForm, yes. Great. So our application is finished. So let’s quickly look into what exactly has been done. So first, the security group resource has been created. Once the security group is established, the EC to instance is established. Once the EC2 instance is created, you will see that TerraForm is running the remote exit, and within the remote exit, it is going ahead and installing the nano package over here. So in this case, the EC2 instance already has a nano package, but it has gone ahead and tried to install it. So that’s the basic idea behind it. Let’s clear the screen and do a Terraform Destroy, as well as an auto-approval here. Great. So now, here, you see that two resources have been destroyed. Now let’s look into what exactly Terraform has done now. So, as soon as we did a Terraform destroy, one of the first things it does is run the remote executable provisioner.
So, basically, this is the provisional destroy time, and it is going ahead and removing. So, if you will see, it is removing the nano package that has been installed. Now that the nano package has been removed, it can begin the actual server-destroying process. So it destroys the EC to begin with, and then it destroys the security group. So I hope, at a high level of overview, you understand the basics of creation-time provisioner and destruction-time provisioner. Now, within the creation time provisioner, if you look at the second point, this is a very important point that we need to know. It states that if a creation time provisioner fails, the resource is marked as tainted. and this is very important. So, if we have to return to the code for any reason, let us return to the code. So due to some reason, if this creation time provisioner fails, then the resource will be marked as tainted. So next time when you do a terraform apply, the terraform will actually go ahead and destroy the EC instance and recreate it. To simulate today’s demo, we’ll intentionally remove this Egress rule.
So if you remove this Egress rule, the EC instance will not be able to connect to the internet. So this is basically the outbound rule. So since it will not be able to communicate with the internet, it will not be able to download this specific nano package. And since the download will not happen, this specific provisional will consider it a failure, and we will look into how exactly it marks the resource as tainted. So let’s do one thing; let’s go ahead and remove this egress rule over here, and I’ll save the change. So from the CLI, first let’s quickly do a TerraForm validate to just verify if things are correct. Great. So now let’s quickly do a TerraForm application with auto approval. So now you see that you have received an error stating that the process is no longer being executed. Actually, from the error itself. So if you look into this error, it states that it could not retrieve a mirror list from this specific URL.
So you’re getting a timeout, which basically means that the EC, for example, isn’t able to communicate it within a certain amount of time. Now, from the AWS console, you will see that this is one of the instances that is terminated, which we had used for our first demo. Now there is one more easy-to-create instance that is created. In fact, this is the one that was just made. Now, if you look, it already has a security group. In fact, let’s also explore the security group here. So, within the inbound rules, you can see that it has one inbound rule of port 22, which is allowed from all, and there is no outbound rule defined. As a result, this simple example cannot connect to the internet. In fact, let me quickly show you this. So let’s quickly copy the public IP here. Now, within the folder where we are actually hosting this specific code, I already have the private key that the provisioner uses to connect to the instance, and we’ll be using the same key to login. So let’s go a bit down, I’ll clear the screen, and let’s do a SSH to the instance.
So at this stage, you can see we were able to successfully connect to the instance. But when you try to do a ping on, let’s say, Google.com, there is no data that has been responded to back. So anyway, I hope you got the basic concept here. So now that the provisioner has failed since the creation time provisioner has failed, this specific resource is marked as tainted. Now, if I have to quickly show you the TF state file here, Now if you look over here under the instance, the status is tainted. So now let’s quickly do a Terraform test to see exactly what it will do now. So you can see it now says one to destroy and one to add. Now, since the EC2 is tainted, it will go ahead and delete the instance as well as create a new one. So here it states that this specific resource must be replaced. Great. So, hopefully, you now understand the fundamentals of both provisional and destructive creation time.
6. Failure Behavior for Provisioners
Hey everyone, and welcome back. Now in today’s video, we’ll be discussing the failure behaviour in provisional. Now, by default, the provisional that will fail will also cause the TerraForm application itself to fail. We’ve already seen that if the creation time provisioner fails, the resource is automatically marked as tainted. Now, in case there is a need, you do not really need to mark the resource as tainted. So, if you want to achieve that use case in such cases, you can do so with the help of the overall failure behaviour in provisional.
There is now a specific argument of an underscore failure within the provisional. So this is the setting that we can change. So there are two allowed values here: one is “continue” and the other is “fail.” So if you do a continue, then the provisioner—even if it fails—is ignored, and the process of creation or destruction is continued. However, if the value is invalid, then it raises an error and stops applying, which again is the default behavior. So again, as we are discussing, if this is an acreage provision, it will go ahead and tame the resource. So by default, if you do not specify anything, it will consider the default value to be failed.
Now within the screenshot, if you see under the command, there is an underscore failure of “continue,” So that basically means that even if your provider has failed, it will still go ahead and continue the overall process. So let’s jump into the practical and understand this in more detail. So for today’s demo, I have a file of failure behaviour (TF). Now this file goes ahead and creates two resources, one for the security group and one for each of the EC2 instances. So this is very similar to the one that we had discussed during the creation and destruction phases of the provisional video. So here I have intentionally removed the egress rule so that we know that this specific remote executable block where it goes ahead and tries to install the nano package will go and fade because the instance will not be able to communicate with the internet. So let’s go ahead and try it out. So from this new folder where we have the TF file present, let’s quickly do a Terraform application with auto approve.
All right, so as expected, you immediately got an error with an exit status of 1. So this resource would be tainted. So let’s do one thing: let’s quickly go ahead and destroy the resource. So going back to the PPT, we know that by default the “on underscore failure” setting is failed. That is, if your provisioner fails, raise an error and stop applying. So what we’ll do now is manually add the failure setting, set it to continue, and then investigate the overall behaviour in such a case. Now going back to the CLI, our resources were destroyed. So going back to the code Let’s go ahead and add a setting over here. I’ll say that failure is underscored, and the value here would be continued. Let’s go ahead and save this. And from the CLI, let’s do a TerraForm application yet again. All right. So now here you see that even though the remote executable provisioner has failed, the application is still completed over here. So now the resource also will not be marked as tainted. So if you want to quickly verify, we can do a TerraForm plan. So now you see that it states that there are no changes in the infrastructure. So there you have it, a high-level overview of Tarapa failure behavior.
