Sumeet specializes in writing IaC using Terraform. He has over ten years of overall experience in IT and has worked with cloud and DevOps technologies for the last four years.

All post by Sumeet Ninawe - Terraform Expert

Sumeet Ninawe

Author title

Spacelift's going to AWS re:Invent in Las Vegas 🚀 🚀

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

Introducing Stack Dependencies v.2  🎉 🎉

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

Terraform

Flavius Dinu

Over time, resources that are deployed using Terraform undergo certain configuration changes. The causes may lie in the application layer and the processing logic of various automation tools and processes. This introduces the probability of resources being modified in an undesired manner.
In such situations, it is often prudent to replace these cloud resources with new instances to avoid failures resulting from misconfigurations. Since Terraform manages the cloud resource lifecycle, it also provides a solution to address this problem using CLI commands &#8211; taint, untaint, and replace.
In this post, we explore how the CLI commands &#8211; taint, untaint, and replace &#8211; help address these issues along with what is the right way to approach them with the help of an example.

In the example below, we create two <a href="https://spacelift.io/blog/terraform-ec2-instance" target="_blank" rel="noopener">EC2 instances using Terraform</a>. The resources are defined in <code>main.tf</code>.

taint

Create EC2 instances

The above diagram represents the process of creating these resources and can be summarized below.
<ol>
<li style="font-weight: 400;" aria-level="1">When we apply the configuration, Terraform validates the same with the state file hosted in the remote backend. </li>
<li style="font-weight: 400;" aria-level="1">Since these EC2 instances do not exist, it creates them in AWS and names them as &#8220;VM 1&#8221; and &#8220;VM 2&#8221; respectively.</li>
<li style="font-weight: 400;" aria-level="1">After the creation of these instances, Terraform updates the state file with the information about these two instances.</li>
</ol>

<h3>What is Terraform taint?</h3>
<a href="https://developer.hashicorp.com/terraform/cli/commands/taint" target="_blank" rel="nofollow noopener">Terraform taint</a> marks a resource as degraded or damaged, indicating that this resource will be destroyed and recreated during the next apply operation. This can be particularly useful when a resource is in an undesirable or unexpected state, but its configuration hasn&#8217;t changed. Terraform basically forces the recreation of resources even if the configuration matches the current state. 
This command is deprecated and you should use the “-replace” option of terraform apply to achieve the same behavior.
Terraform maintains a state file that contains information regarding the real-world resources managed by <a href="https://spacelift.io/blog/terraform-infrastructure-as-code" target="_blank" rel="noopener">Terraform IaC</a>. This is a crucial piece of information, as all the task executions of Terraform depend on this file for coordination.
As established earlier, when a resource becomes misconfigured or corrupt, it is desirable to replace it with a new instance. The taint command updates the corresponding resource state as a &#8220;tainted&#8221; resource so that in the next apply cycle, Terraform replaces that resource.
Note: The taint command is deprecated since Terraform version 0.15.2. If you are using a version that is lower than this, continue using taint and untaint. Otherwise, it is recommended to use the replace command discussed below.
To improve your Terraform workflow, see the <a href="https://spacelift.io/blog/terraform-best-practices" target="_blank" rel="noopener">Terraform Best Practices</a>.
<h3>How to use Terraform taint</h3>
Let us assume our development teams and various business users are using these VMs for their purposes. The operations team happens to perform certain changes on these instances, which has caused VM 1 to have undesirable behavior.
The reasons could be anything &#8211; the changes in the configuration might have exposed VM 1 to security vulnerabilities, or certain processes could be performing particularly slowly, prompting the number of requests processed by this EC2 instance to be lower compared with its peers, etc.

taint3

Terraform Taint

In this case, instead of recreating the entire infrastructure, it would be easier to replace only VM 1, which causes the issue. We can do this by using Terraform’s taint command. By specifying which resource to be marked as tainted, we let Terraform know about the faulty resource in the state file.
To mark the resource as tainted, run the below command in the terminal. The taint command takes the resource identifier as the parameter to understand which resource needs to be marked as tainted.

The output above confirms that VM 1 has been marked as tainted and will be replaced in the next apply cycle. To verify the same, run the <code>terraform plan</code> command and observe the output.

At the beginning of the output, we can see that Terraform has taken note of the <code>aws_instance.my_vm_1</code> as tainted and is prepared to replace the same. This is currently reflected only in the state file, and no action has been performed in AWS.
Run <a href="https://spacelift.io/blog/terraform-apply" target="_blank" rel="noopener"><code>terraform apply</code></a> now, and see what happens to VM 1.

instances-terraform-taint

instances - terraform taint

If we look at the AWS EC2 console, we can see that one EC2 instance named VM 1 is terminated, and another one with the same name is being created. This process is represented in the diagram below.

taint4

VM 1 is terminated

<ol>
<li style="font-weight: 400;" aria-level="1">The developer marks the resource as tainted using the taint command.</li>
<li style="font-weight: 400;" aria-level="1">Terraform updates the state file accordingly. The same is seen in the plan output above.</li>
<li style="font-weight: 400;" aria-level="1">The developer executes the same configuration by running <code>terraform apply</code>.</li>
<li style="font-weight: 400;" aria-level="1">This destroys tainted VM 1.</li>
<li style="font-weight: 400;" aria-level="1">This is followed by the creation of a new instance of VM 1.</li>
<li style="font-weight: 400;" aria-level="1">Terraform updates the state file by removing the older VM 1 object and replacing it with a new VM 1 EC2 instance.</li>
</ol>

<h3>Count and for_each example</h3>
Let’s suppose you are using <code>count</code> to create your resources and you want to taint only one of them.

At a <code>terraform plan</code>, you are going to see three resources, for a count equal to three, so in order to taint the first one, for example, what you have to do is:

If you are using <code>for_each</code>, things will get a little more complicated when it comes to the tainting syntax. This is happening because you will need to use some escape characters for when you are specifying the keys.

Just as before, we are going to see three resources at a terraform plan. If we want to taint the instance that has instance2 as the key, we simply:

<ul>
<li><a href="https://spacelift.io/blog/github-actions-terraform" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Scale Terraform Deployments with GitHub Actions &quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Scale Terraform Deployments with GitHub Actions</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Automating Infrastructure Deployment Using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Automating Infrastructure Deployments Using Terraform</a></li>
<li><a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Infrastructure Drift Detection and How to Fix It With IaC Tools&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Infrastructure Drift Detection and How to Fix Drift</a></li>
</ul>

<h3>What is Terraform untaint?</h3>
<a href="https://developer.hashicorp.com/terraform/cli/commands/untaint" target="_blank" rel="nofollow noopener">Terraform untaint</a> is the opposite operation of Terraform taint. If a resource has been marked as taint which signifies it will be recreated in the next apply, the untaint command will remove this mark, ensuring the resource stays unchanged in the following operations. 
This is useful when resources have been marked as taint by mistake, or if there are changes in operational decisions. As the taint workflow is deprecated, if you are not using it at all, the untaint command will also be obsolete.
<h3>How to use Terraform untaint</h3>
In the current example, let us mark VM 2 as tainted to prove the above. Run the command below in the terminal.

To confirm if VM 2 is marked as tainted, run plan command and observe the output as below.

The EC2 instance named VM 2 is now tainted. If this was a mistake, then we can revert this by using the untaint command as below.

Like taint, a resource identifier is also supplied to untaint command. Confirm the same by running <code>terraform plan</code> command and making sure the plan does not suggest replacement.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Tainting a resource until it is replaced by explicitly executing apply command makes the terraform workflow vulnerable in this brief period.
As we have seen in the example above, when we mark the resource as tainted using the taint command, it modifies the state file but does not make sure the changes are applied. In a shared development environment, if another developer generates and executes a plan at this time &#8211; the target EC2 instance will be replaced.
This is an unintentional change. The resource was marked as tainted by one developer but was replaced due to the apply statement executed by another developer. 
In our example, we are dealing with only a couple of EC2 instances. The changes thus made are still noticeable and can be avoided. But in real-world implementations where the entire infrastructure is being developed by teams, the risk of avoiding these unintentional replacements increases.
Starting with Terraform version 0.15.2 and onwards, the taint command is deprecated, and it is suggested to use apply command with the <code>-replace</code> flag. Let us discuss this in the next section.

Terraform replace is a flag used with the Terraform apply command and is the suggested way to force Terraform to recreate specific resources. As the name suggests, it replaces the specified resource. Its value defines the resource identifier that should be replaced with the existing configuration mentioned in the same Terraform code.
<h3>How to use Terraform replace</h3>
Using replace eliminates the time between marking the resource as tainted and applying those changes. Thus it avoids the drawback discussed in the previous section. Let us replace VM 2 in our example by running the below command.

The output above confirms that Terraform replaces the target resource in a single step.

I hope this blog post was helpful to you in understanding and exploring the CLI commands &#8211; taint, untaint, and replace.
If you are struggling with Terraform automation and management, check out <a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a>. Get started on your journey by signing up for a <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">free trial</a> and taking it for a spin worldwide!
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu is not going to have its own providers and modules, but it is going to use its own registry for them.

