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

Author title

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

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

Terraform

Infrastructure as Code (IaC) is a key attribute of enabling best practices in any organization practicing a DevOps culture. The ability to build up and tear down infrastructure via code has many benefits, like reducing cost, increasing deployment speed, and lowering risk through consistency. There is, however, a dark side to IaC. If not used cautiously and carefully, it is way too easy to cause harm to an environment.

Applying infrastructure changes haphazardly can lead to unwanted changes to your environment. The Terraform <a href="https://www.terraform.io/cli/commands/plan" target="_blank" rel="nofollow noopener"><code>plan</code></a> command is available to bring visibility to your IaC deployments. The <code>plan</code> command reports on changes to infrastructure, but it does not apply any of the proposed changes. Instead, it creates a reviewable execution plan, which you can use to confirm that the proposed changes are expected.
The execution plan can be saved to a file, which can be applied later, or peer-reviewed to enforce quality control. The ability to review the proposed changes prior to applying them can save you from making unexpected infrastructure changes. After you have confirmed the changes as expected, use the Terraform <a href="https://spacelift.io/blog/terraform-apply" target="_blank" rel="noopener"><code>apply</code></a> command to update the remote objects.
The <code>plan</code> command does three things:
<ul>
<li>Ensures the state is up to date by reading the current state of any already-existing remote infrastructure.</li>
<li>Determines the deltas between the current configuration and the prior state data.</li>
<li>Proposes a series of changes that will make the remote infrastructure match the current configuration.</li>
</ul>
If there aren&#8217;t any deltas, the output will report that no actions need to be taken.

Let&#8217;s look at the output resulting from executing <code>plan</code> with a simple Terraform configuration script. For this walkthrough, we&#8217;ll use a new Azure subscription that does not contain any resources. The listing for the configuration script is below.

Run the following command on the command line to generate an execution plan.
Before doing so, be sure to set environment variables for your Azure Subscription Id and Tenant Id, using the subscription id and tenant id from your Azure subscription, respectively. For more details on the different ways, you can configure the AzureRM Terraform provider, <a href="https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs" target="_blank" rel="nofollow noopener">see here</a>.

tf_plan_initial_output_1

Terraform plan - initial output

The output contains a wealth of information, which is highlighted in the image above. Terraform proposed a create action, as indicated by the green plus sign. Changes and deletions appear as yellow tilda and red minus sign, respectively. Terraform is also proposing to create a new resource group named &#8220;rg-tf-plan-example-centralus.&#8221; The execution plan includes a summary count of each action in the proposal. In this case, there is one add, zero change, and zero destroy, actions.
Apply the proposed changes by running the <code>apply</code> command (make sure you confirm the actions by typing <code>yes</code> when prompted):

In addition to creating the resource group, Terraform also updated the local <a href="https://spacelift.io/blog/terraform-state" target="_blank" rel="noopener">state</a> data. Terraform uses state data to remember the remote infrastructure configurations and create deltas when configurations change.
Make the following change to the sample Terraform script. Add the following line to the end of the script, just before the closing curly brace:

The resource group resource should now look like this:

Re-run the <code>plan</code> command:

When the <code>plan</code> command executed, Terraform compared the stored state data for the rg-tf-plan-example-centralus resource to the changes made in the configuration script.

terraform-plan-delta

terraform plan delta output

Looking at the output, you can see Terraform determined an update was necessary. The output also shows the proposed changes, including the actual change itself: the addition of the <code>name</code> tag.
It&#8217;s also worth mentioning that with <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">Spacelift you can use plan policies</a> to make automated decisions based on Terraform plans. Plan policies are evaluated during a planning phase after a vendor-specific change preview command (e.g. <code>terraform plan</code>) executes successfully. The body of the change is exported to JSON, and parts of it are combined with Spacelift metadata to form the data input to the policy.

The <code>plan</code> command can be run in three different modes, normal, which is the default and the mode we&#8217;ve used so far, destroy, and refresh-only. The modes are mutually exclusive. You cannot use more than one mode at a time.
Destroy mode creates a plan which shows you all the remote objects that will be removed. Running the command in destroy mode does not actually perform any actions. A great use case for destroy mode is to delete a temporary development environment.
You activate destroy mode by including the <code>-destroy</code> option on the command line:

terraform-plan-destroy

terraform plan destroy output

There are times when you will intentionally change remote objects without the use of a Terraform script, i.e., directly via the Azure CLI. This can be necessary when troubleshooting a problem in the remote environment. In these cases, the state data will not match the remote object configuration and will need to be reconciled.
Executing <code>plan</code> in refresh-only mode creates a plan with the goal of showing you the deltas between the state data and the remote objects. You can activate refresh-only mode by including the <code>-refresh-only</code> option on the command line.
Note: the <code>-refresh-only</code> option is available only in Terraform v0.15.4 and later.

terraform-plan-refresh-output

terraform plan refresh output

In addition to the alternate <code>plan</code> modes described above, there are a couple of other categories of options available, those affecting behavior and those affecting outputs.
<h3>Options Affecting How the Plan Command Behaves</h3>
Options that modify the <code>plan</code> command&#8217;s behavior are listed below.
<table>
<tbody>
<tr>
<td>Option</td>
<td>Description</td>
</tr>
<tr>
<td><code>-refresh=false</code>
&nbsp;</td>
<td>Ignores external changes to remote objects, i.e., those made via the CLI. This option will not sync the state data with the remote objects before checking for configuration changes. While this improves performance by making less remote API requests, ignoring external changes could result in incomplete or incorrect plans.
&nbsp;</td>
</tr>
<tr>
<td><code>-replace=ADDRESS</code>
&nbsp;</td>
<td>Forces the replacement of the resource instead of an update action or no change at all. This will replace the resource at the given address. It can be applied multiple times to replace many objects at once.
&nbsp;</td>
</tr>
<tr>
<td><code>-var 'NAME=VALUE'</code>
&nbsp;</td>
<td>Applies a value for an input variable. It can be applied multiple times, once per variable.
Note: Errors will occur if a space appears before or after the equals sign (e.g., <code>-var "region = centralus"</code>).
&nbsp;</td>
</tr>
<tr>
<td><code>-var-file=FILENAME</code>
&nbsp;</td>
<td>Applies values for one or more input variables as defined in a <a href="https://spacelift.io/blog/terraform-tfvars" target="_blank" rel="noopener">&#8220;tfvars&#8221; file</a>. It can be used multiple times, once for each &#8220;tfvars&#8221; file.
&nbsp;</td>
</tr>
<tr>
<td><code>-lock-timeout=DURATION</code></td>
<td>Instructs Terraform to retry acquiring a lock for a period of time before returning an error. The duration value must be entered using the format nt where n is a number and t is a letter representing a unit of time, e.g., 3m is 3 minutes.
&nbsp;</td>
</tr>
</tbody>
</table>
Let&#8217;s turn the resource group&#8217;s location attribute into a variable. This adds flexibility and reusability to the script, allowing us to specify the location value at runtime. Modify the sample script as follows.
Add a variable to the sample script named &#8220;region&#8221; just before the provider section and modify the azurerm_resource_group resource so the value for the location attribute comes from a variable.
Note: for simplicity, we are using one &#8220;.tf&#8221; file to define the resources and the variables. In practice, variables are declared in a separate file, typically named &#8220;variables.tf&#8221;. The script below shows the result of making this change.

The &#8220;region&#8221; variable is declared as a string.
Re-run the Terraform <code>plan</code> command. This time you will be prompted for the location in Azure where the resource group resides.

terraform-variable-prompt

terraform variable prompt

Run the <code>plan</code> command again. This time, use the -var option to provide a value for region on the command line and notice that you are no longer prompted to supply a value for the variable.