Build more complex workflows based on Terraform using policy as code, programmatic configuration, context sharing, drift detection, resource visualization and many more.

Initialize/ plan/ apply your IaC, manage modules, state, and more. 

frame-8479

Frame 8479

20 Terraform Best Practices to Improve your TF workflow

5 Ways to Manage Terraform at Scale - Best Practices

Terraform Cheat Sheet - 23 Terraform CLI Commands & Examples

Learn the right way to approach the Terraform CLI commands - taint, untaint, and replace, with examples. Avoid failures resulting from misconfiguration.

91-terraform-taint

Terraform taint, untaint, and replace

Terraform Taint, Untaint, Replace - How to Use It (Examples)

Terraform is a product by Hashicorp that uses Infrastructure as Code (IaC) to provision cloud infrastructure.
In this tutorial, we will learn step-by-step how to use Terraform, enabling you to manage cloud infrastructure with IaC.
<div class="p-rich_text_section">This Terraform tutorial includes:</div>
<ol class="p-rich_text_list p-rich_text_list__ordered" data-stringify-type="ordered-list" data-indent="0" data-border="0">
<li data-stringify-indent="0" data-stringify-border="0"><a href="https://spacelift.io/blog/terraform-tutorial#the-benefits-of-using-terraform">The Benefits of Using Terraform</a></li>
<li data-stringify-indent="0" data-stringify-border="0"><a href="https://spacelift.io/blog/terraform-tutorial#terraform-features">Terraform Features</a></li>
<li data-stringify-indent="0" data-stringify-border="0"><a href="https://spacelift.io/blog/terraform-tutorial#installation-and-setup">Installation and Setup</a></li>
<li data-stringify-indent="0" data-stringify-border="0"><a href="https://spacelift.io/blog/terraform-tutorial#terraform-providers">Terraform Providers</a></li>
<li data-stringify-indent="0" data-stringify-border="0"><a href="https://spacelift.io/blog/terraform-tutorial#resources">Resources</a></li>
<li data-stringify-indent="0" data-stringify-border="0"><a href="https://spacelift.io/blog/terraform-tutorial#terraform-cli">Terraform CLI</a></li>
<li data-stringify-indent="0" data-stringify-border="0"><a href="https://spacelift.io/blog/terraform-tutorial#terraform-variables">Terraform Variables</a></li>
<li data-stringify-indent="0" data-stringify-border="0"><a href="https://spacelift.io/blog/terraform-tutorial#state-management">State Management</a></li>
<li data-stringify-indent="0" data-stringify-border="0"><a href="https://spacelift.io/blog/terraform-tutorial#remote-backends">Remote Backends</a></li>
</ol>

Traditionally, without IaC, the cloud infrastructure was managed manually. This was not the most efficient way and was prone to manual errors. Consistency was a challenge, especially when many servers and clusters were to be managed.
Configuration management tools existed, but the infrastructure&#8217;s support was very limited. Application code development and management of that code has evolved a lot with versioning tools, DevOps toolchains, development practices, and delivery methodologies. Terraform introduced the concept of <a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">Infrastructure as Code</a>, which by default leverages these advantages to managing infrastructure. 
Let us take a look at a few of the benefits Terraform has to offer.
<table>
<tbody>
<tr>
<td>Benefits</td>
<td>Description</td>
</tr>
<tr>
<td>Consistency
&nbsp;</td>
<td>With infrastructure being managed via code, it becomes very easy to version and track changes. Since cloud resource provision happens logically, we can rely on its consistency to create a scaled set of infrastructure.
&nbsp;</td>
</tr>
<tr>
<td>Automation
&nbsp;</td>
<td>Terraform workflow manages <a href="https://spacelift.io/blog/terraform-resource-lifecycle" target="_blank" rel="noopener">the lifecycle</a> of cloud resources &#8211; from their creation till they are destroyed or decommissioned. This provides an opportunity to enable end-to-end automation right from the infrastructure layer. Automation workflows also assist in strengthening deployment strategies. Read more about: <a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">Terraform automation</a>.
&nbsp;</td>
</tr>
<tr>
<td>Less Risk
&nbsp;</td>
<td>Using Terraform to develop infrastructure as code provides validation beforehand. I also isolates manual efforts and errors associated with it. Thus once developed, infrastructure provisioning and de-provisioning cycles execute identically.
&nbsp;</td>
</tr>
<tr>
<td>Modular and DRY
&nbsp;</td>
<td>Infrastructure can be developed in a modular way so that it can be reused across multiple projects. This approach also enables organizations to ingrain their security and governance practices around infrastructure resources, thus offsetting the initial efforts spent every time a new project kicks off.
&nbsp;</td>
</tr>
</tbody>
</table>
<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Added: Take a look at 8 Popular Terraform Alternatives.&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">You can also take a look at <a href="https://spacelift.io/blog/terraform-alternatives" target="_blank" rel="noopener">9 Popular Terraform Alternatives</a>.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu works with your existing Terraform state file, so you won’t have any issues when you are migrating to it.

Some of the key features of Terraform are
<table>
<tbody>
<tr>
<td>Feature       </td>
<td>Description</td>
</tr>
<tr>
<td>Declarative
&nbsp;</td>
<td>Terraform uses Hashicorp Configuration Langauge which provides a declarative syntax to develop infrastructure as code. The HCL configuration language helps declare the target state of cloud resources to be provisioned.
&nbsp;</td>
</tr>
<tr>
<td>Cloud Agnostic
&nbsp;</td>
<td>Terraform is a great tool to automate <a href="https://spacelift.io/blog/multi-cloud-infrastructure-strategy" target="_blank" rel="noopener">multi-cloud deployments</a>. Its modular architecture enables working with multiple well-known cloud vendors simultaneously.
&nbsp;</td>
</tr>
<tr>
<td>Ecosystem
&nbsp;</td>
<td>The provider and module ecosystem of Terraform is well established. Certified modules and <a href="https://spacelift.io/blog/terraform-providers" target="_blank" rel="noopener">providers</a> are available on Terraform Registry to be readily used. Customers can create and publish their own modules both publicly and privately.
&nbsp;</td>
</tr>
<tr>
<td>Extendible
&nbsp;</td>
<td>Terraform can be extended to support lesser-known or private data centers.
&nbsp;</td>
</tr>
<tr>
<td>Agentless
&nbsp;</td>
<td>Terraform works with the programmatic access provided by cloud provider APIs. Thus there is no need to install agents.
&nbsp;</td>
</tr>
</tbody>
</table>
With that in mind, let us get our hands dirty by installing and setting up our Terraform environment.

<h3>Terraform</h3>
Terraform comes in two forms: open source and Terraform Cloud. <a href="https://spacelift.io/blog/what-is-terraform-cloud" target="_blank" rel="noopener">Terraform Cloud</a> is an online hosted platform that provides a UI for automation of provisioning tasks and management, but the code still needs to be manually developed.
You can also check out <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a>, a sophisticated and compliant infrastructure delivery platform that makes Terraform management easy.
For the sake of this tutorial, we would work with an open-source version that offers all of the same features for self-hosting. The Terraform binary can be downloaded from the <a href="https://www.terraform.io/downloads" target="_blank" rel="nofollow noopener">Terraform website</a>.

install-terraform-terraform-tutorial

Download Terraform

Choose the OS and package manager or binary download option as per the choice of your system. The screenshots in this tutorial are based on macOS. Apart from the setup, the steps described in this tutorial are the same across all the operating systems.
If you need more details, see a complete guide on <a href="https://spacelift.io/blog/how-to-install-terraform" target="_blank" rel="noopener"> downloading and installing Terraform on Windows, Linux, and macOS</a>.
The installation steps generally consist of downloading the appropriate binary and setting up the path variable. Once installed successfully, test if the installation works by checking the version below. When writing this tutorial, the latest version of Terraform was v1.2.3.

The code for this tutorial is available at this <a href="https://github.com/sumeetninawe/tf-tuts" target="_blank" rel="nofollow noopener">github repository</a>.
<h3>AWS CLI</h3>
Since we will be working with AWS to provision our infrastructure using Terraform, we also need to install AWS CLI. Follow the steps listed <a href="https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html" target="_blank" rel="nofollow noopener">here</a>, to install the latest version of AWS CLI for your OS. After a successful installation, check the version of AWS CLI as shown below. When writing this tutorial, the latest AWS CLI version was 2.7.9.

Terraform uses AWS CLI to make API calls to execute any provisioning task. Log in to AWS Web Console and create a user for Terraform. The user needs programmatic access to AWS, so check the corresponding checkbox only.

installing-aws-cli-terraform-tutorial

installing AWS CLI

For now, provide the administrative role to this user. However, it is recommended to follow the principle of least privilege when working on projects.

setting-premissions-terraform-tutorial

Set permissions

Once the user is successfully created, take a note of the Access Key ID and Secret Access Key.

access-key-terraform-tutorial

Access Key ID and Secret Access Key

We need to configure these credentials in the AWS CLI we just installed. Open the terminal and run the <code>aws configure</code> command to configure default credentials. I have left the region as the default value since I am using the same. Select the region of your choice if required.

With this, we have successfully set up our environment to begin working with Terraform and AWS.
Note: Terraform is able to make API calls without AWC CLI if you hardcode credentials or use some other method to access AWS.

Terraform implements a modular approach in its application architecture. The Terraform binary we downloaded is the core module required to perform core Terraform functions. Any operation or a CLI command that does not involve invoking any cloud provider API are core functions of this binary.
To work with a cloud provider, AWS in our example, Terraform instantiates a corresponding module. It downloads the binary in the root directory of the project. We instruct Terraform to use a specific version of the <a href="https://spacelift.io/blog/terraform-aws-provider" target="_blank" rel="noopener">AWS provider</a> so that our Terraform project can provision AWS resources.
Now is the time to create our Terraform project. Create a directory in your system and open this path into an IDE of your choice. All the Terraform code goes into <code>.tf</code> files created in the root of this directory. Create the first file named <code>provider.tf</code> into this empty directory and write the provider block as below.

As mentioned before, Terraform uses HCL syntax. A declarative configuration language that helps us declare the cloud resources we want to provision using Terraform. In the <code>provider.tf</code> file, we have specified a terraform block, within which we have declared another block that represents <code>required_providers</code>. 
<code>required_providers</code> contains an attribute <code>aws</code> to which an object with a couple of properties is assigned. These properties define the <code>source</code> and desired <code>version</code> of the AWS provider. Provider-specific documentation is maintained in the registry. To check the <a href="https://registry.terraform.io/providers/hashicorp/aws/latest" target="_blank" rel="nofollow noopener">latest version</a> of the available provider and configure various types of resources with AWS, refer to the <a href="https://registry.terraform.io/" target="_blank" rel="nofollow noopener">Terraform registry</a>.
The above code instructs Terraform to initialize the AWS provider with version 4.19.0. Save the <code>provider.tf</code> file. To initialize our Terraform project, run <a href="https://spacelift.io/blog/terraform-init" target="_blank" rel="noopener"><code>terraform init</code></a> command in the root directory and observe the output as below.

As we can see, Terraform has successfully initialized the desired version of the AWS provider. If we look at our root directory, here is what it contains.

provider-tf-terraform-tutorial

provider.tf

Apart from <code>provider.tf</code> and README.md file, we have <code>.terraform.lock.hcl</code> file and a sub-directory named <code>.terraform</code>. The lock file here is used to manage checksums for the downloaded module binaries, which we will discuss in the next sections. <code>.terraform</code> sub-directory is the target where AWS provider plugin binary is downloaded. If you have followed the steps successfully till now, this is how your directory should look.
At this point, we have set up the Terraform provider, and now we would move on to create some resources in our AWS console using Terraform.

Create another file named <code>main.tf</code> in the same directory. The intention of creating this file is to declare the resources we want to create in AWS. It is completely okay to skip creating this file and just append <code>provider.tf</code> file with the below code. However, creating separate files helps manage the Terraform code in a better way. Add the below code to <code>main.tf</code> file.

Here we have declared a resource block of type “<code>aws_instance</code>”. This instructs Terraform that we want to create an EC2 instance resource in AWS with given attributes. <code>aws</code> in <code>aws_instance</code> helps Terraform identify the provider it would require to perform this provisioning task.
Note: To identify the correct resource type and associated attributes, refer <a href="https://registry.terraform.io/" target="_blank" rel="nofollow noopener">Terraform Registry</a>.
The second parameter is “<code>my_vm</code>”, which is an internal identifier. Its purpose is to refer to this particular EC2 instance elsewhere in the code. We can assign any name to this identifier.
Amongst the resource attributes, we have declared the <code>ami</code> &#8211; which defines the image we want to use to create this EC2 instance. The chosen AMI here is an Ubuntu image in Central Europe. We have also specified the <code>instance_type</code> to define the size of the EC2 instance to be created.
Additionally, we have assigned a <code>tag</code> “Name” with the value “My EC2 Instance”.
With this, we have successfully created the code to create an EC2 instance in AWS using Terraform.

We have created the Terraform code to provision our AWS resources, but we have not yet provisioned them. This is what we would do in this section. Let us take a look at some of the important Terraform CLI commands, that also help us understand the resource lifecycle managed by Terraform.
<h3>Format (<code>fmt</code>)</h3>
Assuming we have already written some Terraform code with correct syntax, it may still lack proper indentations. A properly indented code is very valuable as it improves readability. <code>terraform fmt</code> command helps us format the Terraform code for all <code>.tf</code> files in the given directory.
In your project directory, where you have created the <code>main.tf</code> and <code>provider.tf</code> files, run <code>terraform fmt</code> to achieve well-formatted Terraform code in microseconds.

It outputs a file name &#8211; <code>main.tf</code>. On closer observation, in the <code>main.tf</code> file, in the code we created before, the attributes &#8211; although aligned as per the positioning of “=” sign, there are unnecessary spaces between the name and the “=” sign. Now that we have formatted the code, these spaces are removed.
The output just represents a list of all those files which are reformatted by <code>fmt</code> command.
<h3>Initialize (<code>init</code>)</h3>
We have already worked with this command before. Usually, this command is run only at the beginning of a Terraform project &#8211; as far as we stick with the same provider. However, if we decide to add more providers, or change the version of existing ones and try to execute the Terraform code without initializing &#8211; it throws an error. For new developers, this is a common step that is missed.
In our <code>provider.tf</code> file, change the version attribute of <code>aws</code> from “4.19.0” to “4.18.0” and run <code>terraform plan</code> command in the console.

As it must be clear from the error message, Terraform identifies this change and asks us to initialize this directory again to update the appropriate provider module. Run <code>terraform init -upgrade</code> now.

Thus, running <code>init</code> command with the -upgrade flag has helped us match the version of the provider module to be used.
<h3>Plan (<code>plan</code>)</h3>
Plan command helps us validate the resource declaration we have done using Terraform. It takes into account all the Terraform configuration files and identifies any syntax errors, version miss-match errors (like above), etc.
Additionally, it validates the code with the state file (discussed further) to identify and highlight resources that are to be created, updated, or deleted if we choose to execute the current version of the code. It is a great way to have a snapshot of changes before we apply them to the target set of infrastructure.
In our code directory, run <code>terraform plan</code> and observe the output.

There is quite a lot of information provided in the output here. In summary, it highlights all the resources which will be created. Since this is the first time we are going to run the code &#8211; there are no changes or deletions highlighted. The plan summary at the end of the output is a good way to match the stats when we deal with a larger set of resources.
Read more about <a href="https://spacelift.io/blog/terraform-security-group" target="_blank" rel="noopener">Terraform security groups</a>.
<h3>Apply (<code>apply</code>)</h3>
Now that we have verified the actions that Terraform will perform if we choose to execute this code, let us go ahead and create these resources. <code>terraform apply</code> command helps us provision all the resources we have declared in the <code>main.tf</code> file. When you run <code>terraform apply</code>, it again highlights the output similar to the <code>plan</code> command, and asks for our final confirmation as below:

Type in ‘yes’ and hit enter.

Terraform starts to provision the EC2 instance with the attributes we have specified. For all those attributes which are not specified, it assumes the default value. As seen from the output, it took 31 seconds for Terraform to successfully provision our EC2 instance. Verify the same by logging into your AWS console.

provision-ec2-instance-terraform-tutorial

EC2 instance

Under the hood, Terraform uses the AWS provider plugin, which in turn makes programmatic API calls to AWS using the credentials we configured during setup.
Congratulations, if you have managed to reach this point!
<h3>Destroy (<code>destroy</code>)</h3>
Terraform manages the lifecycle of infrastructure. This also means, that if it is responsible for the creation of a particular resource, it is also responsible for its deletion or destruction. Terraform destroy command helps us delete all these resources completely.
To delete the EC2 instance created using <code>apply</code>, run <a href="https://spacelift.io/blog/how-to-destroy-terraform-resources" target="_blank" rel="noopener"><code>terraform destroy</code></a> to terminate the same instance as below.

Here, it again asks for our confirmation with an output that highlights the resources which will be deleted. If we choose to say anything other than ‘yes’, Terraform will abort this operation. Since the plan summary correctly indicates that one resource will be destroyed &#8211; which is as per our expectations &#8211; let us go ahead and confirm the deletion.

As we can see, Terraform has successfully deleted the EC2 instance. Verify the same from the AWS EC2 console.

delete-ec2-instance-terraform-tutorial

delete EC2 instance

Till now we have been able to create and destroy AWS EC2 instances using Terraform. Terraform commands we just discussed are the most important commands which every developer should be aware of. These commands are vital, in the way that they define the complete end-to-end lifecycle of the resources being managed via Terraform.

<ul>
<li><a href="https://spacelift.io/blog/terraform-best-practices" target="_blank" rel="noopener">20 Best Practices for Using Terraform</a></li>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments and Infrastructure Provisioning</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">How to Improve Your Infrastructure as Code using Terraform</a></li>
</ul>