<h3>Options Related to Formatting and Output</h3>
There will be use cases where you will need to change the <code>plan</code> command&#8217;s output. The following options are available for those use-cases:
<table>
<tbody>
<tr>
<td>Option</td>
<td>Description</td>
</tr>
<tr>
<td><code>-compact-warnings</code>
&nbsp;</td>
<td>Shows warnings as a summary unless the warnings include errors. If there are errors, the text will include useful information for troubleshooting.
&nbsp;</td>
</tr>
<tr>
<td><code>-input=false</code>
&nbsp;</td>
<td>Disables prompts for input variables. that have not otherwise been assigned a value. This option is useful when automating Terraform scripts, like when run in a <a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener">CI/CD pipeline</a>.
&nbsp;</td>
</tr>
<tr>
<td><code>-json</code>
&nbsp;</td>
<td>Returns output in JSON format.
&nbsp;</td>
</tr>
<tr>
<td><code>-no-color</code>
&nbsp;</td>
<td>Removes color from the output.
&nbsp;</td>
</tr>
<tr>
<td><code>-out=FILENAME</code></td>
<td>Saves the plan to a file that can be passed to the Terraform <code>apply</code> command to execute the planned changes. Any filename is allowed, but the recommended naming convention is to name it &#8220;tfplan.&#8221; Do not use the &#8220;.tf&#8221; suffix, as this will lead Terraform to interpret the file as a configuration script and will fail.
Note: the file contains all the values associated with planned changes, including any sensitive data, in cleartext in the plan file. For this reason, you must consider impacts on security when saving plans to a file.
&nbsp;</td>
</tr>
<tr>
<td><code>-parallelism=n</code></td>
<td>By default, Terraform will run 10 operations concurrently, where possible. This option limits the number of concurrent operations to n.
&nbsp;</td>
</tr>
<tr>
<td><code>-detailed-exitcode</code></td>
<td>Includes detailed exit codes, which provide more granular information about the resulting plan. The list of codes is:
&#8211; 0 = Succeeded with empty diff (no changes) 
&#8211; 1 = Error 
&#8211; 2 = Succeeded with non-empty diff (changes present)
&nbsp;</td>
</tr>
</tbody>
</table>

Resource targeting is like the -replace=ADDRESS option in that it tells Terraform to focus the plan only on resources that match the given address. Resource targeting includes all other objects that the selected resource(s) depend on, either directly or indirectly.
You can target resources using the -target=ADDRESS option.
Note: It is not recommended to use -target under normal circumstances.
Terraform enforces this point by including a warning message in the output. Run the following command to see the warning message embedded in the output:

terraform-plan-target-warning

terraform plan target warning

Instead of using -target, split large configurations into several smaller configurations that can each be applied independently. Doing so allows a complicated configuration to be separated into more manageable parts.

The <code>plan</code> command is very powerful despite not actually modifying any resources. Saving plans to output files enables automation and peer review. Supplying variable values on the command line or in files eliminates the need to hard code values, some of which may be sensitive. Using <code>plan</code> to show deltas between state data and remote configurations can help illuminate changes made directly to remote objects, which may need to be refreshed.
You should plan to run the <code>plan</code> command prior to applying your changes. This will help you avoid late-night troubleshooting sessions for changes that have gone awry. Remember, failing to plan is planning to fail.
If you’re interested in finding out how to use Spacelift to manage and automate your Terraform deployments check out our <a href="https://docs.spacelift.io/vendors/terraform/" target="_blank" rel="noopener">Terraform documentation</a> and sign up for a <a href="https://spacelift.io/free-trial?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bterraform_fmt%7D" target="_blank" rel="noopener">free trial</a>.

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.

Terraform Cheat Sheet - 21 Terraform CLI Commands & Examples

How to Debug & Troubleshoot Terraform Projects: Tutorial

5 Ways to Manage Terraform at Scale - Best Practices

The Terraform plan command is very powerful despite not actually modifying any resources. Take a look at the usage examples and planning options.

110-terraform_plan

Terraform plan command

Terraform Plan Command - Check Your IaC Deployment 

This blog post will look into two Infrastructure as Code (IaC) automation tools, Atlantis and Terraform Cloud/Enterprise and analyze their similarities and differences. 
Atlantis allows users to orchestrate <a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">Terraform automation</a> through pull requests by using comments, and it’s a great tool suited for small-scale projects and casual usage. Terraform Cloud provides a specialized CI/CD platform for Terraform automation and a great remote backend solution. Terraform Cloud is more scalable than Atlantis but offers fewer extensibility options.

<a href="https://www.runatlantis.io/" target="_blank" rel="nofollow noopener">Atlantis</a> is an open-source and self-hosted Terraform &#8220;pull request-based&#8221; automation tool. It offers an easy way to automate the Terraform workflow using pull request comments. On every new pull request, Atlantis automatically runs the <code>terraform plan</code> command and comments the output back on the pull request. After the suggested changes have been reviewed, a team member can leave a pull request comment with a special meaning to apply the changes. 
A great benefit of the Atlantis workflow is that it doesn&#8217;t add a new user interface (UI) for operators and developers but integrates nicely with your choice&#8217;s version control system (VCS) provider. It provides the option to perform code reviews and Terraform operations via the same graphical user interface. Users don&#8217;t need access credentials for the infrastructure provider, and errors can be caught during the code review step. With the Atlantis model, each pull request contains a detailed audit log of changes made via Terraform.
Atlantis self-hosted runners can be given an identity native to your cloud (e.g., AWS instance profile) for access without credentials to the state and managed resources. They can also be configured to run inside the <a href="https://aws.amazon.com/vpc/" target="_blank" rel="nofollow noopener">Virtual Private Cloud (VPC)</a> to access local resources (e.g., VPC-internal database) but need inbound connectivity from the VCS provider to receive webhooks. Its configuration is primarily done using environment variables passed to the statically linked binary and the <a href="https://www.runatlantis.io/docs/configuring-atlantis.html" target="_blank" rel="nofollow noopener">YAML file</a>.
Atlantis is stateless, but one of its main drawbacks is that it doesn&#8217;t support a high-availability setup or any scaling and queueing support. To accommodate scaling and highly available setups, a substantial engineering effort and creativity are required to build a custom in-house solution. 
Flexibility is one of the core advantages of Atlantis, as it allows easy integration with other Terraform-helper tools(e.g., <a href="https://github.com/aquasecurity/tfsec" target="_blank" rel="nofollow noopener">tfsec</a>, <a href="https://www.checkov.io/" target="_blank" rel="nofollow noopener">checkov</a>, <a href="https://github.com/infracost/infracost-atlantis" target="_blank" rel="nofollow noopener">Infracost</a>, or <a href="https://www.terratag.io/" target="_blank" rel="nofollow noopener">Terratag</a>). It can work with Terraform wrappers, such as <a href="https://terragrunt.gruntwork.io/" target="_blank" rel="nofollow noopener">Terragrunt</a>, out of the box and even add some of Terragrunt&#8217;s features to vanilla Terraform &#8211; like <a href="https://www.runatlantis.io/docs/custom-workflows.html" target="_blank" rel="nofollow noopener">before and after hooks</a> for every execution stage (init, plan, apply, etc.). 
Atlantis has a vibrant and active community, with new versions being released often. Something to note here is that although the development is active and there are regular contributions, the efforts aren&#8217;t focused on new major features since the lead contributor <a href="https://medium.com/runatlantis/joining-hashicorp-200ee9572dc5" target="_blank" rel="nofollow noopener">moved to Hashicorp</a>.
Overall, it&#8217;s a great tool suited for small-scale operations and infrastructure topologies. It is much appreciated by its user community and offers a flexible automation solution for occasional use. Having said that, it is strongly limited by its architecture, and scaling it isn&#8217;t straightforward. If your company has large-scale infrastructure needs, other more robust and mature solutions exist.