Variables plan an important role when dealing with Terraform projects. So far we have hardcoded all the values like AMI, Instance Type, and Tags, required to provision our EC2 instance. Imagine doing this for multiple resources &#8211; EC2 instances with various configurations, RDS instances, VPCs, etc. &#8211; this approach can quickly become cumbersome.
Variables introduce the much-needed flexibility and dynamics required to manage larger sets of infrastructure. Variables also play an important role when applying the DRY (don’t repeat yourself) principle when creating modules. We will discuss modules in the upcoming sections.
There are mainly three types of variables &#8211; local, input, and output. We will discuss this one by one.
<h3>Local variables</h3>
As the name suggests, these are locally declared variables. These variables provide a name for any attribute value that is to be used anywhere in the Terraform code. <a href="https://spacelift.io/blog/terraform-locals" target="_blank" rel="noopener">Local variables</a> are especially useful if we were to refer to these values in multiple places in our Terraform code. We can perform various operations to calculate these values based on multiple other values as well.
For the sake of our example, we keep it simple. Create a file named <code>variables.tf</code> in the root directory and declare the local variables as below.

Here we have declared all the hardcoded values into their corresponding local variables. Local variables, once declared, can be referred to anywhere within the module. To refer to these variables in our <code>main.tf</code> file, use the syntax <code>local.&lt;variable_name&gt;</code> at appropriate places. After the changes are done to <code>main.tf</code> reflect usage of variables in main.tf file, it should look like below.

To verify if we have correctly declared and referred local variables in our code, run <code>terraform plan</code> and observe that it does not throw any error. At this moment, it is enough to rely on the planned output for verification.
<h3>Input Variables</h3>
At times, there are situations where the values are to be provided to for the execution of code during run time. Local variables only work locally, they lack the ability to accept and assign values dynamically during runtime. 
Input variables provide this function. This ability also helps us define input values for modules to accept values on the go from the parent module.
Let us redefine our <code>variables.tf</code> file with input variables instead of <code>locals</code> for the same attributes.

We have created three variables &#8211; all of the type string &#8211; and provided them with descriptions. Description of input variables helps in generating documentation if we decide to publish this as a module on Terraform registry. Do the corresponding changes to <code>main.tf</code> file to use input variables instead of locals.

When we run <code>terraform plan</code> command at this point, it validates the code successfully. However, try to run <code>terraform apply</code> and observe the output.

Here Terraform asks to provide the value for ‘Ubuntu AMI ID’, and it would ask the same for the other two variables consecutively. This is just to prove that Terraform allows us to provide these values dynamically during runtime.
If we want to avoid supplying values one by one in CLI, we can declare default values in the same <code>variables.tf</code> file as shown below.

Now if we run <code>terraform apply</code>, it will automatically assume the default values provided in this file and proceed towards provisioning of the EC2 resource.
A better way to manage these default values is to create another file named <code>terraform.tfvars</code>. Terraform automatically interprets this file as a group of key-value pairs and maps them with the declared variables in the <code>variables.tf</code> file.
Clear out all the default values from <code>variables.tf</code> file and create <code>terraform.tfvars</code> file as shown below. The syntax is quite straightforward &#8211; on every line, there is a key assigned with a value.
Let us try to run <code>terraform plan</code> command at this point. As we can see, Terraform indicates a successful plan output.
Note: The name <code>terraform.tfvars</code> is a prerequisite. If we choose any other name before <code>.tfvars</code> extension then the file needs to be explicitly supplied in the CLI command with the -var-file flag. Optionally, we can also use the <code>.auto.tfvars</code> extension so that Terraform can pick this file automatically to read variable values.
<h3>Output Variables</h3>
Till now we have been able to create EC2 instances using Terraform code and CLI commands. However, to get the details about that EC2 instance we log in to the AWS Console and see the required attributes.
<a href="https://spacelift.io/blog/terraform-output" target="_blank" rel="noopener">Output Variables</a> provide a way to retrieve the details we are interested in, in the same CLI terminal. Additionally, output variables help &#8220;return” values to the parent modules for further processing. 
We define output variables in the same variables.tf file. In general, you can define Output or Input variables in any .tf file and they will be interpreted by Terraform as far as they reside in the working directory.
Let’s say we are interested in knowing the public IP and Instance ID of the EC2 instance which will be provisioned. We declare the output variables as below. Append the below code in the variables.tf file.

Run terraform apply and observe the output.

The plan output now also indicates the values which will be known after <code>apply</code>. It chooses to display these values because we have declared their corresponding output variables. Add more output variables to know more about your instance after provisioning.
Run terraform apply to see the values being generated.

As we can see, Terraform has successfully provisioned the EC2 instance and we also have the instance ID and public IP information handy. We did not have to log in to the AWS console to find the same.
Note: As far as the naming convention of the files is concerned, apart from .tfvars, there is no constraint for naming these files like we have done until now. You could name them as per your wish &#8211; Terraform considers all the files with <code>.tf</code> extension in any given directory. The names <code>provider</code>, <code>variables</code>, and <code>main</code> are generic conventions used in the ecosystem.

State management in Terraform is one of the crucial things to know and learn about especially when working with teams. In this section, we dive deep into understanding how state files in Terraform work and the impact it creates on the resource lifecycle management workflow, which then offers a great introduction to the next section about remote backends.
Until now we have created multiple files and if we look at our root directory, the system/Terraform seems to create a few more files. Now is the right time to revisit them.

tf-state-terraform-tutorial

tfstate

We have already discussed the <code>.terraform</code> directory, <code>.terraform.lock.hcl</code> file, <code>main.tf</code>, <code>provider.tf</code>, <code>variables.tf</code>, and <a href="https://spacelift.io/blog/terraform-tfvars" target="_blank" rel="noopener"><code>terraform.tfvars</code></a> files. By now we know the purpose of these files. The two new files created are &#8211;
<ol>
<li style="font-weight: 400;" aria-level="1"><code>terraform.tfstate</code> </li>
<li style="font-weight: 400;" aria-level="1"><code>terraform.tfstate.backup</code></li>
</ol>
As a quick recap of our journey till now, we have set up the <a href="https://spacelift.io/blog/terraform-environments" target="_blank" rel="noopener">Terraform environment</a> and declared the configuration/code to create an EC2 instance in AWS. We also destroyed the resource which we created in this process. We have seen how Terraform performs these operations under the wraps and updates the status in the CLI terminal.
Notice how Terraform only works with the resources created using Terraform alone. AWS resources that are created using Terraform &#8211; only those resources are destroyed. If we had multiple EC2 instances existing before the one created by Terraform, those resources will not be affected.
Terraform manages only those resources that the code written by us creates. For this, Terraform maintains the mapping information regarding the resources defined in the configuration and their corresponding real-world cloud entities. This mapping is saved in the state files.
<code>Terraform.tfstate</code> file thus maintains this mapping which in turn helps Terraform to identify the current state of the resources which are already provisioned, and the resources yet to be provisioned, or to be deleted.
When configuring infrastructure as code using Terraform’s declarative language, we essentially define the desired target state of the infrastructure. Any modifications to this code &#8211; addition or removal of resources &#8211; define the newer target state.
With Spacelift, you can <a href="https://docs.spacelift.io/vendors/terraform/infracost" target="_blank" rel="noopener">get insight</a> into application state, resource usage, changes, and more.
When the modified configuration is executed, i.e. terraform plan/apply command is run &#8211; Terraform compares the modifications made with the state files, for the corresponding existence in the real world.
If additional resources are found in the configuration, Terraform plans to provision those resources in the next <code><code>apply</code></code> command execution. Whereas, if lesser resources are encountered, Terraform identifies the removed resources by comparing the configuration with the state file and plans to destroy them.
Thus, the State file &#8211; <code>terraform.tfstate</code> &#8211; is an extremely important piece of information maintained by Terraform itself. The <code>.terraform.tfstate.backup</code> file &#8211; as the name suggests, the backup file holds the previous execution&#8217;s backup.
Note: Terraform CLI offers various commands to query and modify state information. These commands are directly related to this state file. It is recommended to avoid any manual changes as that approach is risk-prone. Always use the state manipulation commands for operations related to the state file.
<h3>State lock file</h3>
However, there is one more file involved in all of this &#8211; <code>.terraform.tfstate.lock.info.</code> We do not have it in the previous screenshot. Its existence is temporary and it only exists when <code>plan</code>, <code>apply</code>, or <code>destroy</code> commands are being executed.
To observe this behavior, run <code>terraform apply</code> in the root directory of our project and do not enter anything when Terraform asks for the confirmation step below.

Hold on to this moment, and observe the file directory.

file-directory-terraform-tutorial

file directory

Here we can see <code>.terraform.tfstate.lock.info</code> file is created automatically. If you now enter ‘yes’, this file exists for the duration until Terraform successfully provisions these resources. Similar behavior is observed for the <code>destroy</code> command.
The purpose of this lock file is to avoid race conditions. Imagine a scenario where Terraform environment is created in a shared VM and multiple developers try to apply their changes simultaneously. For Terraform to decide and execute the applied changes in a particular sequence, it uses this lock file.
You can stay on top of everything you’re responsible for with Spacelift &#8211; helping you <a href="https://docs.spacelift.io/concepts/resources" target="_blank" rel="noopener">visualize your resources</a>, <span data-slate-fragment="JTdCJTIyb2JqZWN0JTIyJTNBJTIyZG9jdW1lbnQlMjIlMkMlMjJkYXRhJTIyJTNBJTdCJTdEJTJDJTIybm9kZXMlMjIlM0ElNUIlN0IlMjJvYmplY3QlMjIlM0ElMjJibG9jayUyMiUyQyUyMnR5cGUlMjIlM0ElMjJwYXJhZ3JhcGglMjIlMkMlMjJpc1ZvaWQlMjIlM0FmYWxzZSUyQyUyMmRhdGElMjIlM0ElN0IlN0QlMkMlMjJub2RlcyUyMiUzQSU1QiU3QiUyMm9iamVjdCUyMiUzQSUyMnRleHQlMjIlMkMlMjJsZWF2ZXMlMjIlM0ElNUIlN0IlMjJvYmplY3QlMjIlM0ElMjJsZWFmJTIyJTJDJTIydGV4dCUyMiUzQSUyMnJlZ2FyZGxlc3MlMjBvZiUyMHRoZSUyMHRlY2hub2xvZ3klMjB1c2VkJTIwJTIyJTJDJTIybWFya3MlMjIlM0ElNUIlNUQlMkMlMjJzZWxlY3Rpb25zJTIyJTNBJTVCJTVEJTdEJTVEJTJDJTIya2V5JTIyJTNBJTIyMmU4NDI2MDJiNjUzNDE4ZGEzYmFjY2E1ZDhkYzY2OWQlMjIlN0QlNUQlMkMlMjJrZXklMjIlM0ElMjJlODcxNjcxY2RkZDE0YWU5ODJlZDQ5MmJiZjg5N2ZjOCUyMiU3RCU1RCUyQyUyMmtleSUyMiUzQSUyMmM3OGZlMDFiN2Y3YzRhNzViODVhZjBiNzFmMjZhOWJlJTIyJTdE">regardless of the technology used.
If we take a look at the lock file, it contains information in the JSON format as below. IT contains information about current execution &#8211; ID, Time when the execution is triggered, Who triggered it, Path to the state file etc.

Any request that is prioritized to be executed, creates this temporary information set &#8211; stored in <code>terraform.tfstate.lock.info</code> file &#8211; and temporarily puts on hold any other request till the current execution is completed.
Such simultaneous requests for Terraform’s execution is a very rare and rather non-suggested scenario, and the Terraform seems to have a fallback in the form of such a locking mechanism.
However, even if it is so when working in the team setup, this falls short of avoiding corruption in the resource configuration. In the next section, we will see why and how remote backends help address this issue.

The state files we discussed in the previous section reside in the same directory where the rest of the Terraform code is being developed. This is said to use a ‘local backend’. It works well if only one developer controls/contributes to the infrastructure being developed.
Another issue with working in local mode is &#8211; version control of the code itself. To leverage the advantage offered by version controlling systems like Git, it becomes risky to make state files part of the same remote git repository.
In a team where multiple developers are responsible for developing the Terraform code if we decide to commit the state file to the remote Git repo &#8211; causes variations in the state being stored locally by each developer. Multiple developers contributing to this repository can commit their own versions of state files. 
When pulled by other developers, it causes inconsistency. This results in corruption of state files and Terraform may end up creating unnecessary orphan resources or unnecessarily destroying required resources. This can cause a serious problem when the team is large enough and the set of infrastructure being developed is huge.
Additionally, state files may also contain sensitive information like credentials and keys, which can be risky to be stored in remote repositories.
Remote backends solve these problems. Using a remote backend essentially means using a separate storage service to securely store state files independently. Of course, this does not mean using remote Git repositories.

terrafrorm-tutorial-diagram

terrafrorm tutorial diagram

When we introduce a remote backend in the Terraform development workflow, the development may follow the below workflow.
<ol>
<li style="font-weight: 400;" aria-level="1">Multiple developers have copies of the Terraform code from remote Git repositories available locally. They make their changes and push these changes back to the remote Git repository.</li>
<li style="font-weight: 400;" aria-level="1">They execute <code>terraform plan</code> command from their local environment. This causes 
<ul>
<li style="font-weight: 400;" aria-level="2">Terraform to apply the lock over the state file in the remote backend.</li>
<li style="font-weight: 400;" aria-level="2">Query for state information.</li>
<li style="font-weight: 400;" aria-level="2">Perform validation and present the plan.</li>
<li style="font-weight: 400;" aria-level="2">Release the state file lock.</li>
</ul>
</li>
<li style="font-weight: 400;" aria-level="1">They execute <code>terraform apply</code> command from their local environment. This causes
<ul>
<li style="font-weight: 400;" aria-level="2">Terraform to apply the lock over the state file in the remote backend.</li>
<li style="font-weight: 400;" aria-level="2">Query for state information.</li>
<li style="font-weight: 400;" aria-level="2">Identify the differences.</li>
</ul>
</li>
<li style="font-weight: 400;" aria-level="1">Terraform applies the changes in the configuration to the cloud provider.</li>
<li style="font-weight: 400;" aria-level="1">Upon successful execution, Terraform releases the lock over the state file
<ul>
<li style="font-weight: 400;" aria-level="2">This works similarly for the destroy command</li>
</ul>
</li>
</ol>
In our example till now, we have been working with the local backend. We would now configure the remote backend to address shortcomings identified when using local file storage for state files.
A range of compatible backends are available and can be found <a href="https://www.terraform.io/language/settings/backends" target="_blank" rel="nofollow noopener">here</a>. For our example, since we are dealing with AWS, we would use S3 as our remote backend. This is not a necessity though, we can use any backend of our choice.
To use <a href="https://spacelift.io/blog/terraform-s3-backend" target="_blank" rel="noopener">Amazon S3 as a backend</a>, we need one S3 bucket. Let us add the configuration for the S3 bucket in our <code>main.tf</code> file as below.

Run terraform apply to provision this bucket in AWS. To use this bucket as backend, add <code>backend "s3"</code> block to the terraform block present in <code>provider.tf</code> file. The final contents of the <code>provider.tf</code> file should look like below.

If you try to run <code>terraform apply</code> it should throw an error. This is because we need to reinitialize Terraform since we have changed the backend information. Now when you run <code>terraform init</code>, it asks for confirmation to move the pre-existing “local” backend to the newly configured “s3” backend. This is exactly what we want. Type in ‘yes’ to confirm the same and hit enter.

If you see the output as above, it means we have successfully configured the given S3 bucket as our remote backend. Log in to the AWS console and verify the same.

s3-bucket-terraform-tutorial

remote backend

Caution: If you now try to destroy the resources using the <code>terraform destroy</code> command, it will also delete the newly created S3 bucket &#8211; which is currently serving as our remote backend.
Run <code>terraform destroy</code>, and observe the output without confirming the same.

This is one of those cases where we would want to remove the bucket from Terraform management. The other option would be to create an S3 bucket separately and use it to configure the remote backend in the terraform block.
Removing the S3 bucket from Terraform management implies that we need to update the state file by removing the corresponding S3 bucket information. Doing this manually is risky. Ideally, the state files should never be touched. Terraform provides various state file management commands. One such command is <a href="https://spacelift.io/blog/terraform-state-rm" target="_blank" rel="noopener"><code>terraform state rm</code></a> command which removes the given resource from the state file.
From the terminal, run <code>terraform state rm aws_s3_bucket.state_bucket</code>.

What is Terraform? What is it Used For, How it Works

In this step by step tutorial, you will learn how to use Terraform and get hands-on experience in managing cloud infrastructure with IaC.

83-terraform-tutorial

Terraform tutorial

Terraform Tutorial - Getting Started With Terraform on AWS

Templates play an important role in <a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">automation</a>. This lso applies to Terraform workflows as Terraform is a tool to automate infrastructure lifecycle management. <a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">Infrastructure as code</a> (IaC) has allowed us to leverage programming principles in cloud infrastructure maintenance, introducing consistency, faster provisioning, reduced manual maintenance efforts, and, consequently, minimized risks.
In this post, we go through the basics of Terraform Templates and discuss probable use cases and examples. In short, if the applications hosted on your infrastructure depend on certain configuration files &#8211; which are usually not part of the application repository &#8211; Terraform templates help manage those files in dynamic ways.