<a href="https://cloud.hashicorp.com/products/terraform" target="_blank" rel="nofollow noopener">Terraform Cloud</a> is a more comprehensive infrastructure provisioning tool that works exclusively for Terraform, developed by Hashicorp. It provides a scalable solution to automate infrastructure delivery, handle compliance, and manage resources in a cloud-agnostic way, utilizing Terraform. It is Hashicorp’s SaaS managed service offering targeting the Terraform workflow.
One of Its main offerings is a specialized CI/CD platform to standardize Terraform deployments and reduce their time. It supports an excellent remote state backend and an API for remote Terraform operations and integration with existing workflows. It integrates with VCS providers and allows fully automated, or manual approval checks for infrastructure provisioning flows. 
Interaction with Terraform Cloud can be achieved with the command-line interface (CLI), UI, API, or CI jobs. The <a href="https://www.terraform.io/language/settings/backends/remote" target="_blank" rel="nofollow noopener">remote or enhanced backend</a> allows teams to run the Terraform binary from their laptops or a third-party CI job, but the operation is executed on a remote machine. This is especially useful for one-off administrative tasks like tainting or migrating resources &#8211; things that are not trivial with Atlantis and may require dedicated solutions like <a href="https://github.com/minamijoyo/tfmigrate" target="_blank" rel="nofollow noopener">tfmigrate</a>.
Terraform Cloud offers basic security essentials such as RBAC with custom workspace permissions and different access levels for different types of users. Its integration with single sign-on (SSO) allows administrators easy user onboarding and management.
Unlike Atlantis, Terraform Cloud architecture is highly scalable, so it will take a while to outgrow it. It offers a shared state, distributed execution, concurrent runs, notifications for workspace events, and VCS integrations to support its scalability. 
Teams can leverage Terraform Cloud’s rich API imperatively from external scripts or declaratively from Terraform itself, using <a href="https://registry.terraform.io/providers/hashicorp/tfe/latest/docs" target="_blank" rel="nofollow noopener">their provider</a>. Managing Terraform with Terraform is often a secret to managing IaC at scale in dynamic organizations. It also supports exporting audit logs to external systems via its API. 
One drawback of Terraform Cloud compared to Atlantis is that it is less extensible. While Atlantis lets you execute arbitrary shell commands as part of your Terraform job, Terraform Cloud depends on clever hacks like the <a href="https://registry.terraform.io/providers/hashicorp/null/latest/docs/resources/resource" target="_blank" rel="nofollow noopener">null resource</a> or an external wrapper. For example, suppose you are a Terragrunt user. In that case, you may want to have a CI job (e.g., Jenkins or GitHub Actions) trigger Terragrunt that’s later shelling out to Terraform, which executes the job on your remote Terraform Cloud environment. This extra layer complicates the architecture and workflow and introduces another party to a sensitive flow.
Terraform Cloud offers some native integrations and third-party tools to incorporate into the Terraform workflow, like their proprietary policy-as-code framework, Sentinel. Leveraging Sentinel, you can create security and compliance guardrails. The disadvantage of Sentinel is that it’s not an industry standard and open-source like <a href="https://spacelift.io/blog/what-is-open-policy-agent-and-how-it-works" target="_blank" rel="noopener">Open Policy Agent (OPA)</a>. HashiCorp recently announced publishing <a href="https://www.hashicorp.com/blog/introducing-sentinel-policies-to-the-terraform-registry" target="_blank" rel="nofollow noopener">reusable Sentinel policies in their public Terraform Registry</a>, which may give Sentinel a new lease of life in the Terraform ecosystem.
Last but not least, Terraform Cloud recently announced a <a href="https://www.hashicorp.com/blog/terraform-cloud-adds-drift-detection-for-infrastructure-management" target="_blank" rel="nofollow noopener">drift detection feature</a>, which allows you to monitor the synchronization between your resources and their respective Terraform definitions. This feature can, to some extent, be replicated using /plan and /apply HTTP endpoints from Atlantis, but it’s a far cry from the native, built-in solution that Terraform Cloud offers.

If for any reason (compliance, regulatory needs, etc.), your organization needs an on-premise version of Terraform Cloud, you can use Terraform Enterprise. <a href="https://www.terraform.io/enterprise" target="_blank" rel="nofollow noopener">Terraform Enterprise</a> is a self-hosted distribution of Terraform Cloud.
It provides organizations with a private environment installation of the Terraform Cloud instance and enterprise-grade features like single sign-on, compliance enforcement with policies, and audit logging. 
If you plan on hosting your own Terraform Enterprise distribution, have a look at the <a href="https://www.terraform.io/enterprise/requirements/credentials" target="_blank" rel="nofollow noopener">requirements</a>, <a href="https://www.terraform.io/enterprise/reference-architecture" target="_blank" rel="nofollow noopener">reference architectures</a> for common cloud providers, and the <a href="https://www.terraform.io/enterprise/install/pre-install-checklist" target="_blank" rel="nofollow noopener">installation and configuration guide</a>.

<h3>On-premise Support</h3>
Both Atlantis and Terraform Enterprise offer the possibility to host your own installation of the tools. 
<h3>Integration with VCS providers</h3>
Most of the standard VCS providers are supported and integrated seamlessly with Atlantis and Terraform Cloud/Enterprise.
<h3>Integration with CI/CD</h3>
Both tools can be incorporated into your organization&#8217;s existing CI/CD flows and work in parallel with existing continuous integration jobs.

terraform-cloud-vs-atlantis

terraform cloud vs atlantis

<h3>SaaS Offering</h3>
Terraform Cloud/Enterprise is a managed service SaaS offering, while Atlantis doesn’t have a similar offering.
<h3>User Interface</h3>
Atlantis uses the same UI as the VCS provider that you are using and allows operators to trigger automation jobs from pull requests. Terraform Cloud/Enterprise comes with its own UI and portal.
<h3>Open Source Availability</h3>
Atlantis is entirely open-source and free, while Terraform Cloud/Enterprise is a proprietary solution, although it offers a free version.
<h3>Remote State Backend</h3>
As part of its offering, Terraform Cloud provides an excellent backend for the Terraform state, while Atlantis doesn’t.
<h3>High Availability</h3>
Terraform Cloud/Enterprise is designed for scale and offers a highly available setup. Scaling and building highly available setups with Atlantis requires additional effort.
<h3>Flexibility/Extensibility</h3>
Atlantis is very flexible and can integrate with other helper tools easily. Extending Terraform Cloud functionality is a bit more cumbersome.
<h3>Security Features</h3>
Atlantis keeps all the infrastructure changes and ties them to pull requests that can be used as audit logs. Terraform Cloud offers more elaborate security essentials like RBAC, single sign-on with SAML, and an audit log.
<h3>Drift Detection</h3>
Terraform Cloud offers <a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener">drift detection</a>, whereas Atlantis doesn’t by default, although similar functionality can be replicated with additional effort.
<h3>Cost Calculation</h3>
Terraform Cloud offers cost estimation, whereas Atlantis doesn’t by default, although similar functionality can be replicated by adding external tooling.

Actually, Atlantis and Terraform Cloud can be used together since <a href="https://www.runatlantis.io/docs/terraform-cloud.html" target="_blank" rel="nofollow noopener">Atlantis integrates seamlessly with Terraform Cloud/Enterprise</a>. It doesn’t matter which flavor or Terraform Cloud/Enterprise your team uses since Atlantis can work with all of them.
If that’s up your alley, you can have the “pull request-based” flow with some of the benefits of a managed solution, like history, access to policies with Sentinel, stopping runs, secret storage, etc. At this point, any generic CI tool would likely do the trick, so there may not be a point in maintaining a self-hosted installation of Atlantis to hand over the work to Terraform Cloud.

Terraform Cloud has been one of the first players in the space, but it’s not the most feature-rich platform anymore. Atlantis is great for small projects, but missing features and scaling might cause headaches.
If you’re choosing between Atlantis and Terraform Cloud, why not give a chance to <a href="https://spacelift.io/?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Batlantis_terraform%7D" target="_blank" rel="noopener">Spacelift</a>, a modern collaborative infrastructure delivery tool with a great focus on user experience? It works with Terraform, Terragrunt, and many other IaC frameworks, supports self-hosted on-prem workers, workflow customization, drift detection, and much more.
For more differences between the tools, I encourage you to check the article <a href="https://spacelift.io/blog/alternative-to-atlantis" target="_blank" rel="noopener">Spacelift vs. Atlantis</a> and <a href="https://spacelift.io/terraform-cloud-alternative" target="_blank" rel="noopener">Spacelift vs. Terraform Cloud.</a>
Spacelift provides a more mature way of automating the whole infrastructure provisioning lifecycle. Its <a href="https://docs.spacelift.io/concepts/run/" target="_blank" rel="noopener">flexible and robust workflow</a> allows teams to get up to speed quickly and collaborate efficiently. Spacelift is highly extensible and will enable teams to enhance the Terraform workflow with custom providers, linters, security tools, and any other custom tooling they see fit.
Spacelift connects directly to the version control system of your choice and provides a truly GitOps native approach. It can support setups with multiple repositories or massive monorepos and leverages the APIs of the VCS provider to give you visibility. 
Spacelift has a built-in CI/CD functionality for developing custom modules allowing teams to incorporate testing, checks, and linting early into the development phase of modules. Another benefit of using Spacelift is its flexible workflow management. It provides a policy-based process to handle dependencies between projects and deployments with <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Trigger Policies</a>. 
Spacelift provides a plethora of <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">Policies</a> to allow teams to define and automate rules governing the infrastructure as code. By utilizing <a href="https://www.openpolicyagent.org/" target="_blank" rel="noopener">Open Policy Agent</a>, users can create their own custom policies and ensure the compliance of Terraform resources.
Check out the <a href="https://docs.spacelift.io/" target="_blank" rel="noopener">Documentation</a> and start automating your infrastructure delivery seamlessly!

We have looked into two infrastructure automation and delivery tools, Atlantis and Terraform Cloud. We analyzed each of them and discussed their strengths and weaknesses, along with a feature comparison. Finally, we saw how a modern collaborative infrastructure delivery tool like Spacelift could be used as an alternative.
Thank you for reading, and I hope you enjoyed this article as much as I did.

Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation and controls to simplify and accelerate the provisioning of cloud based infrastructures.

Alternative to Atlantis – Spacelift

How Spacelift Can Improve Your Infrastructure as Code

Achieving the Atlantis Workflow with Spacelift

Atlantis or Terraform Cloud ? Take a look at two infrastructure automation and delivery tools, along with a feature comparison.