Terraform templates are configuration files that define and describe the infrastructure resources required for a particular application or environment using a declarative configuration language called Hashicorp Configuration Language (HCL). 
These templates have a &#8220;.tf&#8221; extension, and they enable users to code infrastructure, ensuring consistent and reproducible deployments. 
Inside a template, users can specify different resources such as virtual machines, IAM components, storage resources, or networking components and configure their relationships and properties. When executed using the Terraform CLI, these templates are translated into a set of actions that realize the described infrastructure on the targeted provider.
If you need any help managing your Terraform infrastructure, building more complex workflows based on Terraform, and managing AWS credentials per run, instead of using a static pair on your local machine, <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> is a fantastic tool for this. It supports Git workflows, <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">policy as code</a>, programmatic configuration, context sharing, <a href="https://docs.spacelift.io/concepts/stack/drift-detection.html" target="_blank" rel="noopener">drift detection</a>, and many more great features right out of the box.

Terraform offers a way to package a group of Terraform scripts as modules. <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Modules</a> are reusable infrastructure components based on which additional customized infrastructure components are built. 
Modules offer a way to customize the included components using input variables. Input variables provide a way to control aspects like scale, range, type, etc., for infrastructure to be provisioned.
Terraform Templates are a great way to further extend the flexibility provided by modules. Templates manage the configuration and data files, enabling granular control and making the module more flexible and reusable.
Like modules, usage of input variables drives template files to shape the actual config or data files on the target resource.

Terraform templates combine a few features &#8211; <code>templatefile</code> function, string literals, and template files themselves.
<h3><code>templatefile</code> function</h3>
The <a href="https://www.terraform.io/language/functions/templatefile" target="_blank" rel="nofollow noopener">templatefile()</a> function accepts a couple of inputs: 
<ol>
<li style="font-weight: 400;" aria-level="1">A template file (<code>*.tftpl</code>)</li>
<li style="font-weight: 400;" aria-level="1">Variable &#8211; which could be a list or map.</li>
</ol>
The template file contains text in UTF-8 encoded text, representing the desired format data. For example, configuration files required by applications have different formats. These files support Terraform’s <a href="https://www.terraform.io/language/expressions/strings#string-templates" target="_blank" rel="nofollow noopener">string literals</a>, which help replace the actual values supplied in variables.
For the final configuration, variables provide a way to set values in these template files dynamically. Before runtime, make sure that the template files are available on the disk.
<h4>Terraform template_file</h4>
For Terraform versions 0.12 and later, the template_file data source has been superseded by the templatefile function, that can be used directly in expressions without creating a separate data source.
<h3>File provisioners</h3>
<a href="https://www.terraform.io/language/resources/provisioners/file" target="_blank" rel="nofollow noopener">File provisioners</a> provide a way to copy the files from the machine where Terraform code executes to the target resource. The source attribute specifies the file&#8217;s source path on the host machine, and the destination attribute specifies the desired path where the file needs to be copied on target.
Learn more about file provisioners: <a href="https://spacelift.io/blog/terraform-provisioners#the-file-provisioner" target="_blank" rel="noopener">Terraform Provisioners : Why You Should Avoid Them</a>

<h3><code>jsonencode</code> and <code>yamlencode</code> functions</h3>
If the string being generated from the template file is a <a href="https://spacelift.io/blog/yaml#yaml-vs-json" target="_blank" rel="noopener">JSON or YAML file</a>, it could become quite tedious to format it for its validity. The chances of error are high if these files are not formatted properly.
Use <code>jsonencode</code> and <code>yamlencode</code> functions in the template file to produce an output file in respective formats easily.

<ul>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">How to Improve Your Infrastructure as Code using Terraform</a></li>
<li><a href="https://spacelift.io/blog/terraform-best-practices" target="_blank" rel="noopener">20 Best Practices for Using Terraform</a></li>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">5 Ways to Manage Terraform at Scale</a></li>
</ul>

<h3>Example 1 &#8211; Create user_data with Terraform</h3>
AWS EC2 instances offer support to run shell/bash scripts when the instances are booted. These scripts perform essential tasks like updating the packages, creating environment variables, installing patches, etc. These scripts are provided for EC2 creation in the form of user_data.
Given their nature, these scripts can get very complex. However, once the script is tested it may be used multiple times with slightly different values. As an example, we may need to provide a different set of environment variables for two different sets of EC2 instances.
Using Terraform, we can create a template for this script by using string literals to provide variables&#8217; values dynamically. In the example below, the script creates a directory, <code>cd</code>s into that directory, and creates a file within that with some name.

Let the name of above template file be <code>script.tftpl</code>. String literals (<code>${</code> … <code>}</code>) are used to represent variables. To add this script as <code>user_data</code> for EC2 instance, we use the <code>templatefile()</code> function as below.

We have passed the template file name (<code>script.tftpl</code>) as first parameter, and a map object with <code>request_id</code> and <code>name</code> key-value pairs for substitution. Creating an EC2 instance with a given <code>user_data</code> script runs as expected when Terraform code is applied.
Please note that both template and terraform code files are located in the same directory. Further, <a href="https://spacelift.io/blog/how-to-use-terraform-variables" target="_blank" rel="noopener">Terraform variables</a> are used to create larger map objects for easier management of supplied values.

<h3>Example 2 &#8211; Template file with for loop</h3>
Template file used in previous section is a bash script. Similarly, strings generated by shell or any other type of script are non-repetitive in their formats. Certain file formats are repetitive in nature, i.e., certain lines may have the same format, with different values.
As an example, DNS resolution configurations are maintained in a <code>resolv.conf</code> file, that lists the name servers in below format.

As we can see, the expected format of this file is repetitive. Use <a href="https://spacelift.io/blog/terraform-for-loop" target="_blank" rel="noopener">for loop expressions</a> to create a template file for what appears as below.
Filename: <code>resolv.conf.tftpl</code>

The corresponding terraform file would have file provisioner with a list type variable as the second parameter.

Applying above Terraform config results in creating the expected <code>resolve.conf</code> file in the target EC2 instance as below.

<h3>Example 3 &#8211; Creating JSON files using templatefile()</h3>
Occasionally, when applications depend on externally provided configuration files in JSON format. Since the application logic depends on JSON format, it becomes imperative for Terraform to format the configuration file accordingly.
Creating a valid JSON object using string operations can get tricky. A slight mistake in indentation, or mistyping <code>:</code> or <code>"</code> &#8211; in template files &#8211; can cause errors. Even if we successfully create a script to create a valid JSON object, there is always a risk of unhandled escape sequences from incoming data.
Terraform provides a function to create valid JSON files from the given template, without worrying about valid formatting. Let us consider that we want to host a product based on microservice architecture. Our microservices are developed in NodeJS.
For the sake of this example, it is critical that the application nodes in our microservice architecture depend on slightly different versions of dependencies. In that case, we create a template file as below &#8211; <code>dependencies.tftpl</code>.

The corresponding Terraform code appears below. Actual version values are passed via a variable &#8211; which would generate the desired dependencies.json file in target path.

<h3>Example 4 &#8211; Conditions in Terraform templates</h3>
Extending the above example, let us assume certain applications do not need certain dependencies to be installed. In that case, developers may choose simply not to supply the corresponding version values.
The current template file (<code>dependencies.tftpl</code>) throws an error in that case. If conditions provide this flexibility and improve the reusability of a given template file, make the dependencies depend on whether the corresponding information is supplied or not &#8211; using if conditions as below.

The summary of the above file is that if no version information for the given dependencies is provided, the dependencies will not be included in the <code> dependencies.conf</code> file. This makes this template file reusable with any microservice application and can be controlled by the <code>dep_vers</code> variable values in Terraform code.

Terraform’s string literals are a great asset of the HCL language. Terraform offers a whole <a href="https://spacelift.io/blog/terraform-functions-expressions-loops" target="_blank" rel="noopener">range of functions</a> to perform string templating. The combination of string literals, <code>templatefile()</code> function, and file provisioner can be a huge advantage when triggering the configuration management workflows on Day 0. Terraform templates offer flexibility around the file formats &#8211; thus not limiting to specific ones. Additionally, filesystem functions are used to perform validation tasks. 

If you need more help with Terraform, I encourage you to check the following blog posts: <a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments</a>, and <a href="https://spacelift.io/blog/terraform-best-practices" target="_blank" rel="noopener">12 Terraform Best Practices.</a>
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu is not going to have its own providers and modules, but it is going to use its own registry for them.

If you are struggling with Terraform automation and management, check out Spacelift. It helps you manage Terraform state, build more complex workflows, and adds several must-have capabilities for end-to-end infrastructure management.

Grab our ultimate cheat sheet PDF for all the Terraform functions you need on hand.

Common Patterns of Infrastructure as Code Architecture: Terraform & Terragrunt

Terraform Custom Conditions - Preconditions & Postconditions

The basics of Terraform Templates. What are Terraform Templates used for? See examples and use cases. Templatefile function explained.

52-terraform-templates

Terraform templates

What are Terraform Templates? Examples and Use Cases

Ansible Guides and Tutorials | Spacelift Blog

Ansible

What is the difference between Terraform and Ansible? Terraform is an open-source platform designed to provision cloud infrastructure, while Ansible is an open-source configuration management tool focused on the configuration of that infrastructure.
Terraform vs Ansible: which tool should you use? Here’s the answer from experts who have working experience on both tools.
This post highlights the differences between Terraform and Ansible, explores the similarities and concludes with the best way to manage infrastructure.