101-atlantis-vs-terraform-cloud

Atlantis vs Terraform Cloud

Atlantis vs. Terraform Cloud / Enterprise - Comparison

Formatting Terraform Code With the Terraform fmt Command

In this post, we will look at the <code class="gr kj kk kl km b">terraform fmt</code> command, first explaining what it does and when to run it, looking at the operation it performs, and showing some useful examples using the available options.

The <code class="gr kj kk kl km b">terraform fmt</code> command is used to format your configuration files into a canonical format and style. This command applies a subset of the <a class="au lp" href="https://www.terraform.io/language/syntax/style" target="_blank" rel="nofollow noopener">Terraform language style conventions</a>, along with other minor adjustments for readability.
As a best practice, <code class="gr kj kk kl km b">terraform fmt</code> should always be run on your configuration files, so formatting standards and language style conventions are applied across your configuration in a uniform manner. This helps code readability and ensures all configuration files are formatted the same, no matter which team member is writing the file. Consistency can help your team understand the code more quickly and easily, making the use of <code class="gr kj kk kl km b">terraform fmt</code> very important.
Each version of Terraform may introduce changes to the way the <code class="gr kj kk kl km b">terraform fmt</code> command actually adjusts your configuration files, so it should be run each time a different version of Terraform is used. It should be noted that Hashicorp acknowledges that formatting decisions are always subjective, and the style they have chosen might not be agreed upon by everyone, however, having a standard and providing a command to automatically format the configuration consistently achieves the primary goal.
Inserting a step into your <a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener">CI/CD pipeline</a> or running automated checks to ensure <code class="gr kj kk kl km b">terraform fmt</code> has been run on the configuration files is a good idea. One way of achieving this is to use the <code class="gr kj kk kl km b">-check</code> option, if there are changes required, it will return a non-zero code (1 for error); if there are no changes, it will return a zero code and should be allowed to pass to the next stage.
If a non-zero error code is returned, the <code class="gr kj kk kl km b">-diff</code> option can be used to display the diffs of the formatting changes that the <code class="gr kj kk kl km b">fmt</code> command will make. If there are no diffs, then the pipeline stage should be allowed to pass as complete, if there are diffs, then the pipeline should fail, and the writer of the configuration file should be notified that they need to run the <code class="gr kj kk kl km b">terraform fmt</code> command on their configuration files before committing to source control.

Usage: <code class="gr kj kk kl km b">terraform fmt [options] [TARGET]</code>
The target can be a directory or a single filename. You can also specify a <code class="gr kj kk kl km b">-</code> for the target, which then takes input from STDIN.
<code class="gr kj kk kl km b">terraform fmt</code> has the following optional flags:
<code class="gr kj kk kl km b"><a class="au lp" href="https://www.terraform.io/cli/commands/fmt#list-false" target="_blank" rel="noopener ugc nofollow">-list=false</a></code> &#8211; Don&#8217;t list the files containing formatting inconsistencies.
<code class="gr kj kk kl km b"><a class="au lp" href="https://www.terraform.io/cli/commands/fmt#write-false" target="_blank" rel="noopener ugc nofollow">-write=false</a></code> &#8211; Don&#8217;t overwrite the input files. (This is implied by <code class="gr kj kk kl km b">-check</code> or when the input is STDIN.)
<code class="gr kj kk kl km b"><a class="au lp" href="https://www.terraform.io/cli/commands/fmt#diff" target="_blank" rel="noopener ugc nofollow">-diff</a></code> &#8211; Display diffs of formatting changes
<code class="gr kj kk kl km b"><a class="au lp" href="https://www.terraform.io/cli/commands/fmt#check" target="_blank" rel="noopener ugc nofollow">-check</a></code> &#8211; Check if the input is formatted. The exit status will be 0 if all input is properly formatted and non-zero otherwise.
<code class="gr kj kk kl km b"><a class="au lp" href="https://www.terraform.io/cli/commands/fmt#recursive" target="_blank" rel="noopener ugc nofollow">-recursive</a></code> &#8211; Also, process files in subdirectories. By default, only the given directory (or current directory) is processed.
To show how these options work in practice, let&#8217;s look at some examples.
I have a main.tf file that looks like this — note the bad formatting!

terraform-fmt-example-main-tf

terraform fmt example main tf

After I run <code class="gr kj kk kl km b">terraform fmt</code> my file looks like this:

terraform-fmt-file-example

terraform fmt file example

<ul class="">
<li id="72a5" class="me mf io jn b jo jp js jt jw mg ka mh ke mi ki mj mk ml mm gs" data-selectable-paragraph="">The indentation of the required_providers block is fixed and instantly become easier to read.</li>
<li id="e51b" class="me mf io jn b jo mn js mo jw mp ka mq ke mr ki mj mk ml mm gs" data-selectable-paragraph="">Terraform lists the main.tf file after my <code class="gr kj kk kl km b">terraform fmt</code>command to show that it was changed. To stop this from being listed, the <code class="gr kj kk kl km b">-list=false</code> option can be used. Alternatively, the <code class="gr kj kk kl km b">-write=false</code> option will list the files to be changed but not actually write the changes.</li>
<li id="b5ae" class="me mf io jn b jo mn js mo jw mp ka mq ke mr ki mj mk ml mm gs" data-selectable-paragraph="">The extra spaces in the backend block and in the ad_group module call are not removed. That has to be done manually if required.</li>
</ul>
To use the <code class="gr kj kk kl km b">-diff</code> option, Terraform references the diff external command. If you don’t have diff installed already (likely on a Windows machine), you will see the following error:

terraform-fmt-main-tf-error

terraform fmt main tf error

Note that even though the error is generated, the file formatting is still corrected.
To resolve this error on a windows machine, you can install <a href="https://community.chocolatey.org/packages/diffutils" target="_blank" rel="nofollow noopener">GNU diffutils using chocolatey</a>. Chocolately is a popular package manager for Windows. Once installed, you can simply run the following command in an elevated command prompt:

terraform-fmt-install-choco

terraform fmt install choco

Once installed, restart your terminal, and the diff will be successfully generated:

terraform-fmt-diff

terraform fmt diff

This can be a useful option when running in automation to track the changes written to the file.
Moving on to the <code class="gr kj kk kl km b">-check</code> option, this will show one exit code (error) and list the files to be changed if there are changes to be made. If there are no changes, a zero exit code (pass) will be returned, and no files will be listed. As mentioned previously, this can be useful in automation.
Lastly, the <code class="gr kj kk kl km b">-recursive</code> option is useful to make sure all the Terraform configuration files in the directory structure are formatted. By default, <code class="gr kj kk kl km b">terraform fmt</code> only formats files in the current directory, not the subdirectories. Usually, project configuration files will be separated into logical folders or contain submodules, which will also need to be formatted correctly.

I hope with this blog post, you learned how to format your Terraform code with the Terraform fmt command.
If you’re interested in finding out how to use Spacelift to manage and automate your Terraform deployments check out our <a href="https://docs.spacelift.io/vendors/terraform/" target="_blank" rel="noopener">Terraform documentation</a> and sign up for a <a href="https://spacelift.io/free-trial?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bterraform_fmt%7D" target="_blank" rel="noopener">free trial</a>.
Cheers!

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

Common Patterns of Infrastructure as Code Architecture: Terraform & Terragrunt

What are Terraform Templates? Basics, Use Cases, Examples

Terraform Functions, Expressions, Loops (Examples)

The Terraform fmt command is used to format your configuration files into a canonical format and style. Learn how it can keep your code consistent.

100-terraform-fmt

Using Terraform fmt Command to Format Your Terraform Code

In this article, we will give an overview of what providers are in Terraform, and show how to use the provider for Amazon Web Services (AWS) with some useful examples.

A provider in Terraform is a plugin that enables interaction with an API. This includes Cloud providers such as AWS. The providers are specified in the Terraform configuration code, telling Terraform which services it needs to interact with.
For more details on Terraform providers (including the <a href="https://docs.spacelift.io/vendors/terraform/terraform-provider" target="_blank" rel="noopener">Spacelift Terraform provider</a>), check out our previous article: <a href="https://spacelift.io/blog/terraform-providers" target="_blank" rel="noopener">Terraform Providers Overview</a>.

To use Terraform to manage and deploy resources and infrastructure to AWS, you will need to use the AWS provider. You must configure the provider with the proper credentials before you can use it. This provider is maintained internally by the HashiCorp AWS Provider team.
To install the AWS provider, the example configuration below can be used (usually in your <code class="gr mp mq mr ms b">main.tf</code> file):