Terraform enables you to provision, manage, and deploy your infrastructure as code (IaC) using a declarative configuration language called HashiCorp Configuration Language (HCL). One of the most popular IaC tools available, it was initially developed by Hashicorp under an open-source license, but it recently switched to a Business Source License (BUSL).
Key features of Terraform:
<ul>
<li>State management: Terraform tracks resources and their configuration in a state file.</li>
<li>Declarative code: Users describe the desired state of their infrastructure, and Terraform manages it.</li>
<li>Widely adopted: Terraform supports over 3k providers.</li>
<li>Declarative language: You can divide your infrastructure into multiple reusable modules.</li>
</ul>

Ansible is a software tool designed for cross-platform automation and orchestration at scale. Written in Python and backed by RedHat and a loyal open-source community, it is a command-line IT automation application widely used for configuration management, infrastructure provisioning, and application deployment use cases.
Key features of Ansible:
<ul>
<li>YAML: A popular, simple data format that is easy for humans to understand.</li>
<li>Modules: Reusable standalone scripts that perform a specific task</li>
<li>Playbooks: A playbook is a YAML file that expresses configurations, deployments, and Orchestration in Ansible. They contain one or multiple plays.</li>
<li>Plays: Subset within a playbook. Defines a set of tasks to run on a specific host or group of hosts.</li>
<li>Inventories: All the machines you use with Ansible are listed in a single simple file, together with their IP addresses, databases, servers, and other details.</li>
<li>Roles: Redistributable units of organization that make it easier for users to share automation code.</li>
</ul>

At a very high level, given the capabilities of both the products, <a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> and Ansible come across as similar tools. Both of them are capable of provisioning the new cloud infrastructure and configuring the same with required application components.
Both Terraform and Ansible are capable of executing remote commands on the virtual machine that is newly created. This means, both the tools are agentless. There is no need to deploy agents on the machines for operational purposes.
Terraform uses cloud provider APIs to create infrastructure and basic configuration tasks are achieved using SSH. The same goes with Ansible &#8211; it uses SSH to perform all the required configuration tasks. The “state” information for both does not require a separate set of infrastructure to manage, thus both the tools are masterless.

The previous section gives an overview of the two tools in their broadest similarities. At a high level, it sounds like both Terraform and Ansible are capable of provisioning and configuration management. However, a deeper dive into them makes us realize the benefits of one over the other in certain areas.
In general, both the tools are great in their own ways. They have an overlap of functions when it comes to infrastructure management. Infrastructure management broadly encompasses 2 aspects &#8211; orchestration and configuration management. 
Terraform and Ansible have their own ways of managing both &#8211; with strong and weak points when it comes to overlaps. Thus, it is important to delve into some details of both the tools to make a “perfect” choice or a combination with boundaries.

terraform-vs-ansible-4

Terraform vs Ansible comparison table