Note that the version of the provider is ‘pinned’ here to “4.27.0” (the latest at the time of writing). This is recommended best practice to avoid any unexpected changes in behavior between provider versions. Newer minor versions should be backward compatible and not introduce issues, however, major version updates may introduce breaking changes. Pinning the version allows you to update manually when you are confident there will be no adverse effects in doing so.
To find the latest version available, check out the <a href="https://registry.terraform.io/providers/hashicorp/aws/latest" target="_blank" rel="noopener">Terraform docs page</a>, or the <a href="https://github.com/hashicorp/terraform-provider-aws" target="_blank" rel="noopener">GitHub page</a>. GitHub will also give you a version history and details on issues raised by community members and stakeholders.

The configuration options that can be specified in the provider block are all optional for the AWS provider. As well as the general options available for all Terraform providers such as <code class="gr mp mq mr ms b">alias</code>and <code class="gr mp mq mr ms b">version</code>, these provider-specific options can be used to instruct Terraform on how to interact with AWS. For example, how to authenticate to your AWS subscription, specify the region, or assume an IAM role.
From the Terraform docs, there are a number of ways to authenticate using the AWS provider. Configuration for the AWS Provider can be derived from several sources, which are applied in the following order:
<ul>
<li id="ef75" class="lb lc my ld b le mk jp lg lh ml js lj ny mm ll lm nz mn lo lp oa mo lr ls lt ih gs">Parameters in the provider configuration</li>
<li id="ef35" class="lb lc my ld b le mk jp lg lh ml js lj ny mm ll lm nz mn lo lp oa mo lr ls lt ih gs">Environment variables</li>
<li id="c78e" class="lb lc my ld b le mk jp lg lh ml js lj ny mm ll lm nz mn lo lp oa mo lr ls lt ih gs">Shared credentials files</li>
<li id="c465" class="lb lc my ld b le mk jp lg lh ml js lj ny mm ll lm nz mn lo lp oa mo lr ls lt ih gs">Shared configuration files</li>
<li id="0ffc" class="lb lc my ld b le mk jp lg lh ml js lj ny mm ll lm nz mn lo lp oa mo lr ls lt ih gs">Container credentials</li>
<li id="9e0d" class="lb lc my ld b le mk jp lg lh ml js lj ny mm ll lm nz mn lo lp oa mo lr ls lt ih gs">Instance profile credentials and region</li>
</ul>
We will demonstrate the most common methods of using parameters in the provider configuration and environment variables.
However, before we can authenticate, we will need to create an access key for use with Terraform. Browse to the IAM section in the AWS console and ‘create new access key’.

terraform-aws-provider-iam-section

terraform aws provider - iam section

terraform-aws-provider-create-access-key

terraform aws provider - create access key

Note that the usual and recommended way to authenticate to AWS when using Terraform is via the AWS CLI, rather than any of the provider options listed above. To do this, first, <a class="au mj" href="https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html" target="_blank" rel="nofollow noopener">install the AWS CLI</a>, then type <code class="gr mp mq mr ms b">aws configure</code>.

terraform-aws-provider-aws-configure

terraform aws provider - aws configure

You can then enter your access key ID, secret access key, and default region.
<h3>Parameters in the provider configuration</h3>
To specify parameters in the provider configuration, we can set an access key and secret key as follows:

Note: This is NOT recommended! If your secrets are hardcoded into your configuration files and committed to source control, they may be compromised.
Similarly, we can specify a session access token, typically provided after a successful identity federation or Multi-Factor Authentication (MFA) login. With MFA login, this is the session token provided afterward, not the 6-digit MFA code used to get temporary credentials.

<h3>Environment Variables</h3>
To use the environment variables option to authenticate, credentials can be provided by using the <code class="gr mp mq mr ms b">AWS_ACCESS_KEY_ID</code>, <code class="gr mp mq mr ms b">AWS_SECRET_ACCESS_KEY</code>, and optionally <code class="gr mp mq mr ms b">AWS_SESSION_TOKEN</code> environment variables. The region can be set using the <code class="gr mp mq mr ms b">AWS_REGION</code> or <code class="gr mp mq mr ms b">AWS_DEFAULT_REGION</code> environment variables.
In this case, the provider configuration options block would be empty, as the credentials needed for authentication are supplied at the system level (i.e., these are local to the system you are running Terraform from). This is safer than hardcoding your secrets and tokens in the configuration files.

In the command shell, the environment variables are set as follows:

Alternatively, a token can be used instead of Key ID and Access Key:

This might be a useful option when running Terraform from a build agent in a <a href="https://spacelift.io/blog/ci-cd-pipeline" target="_blank" rel="nofollow noopener">CI/CD pipeline</a>.
<h3>Assume an IAM role</h3>
Another useful use of the AWS Provider options is the ability to assume an IAM role. This is done using the <code class="gr mp mq mr ms b">role_arn</code> option inside the <code class="gr mp mq mr ms b">assume_role</code> block.

In this article, we have shown the common uses of the Terraform AWS provider, showing how to authenticate using parameters in the provider configuration options, and using environment variables. For a full list of available options, check out the <a href="https://registry.terraform.io/providers/hashicorp/aws/latest/docs#container-credentials" target="_blank" rel="nofollow noopener">Terraform docs page</a>.
Cheers!

Spacelift effectively manages Terraform state, more complex workflows, supports policy as code, programmatic configuration, context sharing, drift detection, resource visualization, and includes many more features.

AWS IAM Policies : Best Practices & Creating an IAM Policy

How to Manage AWS Lambda Functions with Terraform: Tutorial

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

What is Terraform AWS provider? Learn how to authenticate using parameters in the provider configuration options and using environment variables.

102-terraform-aws-provider

How to Use the Terraform AWS Provider

The Terraform AWS Provider - Authenticate Terraform to AWS

Every time we provision a new set of cloud infrastructure, there is a purpose behind it. We do not create cloud infrastructure just for the sake of it. There are more actions performed on it to make it functional and useful.
For example, when we create an EC2 instance, we create it to accomplish certain tasks. Maybe the EC2 instance is responsible for executing heavy workloads, acts as a bastion host, or simply serves as the frontend for all incoming requests. Clearly, there are more actions to be performed on this instance &#8211; installing a web server, applications, databases, set network firewall, etc &#8211; to enable it for its function.
<a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> is a great IaC tool that helps us build infrastructure using code. Additionally, it is also possible to perform some of the above tasks when the EC2 instance boots or is destroyed. Such tasks are performed using provisioners in Terraform. In this post, we will understand the scenarios handled by provisioners, how they are implemented, and what are the better ways to do it.
But before we go ahead, it is worth noting that using Terraform Provisioners for the activities described in this post should be considered a last resort. The main reason here is that there are dedicated tools and platforms available that align well with the use cases discussed in this post. Hashicorp suggests the usage of Terraform provisioners should only be considered in those cases where we are left with no other option. More about this is described in the concluding section.

Provisioning mainly deals with configuration activities that happen after the resource is created. It may involve some file operations, executing CLI commands, or even executing the script. Once the resource is successfully initialized, it is ready to accept connections. These connections help Terraform log into the newly created instance and perform these operations.
The diagram below represents various types of provisioners you can implement using Terraform at various stages of provisioning.

terraform-provisioners-diagram

terraform provisioners diagram

In the entire plan-apply-destroy cycle of Terraform, provisioners are employed at various stages to accomplish certain tasks. The local-exec provisioner is the simplest provisioner as it executes on the machine that hosts and executes Terraform commands. If the Terraform is installed on the developer&#8217;s local machine, the local-exec provisioner would run on the same machine.
It is simply because, unlike remote-exec and file provisioners, local-exec provisioners do not require connecting to the newly created resources to perform their tasks. Local-exec provisioner executes the commands or scripts on the host system and works on the data generated by the given Terraform configuration or data made available on the host machine.
As far as the target resources are concerned, we have to set up certain mechanisms to provide connection details to perform actions on the target machines. This is because the credentials used to log in to an EC2 instance are AWS key pairs (public and private keys) primarily. 
We will take a look at these provisioners in detail in the next sections.

The local-exec provisioner works on the Terraform host &#8211; where Terraform configuration is applied/executed. It is used to execute any shell command. It is used to set or read environment variables, details about the resource which is created, invoke any process or application, etc.
If we ship any shell script along with the Terraform config, or if the shell scripts are already available on the host to be invoked, then local-exec provisioners are used to execute the same.
In the example below, we create an EC2 instance in AWS. It makes use of a local-exec provisioner to save the private_ip address of the instance which is created in a text file. This provisioner executes in the same working directory where <a href="https://spacelift.io/blog/terraform-apply" target="_blank" rel="noopener"><code>terraform apply</code></a> is run once the provisioning is successful.

Once this configuration is applied successfully, we find a new file being created in the project directory.

terraform-provisioners-create-a-new-file

terraform provisioners create a new file

The contents of the private_ip.txt file are as expected.

terraform-provisiones-private_ip-txt

terraform provisiones private_ip.txt

It is important to note that the command executes once the provisioning task is successful.

It is possible to specify when the provisioners should run. Terraform mainly performs two operations &#8211; apply and <a href="https://spacelift.io/blog/how-to-destroy-terraform-resources" target="_blank" rel="noopener">destroy</a>. If we want to run the provisioner to handle some logic at creation time, then we use the creation-time provisioner. Similarly, if we want to handle the destroy-time scenario differently, we use the destroy-time provisioners.
The “when” attribute used in the provisioner block determines whether a provisioner is creation-time or destroy-time. By default, if the “when” attribute is not specified, the provisioner runs at creation time. In the example below, we create separate text files that contain event-specific messages for both create and destroy events.

Try to apply and destroy the above Terraform configuration. This should generate two text files in respective order of operations &#8211; creation.txt and destruction.txt &#8211; in the project directory as below.

terraform-provisioners-generate-two-files

terraform provisioners generate two files

With text messages as below.

terraform-provisioners-text-messages

terraform provisioners text messages

Note: Artifacts generated using provisioners are not managed via the <a href="https://spacelift.io/blog/terraform-state" target="_blank" rel="noopener">Terraform state file</a>.

Before we proceed to the next sections, it is important to discuss the connection block. The file provisioner and remote-exec provisioners &#8211; both operate on the target resource that is created in the future. To enable Terraform to SSH into our Linux-based EC2 instance, we need a couple of things:
<ol>
<li style="font-weight: 400;" aria-level="1">AWS key pair</li>
<li style="font-weight: 400;" aria-level="1">Security group to open up the HTTP access</li>
</ol>
Navigate to the AWS console and manually create a key pair and save the private key file locally &#8211; on the Terraform host. I have created the key pair and named it “tfsn”. The name of the key file downloaded locally on my machine is “tfsn.cer”.
This information is used by Terraform provisioners to SSH into the EC2 instance. Additionally, we would use this key pair to SSH into the EC2 instance ourselves for validation purposes.
In the Terraform configuration, add the configuration for a new security group that enables HTTP traffic from the internet to access it via browser and SSH login required by provisioners. We would need this for validation when we discuss the remote-exec provisioner. Below is an example configuration of the security group in Terraform.

Note: In the sections that follow, the code snippets may not contain the security group configuration (like variables and provider), but it is assumed to be present.

The file provisioner is a way to copy certain files or artifacts from the host machine to target resources that will be created in the future. This is a very handy way to transport certain script files, configuration files, artifacts like .jar files, binaries, etc. when the target resource is created and boots for the first time.
To demonstrate this, we have a file named “letsdotech.txt” which we would like to copy into the home directory of the target EC2 instance. The project directory currently looks like the below. “tfsn.cer” is the private key file we created in the previous section for enabling the Terraform provisioner to SSH into the EC2 instance.

terraform-provisioners-tfsn-cer

terraform provisioners tfsn cer

Note: It is recommended to use better mechanisms to manage key files. Making the key file a part of the shared git repository is highly discouraged.
Terraform configuration for the EC2 instance along with file provisioner looks like below. Various attributes are described in the table that follows.

<table>
<tbody>
<tr>
<td>Attribute</td>
<td>Description</td>
</tr>
<tr>
<td>ami
&nbsp;</td>
<td>The Amazon Linux AMI.
&nbsp;</td>
</tr>
<tr>
<td>instance_type
&nbsp;</td>
<td>The size of the instance we need. It is currently set to “t2.micro”.
&nbsp;</td>
</tr>
<tr>
<td>key_name
&nbsp;</td>
<td>Name of the key file as created in the AWS console in the previous section.
&nbsp;</td>
</tr>
<tr>
<td>security_groups
&nbsp;</td>
<td>Reference to the Security Group name as created in the previous section.
&nbsp;</td>
</tr>
<tr>
<td>provisioner
&nbsp;</td>
<td>The file provisioner block contains information about the source and destination.
Source &#8211; is a path to the file on the Terraform host
Destination &#8211; is a path on the target EC2 instance, where the source file should be copied
&nbsp;</td>
</tr>
<tr>
<td>connection
&nbsp;</td>
<td>The connection block used by the file provisioner to SSH into the EC2 instance to copy the file.
Type &#8211; specifies the protocol i.e. SSH
Host &#8211; specifies the public IP address of the EC2 instance that will be created
User &#8211; Amazon Linux AMIs have ec2-user as the default user
Private_key &#8211; Path to the private key file named tfsn.cer stored locally
Timeout &#8211; 4 minutes. If the provisioner is not able to perform the given operation within 4 minutes, it throws an error.
&nbsp;</td>
</tr>
<tr>
<td>tags
&nbsp;</td>
<td>To name our EC2 instance.
&nbsp;</td>
</tr>
</tbody>
</table>

When the above configuration is applied, it creates the EC2 instance and we can verify the same in the AWS console. Once the instance is created, the file provisioner copies the text file to the destination path. We can verify the same from the Terraform output after apply.

Also, let us SSH into the EC2 instance and check if the file exists and the contents of the file.

This is as expected. Thus we have successfully used the file provisioner to copy a file from the local machine/Terraform host machine to the newly created EC2 instance. Every time we recreate the EC2 instance using the above configuration, the text file letsdotech.txt would always be made available, thanks to the file provisioner.

The remote-exec provisioners are similar to local-exec provisioners &#8211; where the commands are executed on the target EC2 instance instead of Terraform host. This is accomplished by using the same connection block that is used by the file provisioner.
We use a remote-exec provisioner to run a single command or multiple commands. The example below performs a simple task on the EC2 instance that is created by Terraform. Once the EC2 instance creation is successful, Terraform’s remote-exec provisioner logs in to the instance via SSH and executes the commands specified in the inline attribute array.

When we apply the above configuration, we can observe in the Terraform output that first the EC2 instance was created, then the remote-exec provisioner used the connection details to SSH into the instance, performed the tasks, and logged out.

As a result, when we log into the same EC2 instance, we should have a file named “hello.txt” with a message “Have a great day!” in its contents. Let us verify the same.

In this section, we use Terraform provisioners to install the Nginx web server. Installation of the Nginx web server successfully requires a few commands to download, install, and configure the same correctly. 
Instead of supplying these commands in an inline array attribute, we wrap them in a shell file and execute that shell file. This requires us to use the file provisioner to first transport the shell file in the target EC2 instance and then use the remote-exec provisioner to call the same.
Installing the Nginx web server is a relatively simple task, with few commands to execute. However, it gives us an idea of how complex tasks may be performed in a real-world scenario.
To prepare for our example, we first create the shell file named installnginx.sh, with the below contents. It simply updates the registries, installs Nginx, enables the Nginx service, and starts the server.

The project folder currently has the below files.

terraform-provisioners-project-folder

terraform provisioners project folder

Modify the EC2 configuration as below. Here, we have specified the file provisioner as discussed above. The inline commands modify the file permissions of installnginx.sh file, and then execute the same.

Apply the above configuration and observe the <a href="https://spacelift.io/blog/terraform-output" target="_blank" rel="noopener">Terraform output</a>.

The Terraform output indicates the sequence of activities it performed to provision this resource and install the Nginx. The activities can be summarized below.
<ol>
<li style="font-weight: 400;" aria-level="1">Created security group</li>
<li style="font-weight: 400;" aria-level="1">Created EC2 instance</li>
<li style="font-weight: 400;" aria-level="1">Executed file provisioner, which copied the file to the target instance</li>
<li style="font-weight: 400;" aria-level="1">Executed remote-exec provisioner, which executed the installnginx.sh file to install Nginx</li>
</ol>
To verify if the Nginx was installed successfully, open up the browser and access the home page with the public IP address displayed. If you are able to see the Nginx landing page, it means we have successfully used file and remote-exec provisioners to install the same.

terraform-provisioners-nginx

terraform provisioners nginx