<h3>1. Orchestration vs. Configuration Management</h3>
Orchestration/provisioning is a process where we create the infrastructure &#8211; virtual machines, network components, databases, etc. Whereas, on the other hand, configuration management is a process of automating versioned software component installation, OS configuration tasks, network and firewall configuration, etc.
Both Terraform and Ansible are capable of performing both tasks. However, <a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">Terraform offers a comprehensive solution to manage infrastructure</a>. Terraform uses cloud provider APIs to provision and de-provision the infrastructure based on declared resources. 
Ansible, on the other hand, is also capable of provisioning the cloud infrastructure but it is not comprehensive enough. It is mainly geared towards configuration management. Configuration management is a process of keeping the applications and dependencies up to date. This is where Ansible really shines as compared to Terraform.
Both the tools can perform both kinds of activities. However, there are limitations when implementing configuration management using Terraform, and infrastructure automation using Ansible. They are not flexible enough when it comes to complex infrastructure management.
Logically, we can identify orchestration as Day 0 activity and configuration management as Day 1 activity. Terraform works best for Day 0 activities and Ansible for Day 1 and onwards activities.
<h3>2. Declarative vs. Procedural Language</h3>
Terraform is used to write Infrastructure as Code (<a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">IaC</a>). It uses HCL (Hashicorp Configuration Language) which is declarative in nature. It doesn&#8217;t matter in which sequence the code is written. The code could also be dispersed in multiple files.
No matter how you write the code, Terraform identifies the dependencies, and provisions infrastructure. Writing or translating existing infrastructure to code is easy in Terraform. Check this <a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform" target="_blank" rel="noopener">Terraform import tutorial</a> if you would like to know more about importing infrastructure under Terraform management.
Ansible uses YAML syntax to define the procedure to perform on the target infrastructure. Ansible YAML scripts are procedural in nature &#8211; meaning when you write the script, it will be executed from top to bottom.
Ansible scripts are called &#8220;<a href="https://spacelift.io/blog/ansible-playbooks" target="_blank" rel="noopener">ansible playbooks</a>&#8220;. When you have to perform a certain series of tasks, you define the same in the playbook. The tasks will be performed in the sequence they are written. For example, to install an Apache server on the given virtual machine as a root user, you would have to write the user creation step before defining the task for installation.
<h3>3. Mutable vs. Immutable Infrastructure</h3>
Application deployment workflow involves provisioning of the infrastructure and installing the right version of source code and dependencies on the provisioned infrastructure. 
Mutability is an attribute associated with the underlying infrastructure that defines the way newer versions of applications and services are deployed. Deployment either takes place on existing infrastructure, or we can provision a completely new set of infrastructure for the same.
The deployment practices typically determine whether the infrastructure is mutable or immutable. When newer versions of applications are released on the same infrastructure, it is called mutable. However, if the deployment happens on completely new infrastructure during releases, it is said to be immutable.
Mutability seems convenient, but the risk of failure associated with it is higher. When application configurations are re-applied on the same infrastructure, there are additional steps of uninstalling the previous version and then installing the desired version. More steps also introduce more chances of failure. Doing this for a fleet of servers can result in uneven configurations and unpredictable behavior.
Instead, if we focus on reducing these number of steps by ignoring the uninstallation procedure and performing the installation on new infrastructure resources &#8211; we get a chance to test and revert the new deployment in case of failure. Treating infrastructure as immutable in this way provides greater control over introducing changes.
However, there is no golden rule defined that advocates one approach over the other. 
Since Terraform’s strength lies in handling the infrastructure lifecycle, it supports infrastructure immutability better. It is easier to provision a completely new set of infrastructure and deprovision the older set using Terraform. However, handling configuration changes are not something that can be done in the most efficient manner.
As far as the configuration changes are concerned, Ansible wins the race since it is primarily a configuration management tool. Ansible supports infrastructure immutability by offering VM image creation. However, maintaining these additional images requires additional efforts.
It is recommended to follow the immutable infrastructure approach, where Terraform takes care of the infrastructure management, and Ansible helps apply the changed configuration. This is also known as the Blue/Green deployment strategy, where the risk of configuration failure is reduced.
<h3>4. State Management</h3>
Terraform manages the entire <a href="https://spacelift.io/blog/terraform-resource-lifecycle" target="_blank" rel="noopener">lifecycle of the resources</a> under its management. It maintains the mapping of infrastructure resources with the current configuration in state files. State management plays a very important role in Terraform.
States are used to track changes to the configuration and provision the same. It is also possible to import existing resources under Terraform management by importing the real-world infrastructure in state files. 
At any given time, it is possible to query the <a href="https://spacelift.io/blog/terraform-state" target="_blank" rel="noopener">Terraform state files</a> to understand the infrastructure component and their attributes currently available.
As opposed to this, Ansible does not support any lifecycle management. Since Ansible mainly deals with configuration management and considering it defaults to immutable infrastructure, any changes introduced in the configuration are executed automatically on the target resource.
<h3>5. Configuration Drift</h3>
Configuration drift refers to the difference between the desired and actual state of your configuration. One of the most common reasons for this is that engineers/machines make changes outside the configuration. If you are using Terraform to manage your infrastructure and you make a change outside it, you’ve introduced drift. Drift happens, and solutions like <a href="https://spacelift.io/drift-detection" target="_blank" rel="noopener">Spacelift’s drift detection</a> not only detect the drift but can optionally remediate it, too.
While both Ansible and Terraform aim to mitigate drift, their methodologies differ. Ansible relies on idempotent tasks and continuous execution without maintaining a persistent state of the infrastructure. In contrast, Terraform relies on a stored state to detect and manage drift, emphasizing a declarative approach to infrastructure as code.

<ul>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments</a></li>
<li><a href="https://spacelift.io/blog/github-actions-terraform" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Managing Terraform with GitHub Actions &amp; How to Scale&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Managing Terraform with GitHub Actions &amp; How to Scale</a></li>
<li><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener">Top Most Useful CI/CD Tools for DevOps</a></li>
</ul>

Which is better: Terraform or Ansible? The answer to this question lay somewhere in the middle. But as we have known till now, Terraform works best with orchestration and Ansible is great at configuration management. They have the capabilities to perform each other’s tasks, although in a limited manner. It’s recommended to leverage both tools for infrastructure management, based on their respective strengths.
If you are looking to manage infrastructure as code, <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> is the way to go. It supports Git workflows, policy as code, programmatic configuration, context sharing, and many more great features. It currently works with <a href="https://docs.spacelift.io/vendors/terraform/" target="_blank" rel="noopener">Terraform</a>, Pulumi, CloudFormation, and Kubernetes and has initial <a href="https://spacelift.io/blog/spacelift-ansible-integration-beta" target="_blank" rel="noopener">support for Ansible</a>. You can test drive it by creating a <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">free trial account</a>.

Spacelift is a sophisticated SaaS product for Infrastructure as Code that helps DevOps develop and deploy new infrastructures or changes quickly and with confidence.

13 Most Useful CI/CD Tools for DevOps in 2023

How Spacelift Can Improve Your Infrastructure as Code

Ansible vs Terraform: what is the difference between the tools and which one to choose? See a detailed expert comparison and decide for yourself.

16-1-2

terraform vs ansible

Terraform vs. Ansible: Differences and Comparison of Tools

Cloud resources created using Terraform are maintained using Infrastructure as Code. Any changes, commissioning, and decommissioning of resources are supposed to be handled using IaC. Teams who have adapted Terraform for infrastructure management usually have strict compliance with manual changes via the web console.
In this post, you will learn how to manage the destruction of cloud infrastructure resources that are under Terraform management (resources that are created using Terraform IaC) and how to overcome some common pitfalls.

The <dfn>Terraform destroy command</dfn> is a command that terminates resources managed by your current Terraform project by deleting infrastructure resources present in the state file. When the <code>destroy</code> command is executed, Terraform first validates the information contained in the state file by cross-checking with cloud provider APIs. Internally it builds a dependency graph to identify the sequence in which the resources are to be destroyed.
Clearly, the <a href="https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/DEVNET-2340.pdf" target="_blank" rel="noopener">state file is a source of truth for Terraform to perform any operation</a>. If the state file is corrupted then Terraform can behave in unwarranted ways. If the state file has no mention of a certain resource &#8211; but the resource exists in the real world &#8211; then running <code>terraform destroy</code> will NOT destroy that resource.
Note: New versions of Terraform will be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers while also introducing improvements and enhancements. OpenTofu works with your existing Terraform state file, so you won’t have any issues when you are migrating to it.

Continuing on the importance of the state file &#8211; there are essentially two ways to destroy resources using Terraform.
<h3>1. Terraform Plan Destroy</h3>
Assuming you have a set of resources deployed using Terraform configurations, to destroy one or all of the resources in this configuration, simply remove/comment out the resource blocks and run <code>terraform plan</code> to validate the desired action and then <code>apply</code>.
During its validation phase Terraform identifies the gaps in configuration and state files. It also checks if the real-world resources exist and generates a plan to remove any resources which are available in the real world, but not in the configuration.
This also means, if we manually delete a particular resource, the next <code>destroy</code> cycle would take the same into consideration and only attempt to delete the resource that exists.
Running the example code below (uncommented) will create 2 EC2 instances &#8211; <code>demo_vm_1</code> and <code>demo_vm_2</code>. To destroy one of the EC2 instances, comment out the corresponding resource block in the code &#8211; <code>demo_vm_2</code>.

Run <code>terraform plan</code> and observe the output.

Terraform identifies the absence of <code>demo_vm_2</code> in the configuration, but notices that it exists in the state file as well as in the real world. Thus it generates a plan to destroy that EC2 instance. Running <code>terraform apply</code> now would cause the destruction of this EC2 instance.

<ul>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments and Infrastructure Provisioning</a></li>
<li><a href="https://spacelift.io/blog/github-actions-terraform" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Managing Terraform at Scale with Github Actions&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Managing Terraform at Scale with GitHub Actions</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Improve Your Infrastructure as Code using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Improve Your Infrastructure as Code using Terraform</a></li>
</ul>

<h3>2. Terraform Destroy Command</h3>
<code>Terraform destroy</code> is a more common way to destroy resources managed by Terraform. The <code>destroy</code> command can be used to destroy a complete set of cloud infrastructure or a targeted resource.
To destroy a specific EC2 instance (<code>demo_vm_1</code>), the <code>--target</code> argument can be supplied to the <code>destroy</code> command with the resource path to identify the correct resource as below.
<h4>Terraform: Destroy Target</h4>

Terraform validates the state as well as its existence in AWS EC2 console, and triggers the deletion of the specified EC2 instance.
<h4>Terraform: Destroy Specific Resource </h4>

Validate the same by logging into the AWS Console.
However, to destroy both EC2 instances simply run <code>terraform destroy</code> without <code>--target</code> argument. Terraform validates the state and existence of the EC2 instances and triggers the resource deletion. Try running <code>terraform destroy</code> with our example now, and observe the output.

<h3>3. Destroy Protected Resources</h3>
Let us recreate the infrastructure we had in the previous example, this time with a minor difference. Add <code>disable_api_termination = true</code> attribute to <code>demo_vm_2</code>. Try to destroy the same using <code>terraform destroy</code> command again. Observe the output with error message.
As per the error message, we get <code>OperationNotPermitted</code> error for one of the EC2 instances. The Terraform configuration responsible for creating this EC2 instance has <code>disable_api_termination</code> set to <code>true</code>. This is additional protection provided by the cloud provider to avoid accidental deletion of the EC2 instance.
Because Terraform operations utilize cloud provider APIs to <code>apply</code> or <code>destroy</code> configurations, it cannot do anything disallowed by the provider’s API. In this case it means that Terraform is not be able to delete <code>demo_vm_2</code>. However, it was able to delete <code>demo_vm_1</code> for which this property was not set at all. This tells us that it defaults to <code>false</code>.
Log in to AWS console and disable the termination property for this EC2 instance, and run the <code>destroy</code> command again. This time it should succeed.

destroy terraform resources

At this time, there is no way for Terraform to override this behavior. But this is a positive, because it helps prevent any accidental deletion of critical resources.

<h3>4. Destroy All Except a Few</h3>
At times you will face scenarios where you would like to recreate most of the infrastructure components, but keep a few critical ones in place. Currently, there is no way to specify the resources NOT to be destroyed using Terraform.
However, since the state plays a major role in Terraform’s decision making &#8211; an apparent workaround would be as follows:
<ol>
<li style="font-weight: 400;" aria-level="1">Remove the resource from the state file using <a href="https://spacelift.io/blog/terraform-state-rm" target="_blank" rel="noopener"><code>terraform state rm</code> command</a>.</li>
<li style="font-weight: 400;" aria-level="1">Run <code>terraform destroy</code> &#8211; without <a href="https://spacelift.io/blog/terraform-target" target="_blank" rel="noopener">Terraform <code>--target</code> argument</a>.</li>
<li style="font-weight: 400;" aria-level="1">After successful destruction, <code>import</code> the target resources back in the state file. This post describes <a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform" target="_blank" rel="noopener">how to import cloud resources under Terraform</a>.</li>
</ol>
Running <code>terraform state rm</code> lets Terraform know that some of the resources are not managed by Terraform anymore. When <code>destroy</code> is executed, Terraform does not touch those resources. When the cleanup of other resources is done, and the remaining resources are imported back &#8211; Terraform then manages the resources again.

Terraform <code>destroy</code> is a command that should be used wisely. It is not something that would be used on a daily basis in managing the production environment. 
However, making use of it in sub-production environments would be quite frequent as a lot of try-outs for proofs-of-concept require cleanup activities.
<a href="https://docs.spacelift.io/" target="_blank" rel="noopener">Spacelift</a> lets you customize the entire infrastructure life-cycle management by providing the ability to run pre and post commands at every stage – including the <code>destroy</code> phase – which can be very useful in keeping track of things. 
We encourage you also to explore <a href="https://spacelift.io/terraform-at-scale" target="_blank" rel="noopener">how Spacelift makes it easy to work with Terraform</a>. If you need any help managing your Terraform infrastructure, building more complex workflows based on Terraform, and managing AWS credentials per run, instead of using a static pair on your local machine, Spacelift is a great tool for this. It supports Git workflows, policy as code, programmatic configuration, context sharing, drift detection, and many more great <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">features</a>. Create your free trial account <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">here</a>.

Spacelift destroying phase

frame-8479-2

How to Automate Terraform Deployments and Infrastructure Provisioning

Learn how to destroy resources from Terraform. See how to use the Terraform destroy command, also to target a specific resource.

Sumeet Ninawe

Terraform Taint, Untaint, Replace – How to Use It (Examples)

Get the newsletter

Recent posts

Terraform Tutorial – Getting Started With Terraform on AWS

What are Terraform Templates? Examples and Use Cases

Terraform vs. Ansible : Key Differences and Comparison of Tools

Destroy Command – How to Destroy Resources from Terraform

How to Use Terraform Variables (Locals, Input, Output, Environment)

Terraform Data Sources – How They Are Utilized

Importing Existing Infrastructure Into Terraform – Step by Step