Provisioners are great. But there are some limitations which we should consider before using them. As mentioned in the Terraform documentation, provisioners should be used as the last resort to achieve any kind of configuration management tasks possible with them.
When provisioners enable us to execute any command in the future target resource, it means a lot of power and responsibility. It opens up huge scope for activities that can be performed on the OS and application layer. There is no tracking or accountability for these actions.
If, for some reason, the provisioner tasks fail to run on a few machines, just increases the overhead of identifying them and deploying a workaround. Gaining an understanding of why a particular provisioner did not work on a set of machines can be very difficult and is highly hostile. Simply because there are several factors that are potentially unique to each resource.
In a way, provisioners extend into the space of configuration management software, but with low confidence. It is recommended to rely on software built for configuration management &#8211; like Chef, Puppet, Ansible, etc. &#8211; for such tasks. These tools have better control over configuration management, credential management, and better security standards. For additional support, check out <a href="https://spacelift.io/?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bterraform_provisioners%7D" target="_blank" rel="noopener">Spacelift</a>, a sophisticated and compliant infrastructure delivery platform that makes Terraform management easy.
Similarly, to pass the data into the target resource, prefer to use the cloud-native way to achieve the same. For example, while provisioning an AWS EC2 instance, the user_data attribute can be used to pass certain scripting data to the instances. These mechanisms depend on cloud-init software &#8211; which has become an industry standard &#8211; that takes care of the initialization process when the instance boots.
Provisioners have the most influence on the resource during the creation process since the scripts which are run during the instance boot process play a key role in the lifetime of the resource which has just started. If there is certain data, application, patches, etc. that can be pre-configured into a machine image, then prefer to create custom AMIs, over provisioners.

Spacelift effectively manages Terraform state, more complex workflows, supports policy as code, programmatic configuration, context sharing, drift detection, resource visualization and includes many more features.

How to Build AWS VPC using Terraform - Step by Step

The Lifecycle of a Terraform Resource - Lifecycle Meta-Argument

12 Terraform Best Practices to Improve your TF workflow

Learn about different types of Terraform provisioners at various stages of infrastructure provisioning. Keep in mind they should be considered a last resort.

106-terraform_provisioners

Terraform Provisioners

Terraform Provisioners : Why You Should Avoid Them

Terraform provides a well-defined and concise way to deploy infrastructure resources and changes. The typical workflow involves manual steps and checks that aren’t easily scalable and depend on human intervention to complete successfully. 
This article will look into different approaches to automating infrastructure provisioning with Terraform and the pros and cons of each one.

Terraform is one of the most prominent tools in the Infrastructure as Code space. Part of its success lies in the straightforward and easy-to-operate workflow it provides. If you aren’t familiar with Terraform, check the various <a href="https://spacelift.io/blog/terraform" target="_blank" rel="noopener">Terraform articles on Spacelift’s blog</a> to get an idea. 
The core Terraform workflow consists of three concrete stages. First, we generate the infrastructure as code configuration files representing our environment&#8217;s desired state. Next, we check the output of the generated plan based on our manifests. After carefully reviewing the changes, we apply the plan to provision infrastructure resources.

terrafrom-automation-diagram

terrafrom automation - diagram

Typically, this workflow involves some manual steps that are easily automatable. For example, using the Terraform CLI we have to run the command <a href="https://spacelift.io/blog/terraform-plan" target="_blank" rel="noopener"><code>terraform plan</code></a> to check the effect of our newly prepared configuration files. Similarly, we have to execute the command <a href="https://spacelift.io/blog/terraform-apply" target="_blank" rel="noopener"><code>terraform apply</code></a> to propagate the changes to the live environment. 
If you want to have all of the important Terraform commands in one place, take a look at our <a href="https://spacelift.io/blog/terraform-commands-cheat-sheet" target="_blank" rel="noopener">Terraform Cheat Sheet</a>.
For individual contributors and small teams, operating Terraform with the typical workflow and with manual steps to plan and apply the code might work perfectly fine. When teams get bigger, though, and we want to scale Terraform&#8217;s usage across organizations, we quickly reach bottlenecks and issues.

As Terraform’s usage across teams matures, adding some kind of deployment automation is beneficial. Let’s look into some of the approaches to running Terraform in automation.
<h3>1) Terraform Orchestration with Custom Tooling</h3>
Some teams continue running Terraform locally, but they add custom tooling, pre-commit hooks, and wrappers (e.g., <a href="https://terragrunt.gruntwork.io/" target="_blank" rel="nofollow noopener">Terragrunt</a>) to enhance the core Terraform workflow. There are different wrapper tools to choose from that provide extra functionalities, such as <a href="https://spacelift.io/blog/terragrunt-with-spacelift" target="_blank" rel="noopener">keeping your configuration DRY</a>, managing remote state, and managing different environments. Other teams prefer writing their own custom wrapper scripts to prepare Terraform working directories according to some standards. 
This semi-manual approach is more native to the core Terraform workflow and allows direct access to output and running operational commands (e.g., <a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform" target="_blank" rel="noopener">terraform import</a>). On the other hand, since it involves manual steps, it is error-prone and requires human intervention. One more thing to note is that usually, this approach requires privileged access to the underlying infrastructure provider as well as the Terraform state file, which might be a security risk.
One step ahead, some teams develop their own custom platform on top of Terraform manifests that allow end users to provision infrastructure resources via tweaking some configuration changes on a UI. 
This approach abstracts any unnecessary level of detail and Terraform-specific knowledge from end users and allows them to manage infrastructure on demand without another team blocking them. On the flip side, this path requires substantial engineering effort to develop a useful platform and adds a maintenance overhead to the platform team. 
<h3>2) Building infrastructure provisioning pipelines</h3>
The most common approach for running Terraform in automation is to build infrastructure provisioning pipelines with a CI/CD tool. With this method, teams can enforce best practices, add tests and checks, and integrate the Terraform workflow to any CI/CD tool they are familiar with. 
Building infrastructure delivery pipelines in <a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener">CI/CD tools</a> brings several challenges as it needs to adjust the core Terraform workflow for non-interactive environments. 
The first step for automating Terraform deployments is to embrace Infrastructure as Code and GitOps and store your manifests in the version control system of your choice. Having versioned repositories as the source of truth for automating infrastructure delivery is a core requirement. 
Next, the typical Terraform workflow is adjusted for running in remote environments. Since the run might be triggered in ephemeral environments, we have to initialize the Terraform working directory, run any custom checks or tests and produce a planned output for changing resources. 
A common tactic is integrating these steps as part of every proposed code change (e.g., Pull Requests). Once other team members review the proposed changes and find the produced plan acceptable, they can approve and merge the Pull Request. Merging new code to the branch that is considered the source of truth triggers a terraform apply to provision the latest changes. 
<h3>10 things to consider for building your own automated Terraform delivery pipelines:</h3>
<ul>
<li style="font-weight: 400;" aria-level="1">Your code should be stored in a version control system.</li>
<li style="font-weight: 400;" aria-level="1">Leverage the <code>-input=false</code> flag to disable interactive prompts. The command line, environment variables, or configuration files should provide any necessary input.</li>
<li style="font-weight: 400;" aria-level="1">Use a backend that supports remote <a href="https://spacelift.io/blog/terraform-state" target="_blank" rel="noopener">Terraform State</a> to allow runs on different machines and state locking for safety against race conditions. </li>
<li style="font-weight: 400;" aria-level="1">Prepare an environment to run Terraform with any dependencies pre-installed. To avoid downloading the provider plugins every time with the init command, use the flag <code>-plugin-dir</code> to provide the path of preconfigured plugins on the automation system.</li>
<li style="font-weight: 400;" aria-level="1">To allow changing the default backend configuration to deploy with different permissions or to different environments, you can utilize the <code>-backend-config=path</code> flag when initializing. If you only need to run checks on the Terraform files that don&#8217;t require initializing the backend (e.g., terraform validate), consider using the flag <code>-backend=false</code>.</li>
<li style="font-weight: 400;" aria-level="1">Integrate Terraform formatting, validating, linting, checking policies, and custom testing to the <a href="https://spacelift.io/blog/ci-cd-pipeline" target="_blank" rel="noopener">CI/CD pipelines</a> to ensure your code conforms to your organization’s standards. </li>
<li style="font-weight: 400;" aria-level="1">Usually, CI/CD pipelines run on distributed systems. To ensure that we will apply the correct plan, we can output the plan to a file and package the whole terraform working directory after each plan. These artifacts will be stored somewhere to be fetched by the apply step to avoid accidentally applying different changes to the ones reviewed. </li>
<li style="font-weight: 400;" aria-level="1">Optionally, use the flag <code>-auto-approve</code> to apply the changes without human intervention. </li>
<li style="font-weight: 400;" aria-level="1">Use environment variables prefixed with <code>TF_VAR_</code> to pass any necessary values using the CI/CD tool mechanisms. </li>
<li style="font-weight: 400;" aria-level="1">Set the environment variable <code>TF_IN_AUTOMATION</code> to indicate that Terraform is running in automation mode. This adjusts the output of some commands to avoid outputting messages that are misleading in an automation environment.</li>
</ul>
Integrating the Terraform workflow in CI/CD infrastructure provisioning pipelines is a great way to automate infrastructure delivery. Running <a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener">Terraform in CI/CD</a> automation eliminates the need for people’s privileged access, enforces a consistent workflow and way of working, and removes any human intervention.
On the other hand, we have to take into account considerations for running on distributed systems, spend substantial engineering time and put a lot of effort into building a custom pipeline that satisfies our team’s needs

A more robust approach to automating your Terraform workflows end-to-end would be to use <a href="https://spacelift.io/?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bterraform_automation%7D" target="_blank" rel="noopener">Spacelift</a>, a collaborative infrastructure delivery tool. Spacelift provides a more mature way of automating the whole infrastructure provisioning lifecycle. Its <a href="https://docs.spacelift.io/concepts/run/" target="_blank" rel="noopener">flexible and robust workflow</a> allows teams to get up to speed quickly and collaborate efficiently.
Spacelift connects directly to the version control system of your choice and provides a truly GitOps native approach. It can support setups with multiple repositories or massive monorepos and leverages the APIs of the VCS provider to give you visibility. 
The Spacelift runners are fully customizable Docker containers. This allows teams to enhance the Terraform workflow with custom providers, linters, security tools, and any other custom tooling you might see fit. 
Spacelift has a built-in CI/CD functionality for developing custom modules allowing teams to incorporate testing, checks, and linting early into the development phase of modules. Another benefit of using Spacelift is its flexible workflow management. It provides a policy-based process to handle dependencies between projects and deployments with <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Trigger Policies</a>. 
Sometimes, the actual state of live environments drifts from the desired state, a concept known as configuration drift. Spacelift can assist you in <a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">automatically detecting and, if desired, reconciling configuration drift</a>.
Spacelift provides a plethora of <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">Policies</a> to allow teams to define and automate rules governing the infrastructure as code. By utilizing <a href="https://www.openpolicyagent.org/" target="_blank" rel="noopener">Open Policy Agent</a>, users can create their own custom policies and ensure the compliance of Terraform resources.
Check out the <a href="https://docs.spacelift.io/" target="_blank" rel="noopener">Documentation</a> and start automating your infrastructure delivery easily!

In this blog post, we discussed different approaches and strategies to automate Terraform deployments and provision infrastructure in an automated fashion. We looked into the typical Terraform workflow and saw how we can enhance it with orchestration tools. Finally, we saw how Spacelift greatly assists us in bringing our Terraform automation to the next level.
Thank you for reading, and I hope you enjoyed this article as much as I did.

Automate your infrastructure provisioning, build more complex workflows based on Terraform using policy as code, programmatic configuration, context sharing, drift detection, resource visualization, and many more.

Infrastructure Drift Detection and How to Fix It With IaC Tools

Learn different approaches to Terraform automation and provision infrastructure in an automated fashion. See how to enhance it with orchestration tools.

104-terraform-automation

Terraform automation

How to Automate Infrastructure Provisioning with Terraform

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

Kubernetes Guides and Tutorials | Spacelift Blog

Kubernetes

This article will compare two of the most dominant tools in the cloud infrastructure space, Terraform and Kubernetes. These two tools share some similarities but are built to serve different purposes. Terraform is a tool focused on infrastructure provisioning and operates in the Infrastructure as code space. Kubernetes focuses on running container workloads and operates in the container orchestration space.
We will briefly take a look at each one of them and discuss their similarities and differences.
To learn more about these two foundational cloud infrastructure technologies, check the multiple tutorials on Spacelift’s blog around <a href="https://spacelift.io/blog/kubernetes" target="_blank" rel="noopener" data-saferedirecturl="https://www.google.com/url?q=https://spacelift.io/blog/kubernetes&amp;source=gmail&amp;ust=1661233733361000&amp;usg=AOvVaw0U55gyVSYyB8fmHIbefmpF">Kubernetes</a> and <a href="https://spacelift.io/blog/terraform" target="_blank" rel="noopener" data-saferedirecturl="https://www.google.com/url?q=https://spacelift.io/blog/terraform&amp;source=gmail&amp;ust=1661233733361000&amp;usg=AOvVaw3AGtv2eOlNveyd8H80rYk_">Terraform</a>.

<a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> is an open-source software tool that allows us to safely and predictably manage infrastructure at scale using cloud-agnostic and infrastructure as code principles. It is a powerful tool developed by Hashicorp that enables infrastructure provisioning both on the cloud and on-premises. 
Terraform is written in a declarative configuration language, Hashicorp Configuration Language (HCL), and facilitates the automation of infrastructure management in any environment. It allows IT professionals to collaborate and perform changes safely on cloud environments and scale them on-demand according to the business needs. 
<a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Modules</a> provide excellent reusability and code-sharing opportunities to boost the collaboration and productivity of teams operating on the cloud. <a href="https://spacelift.io/blog/terraform-providers" target="_blank" rel="noopener">Providers</a> are plugins that offer integration and interaction with different APIs and are one of the main ways to extend Terraform’s functionality. 
Terraform keeps an internal <a href="https://www.terraform.io/language/state" target="_blank" rel="nofollow noopener">state</a> of the managed infrastructure, which represents resources, configuration, metadata, and their relationships. The state is actively maintained by Terraform and utilized to create plans, track changes, and enable modifications of infrastructure environments. The state should be stored remotely to allow teamwork and collaboration as a best practice. 
The core Terraform workflow consists of three concrete stages. First, we generate the infrastructure as code configuration files representing our environment&#8217;s desired state. Next, we check the output of the generated plan based on our manifests. After carefully reviewing the changes, we apply the plan to provision infrastructure resources.

terraform-vs-kubernetes-terraform-workflow

terraform vs kubernetes - terraform workflow

<a href="https://kubernetes.io/" target="_blank" rel="nofollow noopener">Kubernetes</a> (K8s) is an open-source system for container orchestration, automating deployments, and managing containerized apps. Its powerful orchestration system enables applications to scale seamlessly and achieve high availability. It has been designed and developed by Google, leveraging its vast experience in running and maintaining critical workloads in production.
Kubernetes strives to be cloud agnostic at its core, providing great flexibility in running workloads across cloud and on-premises environments. Additionally, it is designed with extensibility in mind, providing the option to add features and custom tooling to clusters easily.  
One of its main benefits is the self-healing capabilities it provides. Containers that fail are automatically restarted and rescheduled, nodes can be configured to be automatically replaced, and traffic is served only by healthy components based on health checks.  
Rollouts are handled progressively, and Kubernetes provides smart mechanisms to monitor application health during deployments. Rolling back problematic changes happens automatically if the application health doesn’t report a healthy status after a new deployment. Keeping the application running while rolling out new software versions has been a hot topic in the Kubernetes ecosystem over the past years, with many possible deployment strategies.
Kubernetes handles service discovery and load-balances traffic between similar pods natively without the need for complex external solutions. It has extendable built-in mechanisms to manage configuration and secrets for your applications. Scaling your applications has never been easier since it provides autoscaling options, scaling through commands, or via a UI. 
Kubernetes provides a cluster of nodes, a group of worker machines that run containerized applications. Each node hosts pods that hold application workload containers. The brain of the whole system is the control plane. Each cluster consists of several components that manage the worker nodes and pods and guarantee operational continuity. 
The API server is the component exposing the Kubernetes API and operates as the front-end of the control plane by handling all the communication between other parts. The etcd component is used to store all cluster data and state. The scheduler manages how pods are assigned to nodes and takes all the workload scheduling decisions. The controller manager components run different controller processes to ensure that the cluster&#8217;s desired state matches its current state. The cloud controller manager integrates Kubernetes clusters with external cloud providers, embeds their logic, and links the Kubernetes API with the Cloud Provider’s API. On each node, the kubelet is the agent responsible for running containers in pods, and kube-proxy is the component that adds the necessary networking capabilities for communication between pods and nodes.

terraform-vs-kubernetes-kubernetes-cluster

terraform vs kubernetes - kubernetes cluster

Check out this article to learn more about the <a href="https://spacelift.io/blog/kubernetes-cluster" target="_blank" rel="noopener">Key Kubernetes Cluster Components</a>.

See the comparison of Terraform and Kubernetes, the most dominant tools in the cloud infrastructure space. Learn about their similarities and differences. 

Terraform Plan Command – Check Your IaC Deployment

Get the newsletter

Recent posts

Atlantis vs. Terraform Cloud / Terraform Enterprise – Comparison

Terraform fmt Command – How to Format Terraform Code

The Terraform AWS Provider – Authenticate Terraform to AWS

Terraform Provisioners : Why You Should Avoid Them

How to Automate Infrastructure Provisioning with Terraform

Terraform vs. Kubernetes : Key Differences and Comparison

Managing Terraform State – Best Practices & Examples

How to Build AWS VPC using Terraform – Step by Step

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

The Lifecycle of a Terraform Resource – Lifecycle Meta-Argument

Terraform Custom Conditions – Preconditions & Postconditions

Terraform Providers Overview – How To Use Them & Examples