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

Jacob Martin

Occasionally you might want to rename an AWS S3 bucket you are managing with Terraform. However, names of S3 buckets are immutable, which means you can’t change them directly. If you tried, Terraform would destroy the old one and then create a new one, resulting in data loss.
To avoid this, you need to create a new bucket with the desired name, move the data over to it, make the relevant Terraform state replacements, and finally delete the old bucket.
In this post you will learn how to rename an AWS S3 bucket in <a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a>. First things first &#8211; let’s say you have a bucket definition in your Terraform code:

and you want to change the name of the bucket to <code>new-name</code>.

Firstly, we’ll need to <a href="https://spacelift.io/blog/terraform-aws-s3-bucket" target="_blank" rel="noopener">create a new bucket</a>. You can do this using the AWS CLI or the <a href="https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-help-gsg.pdf" target="_blank" rel="nofollow noopener">AWS console</a>. Just make sure to properly replicate the old settings, especially the ACL (so that your data doesn’t accidentally become public).
Now, we can copy all the files from the old to the new bucket:

Now that we have our new bucket, we need to remove the old one from our Terraform state and <a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform" target="_blank" rel="noopener">import</a> the new one in its place:

If you tried to run Terraform now, it would show you that there’s drift—and yes, there would be! We’ve just imported a bucket into a resource which still has <code>old-name</code> in the config.

That’s why we now have to finally change the name of the bucket in our Terraform config:

If you run Terraform now, you’ll see that there are no changes to be made.

<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>

If you want to, you can now delete your old bucket using:

Make sure all the data has successfully been copied over to the new bucket.

If you’re using Spacelift then you can use <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">tasks</a> to run the above arbitrary AWS CLI commands. The default runner image already contains the AWS CLI, so no changes are necessary there.
One additional thing you can do is <a href="https://docs.spacelift.io/concepts/stack/stack-locking" target="_blank" rel="noopener">lock the Stack</a> while you’re running the migration, this way nobody will accidentally run Terraform or make any other changes while you’re moving the data.
And that’s it! If you have any questions about how to rename an AWS S3 bucket, drop me a line in the comments and I’ll get back to you straight away.
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 the future of the Terraform ecosystem, and having a truly open-source project to support all your IaC needs is the main priority.

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.

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

frame-8479

Frame 8479

Provisioning AWS EKS Cluster with Terraform - Tutorial

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

Bootstrap Complete Amazon EKS Clusters with EKS Blueprints for Terraform

Learn how to rename an AWS S3 bucket in Terraform. See renaming process of Amazon s3 bucket in a few simple steps.

8-rename-aws-s3-bucket

How to rename aws s3 bucket

How to Rename an AWS S3 Bucket in Terraform - Step by Step

Learn more about new features, updates, and Spacelift product announcements.

Product Features and Updates | Spacelift Blog

Product

Marcin Wyszynski

Atlantis is an old and battle-tested self-hosted tool that provides a layer of automation and collaboration for Terraform. Lacking a user interface other than server <a href="https://www.runatlantis.io/docs/server-configuration.html#flags" target="_blank" rel="nofollow noopener">flags</a> and <a href="https://www.runatlantis.io/docs/server-side-repo-config.html#do-i-need-a-server-side-repo-config-file" target="_blank" rel="nofollow noopener">YAML configuration files</a>, Atlantis uses your VCS as one, listening for pull request notifications and posting feedback as comments.
Using Atlantis has two major benefits over running Terraform in a “generic” CI system. First, it strikes the right balance between specialized and flexible: <a href="https://www.runatlantis.io/docs/custom-workflows.html" target="_blank" rel="nofollow noopener">custom workflows</a> give you a level of control that’s not possible within a tool like <a href="https://spacelift.io/blog/what-is-terraform-cloud" target="_blank" rel="noopener">Terraform Cloud</a>. Second, it runs on your infrastructure, which allows it to access resources inside a VPC or use cloud-specific dynamic credentials.
<a href="https://spacelift.io/atlantis-alternative" rel="">Spacelift</a> embraces all those characteristics of Atlantis but offers them in a modern and sophisticated SaaS product that provides:
<ul>
<li style="font-weight: 400;" aria-level="1">a more intuitive, <a href="https://docs.spacelift.io/concepts/policy/git-push-policy" target="_blank" rel="noopener">versatile</a>, and <a href="https://docs.spacelift.io/concepts/run/#run-state-machine" target="_blank" rel="noopener">robust</a> workflow;</li>
<li style="font-weight: 400;" aria-level="1">extremely granular access controls on <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">account</a> and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">project</a> level that works well with an <a href="https://docs.spacelift.io/integrations/single-sign-on/" target="_blank" rel="noopener">identity provider of your choice</a> (SSO);</li>
<li style="font-weight: 400;" aria-level="1">an <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">automated code review</a> and <a href="https://docs.spacelift.io/concepts/policy/task-run-policy" target="_blank" rel="noopener">threat detection</a> using a consistent open-source <a href="https://www.openpolicyagent.org/" target="_blank" rel="nofollow noopener">policy-as-code framework</a>;</li>
<li style="font-weight: 400;" aria-level="1">the ability to <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">declare complex workflows</a> between projects across multiple repositories;</li>
<li style="font-weight: 400;" aria-level="1">a <a href="https://docs.spacelift.io/vendors/terraform/module-registry" target="_blank" rel="noopener">built-in private module registry</a> with a full CI system for modules;</li>
<li style="font-weight: 400;" aria-level="1">effortless setup and customization with <a href="https://docs.spacelift.io/concepts/configuration/environment" target="_blank" rel="noopener">per-project environment management</a> and <a href="https://docs.spacelift.io/integrations/docker" target="_blank" rel="noopener">Docker integration</a>;</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/vendors/terraform/terraform-provider" target="_blank" rel="noopener">programmatic configuration</a> using Terraform;</li>
<li aria-level="1"><a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">drift detection;</a></li>
<li style="font-weight: 400;" aria-level="1">… and a myriad of creature comforts like <a href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">contexts</a>, <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">tasks</a>, or <a href="https://docs.spacelift.io/concepts/stack/#stack-locking" target="_blank" rel="noopener">stack locking</a>;</li>
</ul>
Let’s talk through each of these features one by one.

One of most frequent challenges while using Atlantis in practice is a non-intuitive workflow driven by its reliance on pull requests. Not only is it a lot of work to set up multiple <a href="https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#supporting-terraform-workspaces" target="_blank" rel="nofollow noopener">workspaces</a> pointing to the same Git repository but the result is fragile and nondeterministic. Since there’s no concept of mapping projects to branches or tags, anyone that can comment on an approved pull request can deploy arbitrary code to production, even if the approval was meant for a short-lived experimental environment.
Spacelift does not depend on pull requests. Sure, it will post beautiful comments there for your convenience, but it’s mostly driven by push and tag events, so it’s easy to build a sophisticated Git flow. Spacelift will report the outcome of its jobs as commit status checks, which then allows you to block merging the code on a failing Spacelift check. There are <a href="https://docs.spacelift.io/concepts/run/#where-do-runs-come-from" target="_blank" rel="noopener">two main types of runs</a> &#8211; proposed and tracked. By default, each project points at a particular branch (and optionally also a path) &#8211; pushing to that branch will trigger a tracked run &#8211; one that can be applied. This behavior can be customized using <a href="https://docs.spacelift.io/concepts/policy/push-policy/" target="_blank" rel="noopener">Git push policies</a>. Thanks to that, Spacelift can provide the same level of comfort and security to teams using one project per repository and those using monorepos with hundreds of interdependent projects. You can read more about our approach to VCS integration <a href="https://docs.spacelift.io/integrations/source-control/github#tracked-branches" target="_blank" rel="noopener">here</a>.

Another pain point when using Atlantis at scale is its access control model. By relying on comments on pull requests to drive infrastructure deployments, Atlantis effectively yields control over your infrastructure to the VCS provider. While this is usually fine when a single repository drives a single Terraform project, this becomes a huge liability for more complex scenarios.
Spacelift ships with a sophisticated mechanism allowing administrators to declare <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">who can log in</a> (and under what circumstances) and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">what should be their level of access</a> to each of the managed projects. Since it’s 2020, Spacelift ships with SSO out of the box, supporting every identity provider that speaks SAML 2.0 protocol. Even our <a href="https://docs.spacelift.io/integrations/chatops/slack" target="_blank" rel="noopener">Slack integration</a> can be subject to policy controls, allowing an admin to grant access to a project <a href="https://docs.spacelift.io/integrations/chatops/slack#managing-access-to-stacks-with-policies" target="_blank" rel="noopener">based on Slack-specific data</a> (think team, channel, user etc.). For extra protection, powerful features like Tasks have their own independent policy controls.

Both Spacelift and Atlantis let you use <a href="https://www.openpolicyagent.org/" target="_blank" rel="nofollow noopener">Open Policy Agent</a> &#8211; an open-source solution endorsed by <a href="https://www.cncf.io/" target="_blank" rel="nofollow noopener">Cloud Native Computing Foundation</a> &#8211; to ensure that your infrastructure is compliant with industry best practices and your company policies. Atlantis integrates with <a href="https://www.runatlantis.io/docs/policy-checking.html#how-it-works" target="_blank" rel="nofollow noopener">conftest</a> to achieve that and lets you verify each Terraform plan using OPA policies.
Spacelift goes a few steps further though and puts policy-as-code in the center of its value proposition and builds a consistent, <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">robust policy framework</a>. Apart from providing a comprehensive automated change review and ensuring compliance of your <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">Terraform changes</a>, Spacelift uses the same approach to allow you to declare rules around <a href="https://docs.spacelift.io/concepts/policy/login-policy" target="_blank" rel="noopener">account</a> and <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">project access</a>, <a href="https://docs.spacelift.io/concepts/policy/push-policy/" target="_blank" rel="noopener">handling push notifications</a>, <a href="https://docs.spacelift.io/concepts/policy/run-initialization-policy" target="_blank" rel="noopener">starting runs</a> and <a href="https://docs.spacelift.io/concepts/policy/task-run-policy" target="_blank" rel="noopener">triggering tasks</a>, and creating <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">relationships between projects</a>. It also provides the Policy Workbench, which lets you view past executions of your policy &#8211; including the inputs and decisions that have been made &#8211; and lets you interactively edit your policy, while simulating its execution on these previous inputs. You can use our <a href="https://github.com/spacelift-io/terraform-starter" target="_blank" rel="nofollow noopener">starter repo</a> to quickly provision a bunch of policies and get a feel for how you can work with them in Spacelift.

Handling interdependencies between projects has always been Terraform’s Achilles&#8217; heel and Atlantis is no different in that regard. The usual approach to this problem is adding another layer of abstraction in the form of a Terraform wrapper like <a href="https://terragrunt.gruntwork.io/" target="_blank" rel="nofollow noopener">Terragrunt</a>. While this breaks the problem into smaller chunks, it’s only a partial solution achieved at a cost of locking yourself into another dependency.
<a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Spacelift’s trigger policies</a> on the other hand provide a smart, declarative automation layer on top of vanilla Terraform. These allow you to plug into state changes of individual projects and declare dependencies that should be resolved following the changes that have just been applied. In fact, this is just a subset of all use cases covered by trigger policies. <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">Read more</a> to discover other exciting possibilities.

<ul>
<li><a href="https://spacelift.io/blog/atlantis-terraform" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Atlantis vs. Terraform Cloud vs. Terraform Enterprise&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Atlantis vs. Terraform Cloud vs. Terraform Enterprise</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>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
</ul>

Another problem that one needs to solve externally when using Atlantis is authoring and maintaining reusable Terraform modules for your organization. Terraform is flexible in allowing modules to come from <a href="https://www.terraform.io/docs/modules/sources.html" target="_blank" rel="nofollow noopener">various sources</a> but ensuring confidential access as well as testing and versioning are left to you, the user.
Until now, the golden standard in that regard has been the <a href="https://www.terraform.io/docs/cloud/registry/index.html" target="_blank" rel="nofollow noopener">private module registry from HashiCorp</a>. But Spacelift offers that, and much more. Far from being just a glorified package manager, Spacelift adds a <a href="https://docs.spacelift.io/vendors/terraform/module-registry" target="_blank" rel="noopener">full CI solution for Terraform modules</a>, out of the box and free of charge. You can thus ensure that your private modules are healthy before you distribute them to the rest of your organization.

If you manage a single or a handful of rarely changing projects using Atlantis, it’s likely that you just set it up once and forget about it. But in a more dynamic environment, where microservices come and go, new environments proliferate and new product teams require their own <a href="https://spacelift.io/blog/terraform-workspaces" target="_blank" rel="noopener">Terraform workspaces</a>, the need to configure Atlantis each and every time becomes a major nuisance putting a lot of pressure on your DevOps team.
Enter Spacelift. In Spacelift, much of the configuration can be handled by the project owners themselves &#8211; you can add Terraform and/or <a href="https://docs.spacelift.io/concepts/configuration/environment" target="_blank" rel="noopener">environment variables</a> and mount files (even inject Terraform code!) programmatically or through the GUI without the need for administrative privileges or changing the central server configuration. For administrators, adding new projects requires minimal hassle since there’s no need to set up webhooks or change any YAML. And it can all be done programmatically, using Terraform.

What comes as a pleasant surprise to long-time Atlantis users, Spacelift entities like stacks, contexts, modules or policies as well as their configuration can be managed in a declarative way using your favorite infra-as-code tool. Yes, that’s right &#8211; <a href="https://docs.spacelift.io/vendors/terraform/terraform-provider" target="_blank" rel="noopener">Spacelift offers a Terraform provider</a> that allows you to manage the lifecycle of its own resources programmatically.
 Administrative stacks get credential-less access to the subset of our <a href="https://docs.spacelift.io/integrations/api" target="_blank" rel="noopener">GraphQL API</a> that does not involve managing the actual infrastructure. For more sophisticated use cases, Spacelift allows you to generate API keys that are subject to the same access controls as normal users are, allowing you to create single-purpose tokens for restricted use by your internal scripts.

<a href="https://www.hashicorp.com/blog/detecting-and-managing-drift-with-terraform" target="_blank" rel="nofollow noopener">Infrastructure drift happens.</a> Either somebody will make manual changes while debugging and then forget about them, or you might have data sources whose outputs change periodically. Normally, you would notice these changes only after you execute your next plan or apply.
Spacelift has got you covered here. You can configure periodic <a href="https://docs.spacelift.io/concepts/stack/drift-detection" target="_blank" rel="noopener">drift detection</a> to be notified whenever drift happens and take immediate action. You can go a step further too with optional automatic <a href="https://docs.spacelift.io/concepts/stack/drift-detection#to-reconcile-or-not-to-reconcile" target="_blank" rel="noopener">reconciliation</a>, ensuring your infrastructure always resembles your Terraform configuration.

Last but not least, Spacelift puts an emphasis on great user experience, offering a myriad of creature comforts. <a href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">Contexts</a> for example allow you to attach entire collections of configuration to individual stacks and modules. <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">Tasks</a> provide a powerful audited way of running one-off administrative commands on an initialized Terraform environment &#8211; subject to <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">their own policy constraints</a>. <a href="https://docs.spacelift.io/concepts/stack/#stack-locking" target="_blank" rel="noopener">Stack locking</a> allows a single individual to take exclusive control over a stack to ensure that nobody is able to modify its state while crucial changes are being made. The <a href="https://docs.spacelift.io/concepts/resources" target="_blank" rel="noopener">resources visualization</a> shows you all the resources you’re managing in your account, when and how they’ve last been updated, and lets you slice and dice them using a plethora of views, filters and groupings.

Spacelift is an Atlantis alternative that embraces all of its features, offering them in a modern and sophisticated SaaS product that provides a more intuitive, versatile, and robust workflow, granular access control, drift detection, and many more.

Importing Existing Infrastructure Into Terraform - Step by Step

What is OPA? Open Policy Agent Examples & Tutorial

5 Ways to Manage Terraform at Scale - Best Practices

Spacelift is an Atlantis alternative that embraces all the characteristics of Atlantis but offers them in as a modern and sophisticated SaaS product.

7-alternative_to_atlantis

Alternative to Atlantis

Atlantis vs. Spacelift: Key Differences and Similarities

Mudassar Shafique

If you have heard of Terraform but are not exactly sure what it is or when to use it, you have landed at the right place. This post will cover it all starting off with defining Terraform.

<dfn>Terraform</dfn> is a powerful Infrastructure as Code (IaC) software tool offered by HashiCorp. It facilitates provisioning and managing your infrastructure on-prem and in the cloud. It can be easily extended with the help of its plugin-based architecture.

Terraform can be connected with different infrastructure hosts and achieve complex management scenarios and compliance across multiple clouds. Its configuration can be easily packaged, shared, and reused in the form of <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform modules</a>.
In this post we will go over some basic elements and features of Terraform that can help you get started. Before we move forward, however, let’s discuss Infrastructure as Code (IaC) a bit more to develop a good understanding of Terraform.

Traditionally, the process of preparing a Windows or Linux server for your lab or data center consisted of several steps involving mouse clicks, running scripts, and manually configuring different aspects such as storage and networking. Doing this at scale for hundreds or thousands of servers becomes increasingly complex and error-prone.
<a href="https://www.redhat.com/cms/managed-files/pa-terraform-and-ansible-overview-f14774wg-201811-en.pdf" target="_blank" rel="noopener">IaC</a> makes this process much easier by allowing you to define and provision your infrastructure with the help of a declarative language. With this approach, you can gain consistency, repeatability, and enhanced reliability. 
In addition to day one infrastructure setup, this approach also helps with the management of any changes that happen to your infrastructure along the way, commonly referred to as drift management. (If you’re interested in how to manage Terraform workflows at scale, see: <a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">How to Manage Terraform at Scale</a>)
Other common <a href="https://spacelift.io/blog/infrastructure-as-code-tools" target="_blank" rel="noopener">IaC tools </a>include Cloud Formation Templates (CFT) for AWS, Azure Resource Manager (ARM) templates for Microsoft Azure, and Deployment Manager for Google cloud.

At a high level, Terraform can be thought of as consisting of two main parts: Terraform Core and Plugins. Core is responsible for life cycle management of infrastructure. It is the open-source binary that you download and use from the command line. 
Terraform Core takes into consideration the current state and evaluates it against your desired configuration. It then proposes a plan to add or remove infrastructure components as needed. Next, it takes care of provisioning or decommissioning any resources if you choose to apply the plan.
Terraform Plugins provide a mechanism for Terraform Core to communicate with your infrastructure host or SaaS providers. Terraform Providers and Provisioners are examples of plugins as mentioned above. Terraform Core communicates with the plugins via Remote Procedure Call (RPC).

terraform-definition

terraform definition

A typical Terraform workflow will consist of the following steps:
<h3>Step 1. Write </h3>
Declare your infrastructure resources as code in Hashicorp Configuration Language (HCL). 
<h3>Step 2. Review the Plan</h3>
Terraform will display a plan to add or remove resources based on the comparison of your declared infrastructure and the current state of any existing resources.
<h3>Step 3. Apply</h3>
Accept the planned changes to add or remove any infrastructure resources. This workflow works well for a single author as Terraform State is stored locally. As more contributors join the team, it becomes important to ensure everyone has a correct view of the current infrastructure state and changes are applied sequentially without overlaps. 
Terraform offers Enterprise and Cloud versions for teams to work together. These store the state remotely so everyone can have a consistent view. <a href="https://spacelift.io/blog/what-is-terraform-cloud" target="_blank" rel="noopener">Terraform Cloud</a> is available as a hosted service, whereas Terraform Enterprise enables you to deploy and self-host the Terraform Cloud in your private instance. Authors contribute their code to a central version control system (e.g. Github) and Terraform Cloud uses the latest code versions from the central repository.

<h3>Terraform CLI</h3>
Terraform is an <a href="https://github.com/hashicorp/terraform" target="_blank" rel="nofollow noopener">open-source</a> tool that compiles to a single binary file that can be downloaded on your system and used interactively from the command prompt. The latest version of Terraform can be downloaded <a href="https://www.terraform.io/downloads.html" target="_blank" rel="nofollow noopener">here</a>. A list of available Terraform commands can be retrieved from the command line

<ul>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;5 Ways to Manage Terraform at Scale – Best Practices&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">5 Ways to Manage Terraform at Scale – Best Practices</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>
<li><a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Deploy your Infrastructure in CI/CD using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Deploy your Infrastructure in CI/CD using Terraform</a></li>
</ul>

<h3>Terraform Language</h3>
Infrastructure is defined in the <a href="https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmware-nsx-t-data-center-and-terraform.pdf" target="_blank" rel="noopener">Hashicorp Configuration Language (HCL)</a> when working with Terraform. HCL is a declarative language targeted towards <a href="https://spacelift.io/blog/devops-tools" target="_blank" rel="noopener">DevOps tools</a> and servers. It provides a nice balance between machine-readable formats such as JSON and configuration formats included in high-level languages such as Ruby. 
Infrastructure components managed by Terraform are called Resources. Examples of resources include virtual machines, database tables, AWS S3 buckets, VPCs, and more. Each resource block in HCL helps define the resource and configure its properties. An example VPC resource looks like this:

<h3>Terraform Providers</h3>
Terraform needs to connect to your infrastructure host to effectively manage your infrastructure. Infrastructure hosts generally have a published API that facilitates operations to create, update and delete infrastructure elements. <a href="https://spacelift.io/blog/terraform-providers" target="_blank" rel="noopener">Terraform Providers</a> supply an abstraction to these APIs. 
Terraform configuration must include providers for it to connect with required cloud or SaaS services. Providers are published by infrastructure hosts and made available to Terraform as plugins. The plugin-based architecture allows publishers to independently publish and maintain their providers. The <a href="https://registry.terraform.io/browse/providers" target="_blank" rel="nofollow noopener">Terraform registry</a> is the main directory of publicly available providers (you can also find the <a href="https://registry.terraform.io/providers/spacelift-io/spacelift/latest/docs" target="_blank" rel="nofollow noopener">Spacelift Terraform Provider</a> in this registry).
Here is an example of configuring AWS Terraform Provider in HCL:

<h3>Terraform Provisioners</h3>
<a href="https://spacelift.io/blog/terraform-provisioners" target="_blank" rel="noopener">Provisioners</a> are another type of plugin available to use with Terraform as a means of configuring the infrastructure and making it ready for service. For example, you might need to copy certain files to your virtual machine necessary for your application to function, or you might need to run configuration management software (e.g. Chef or Puppet, etc.) that you normally use to configure your environment. 
Provisioners add complexity to overall usage of Terraform. Their behavior cannot be easily modeled with Terraform for planning as they can take a wide range of actions and might access your critical infrastructure services with high privileges. Hashicorp recommends using Provisioners as a last resort for your needs, only after searching for options available with other Terraform constructs.

<h3>Terraform Modules</h3>
Modules provide a way to package resources that provide relevant functionality together as a group. Each Terraform configuration has at least one module called the root module and can call other modules referred to as child modules. 
It is easy to write modules and share them with your team or others. The <a href="https://registry.terraform.io/browse/modules" target="_blank" rel="nofollow noopener">Terraform registry</a> hosts a large collection of Terraform modules for commonly used configuration scenarios. Terraform can automatically download these modules if you include them in your configuration.

<h3>Terraform State</h3>
Terraform stores a representation of your infrastructure objects, their interdependencies and bindings in a configuration file named terraform.tfstate. Storing the state information helps Terraform immensely in making planning and execution decisions. State can be stored locally as well as remotely in a team environment.
<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Read more about the elements of Terraform architecture.&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Read more about the <a href="https://spacelift.io/blog/terraform-architecture" target="_blank" rel="noopener">elements of Terraform architecture</a>.

Let’s take a look at some common scenarios where Terraform can be used:
<h3>Example 1. Rapidly Build and Dispose Environments</h3>
It is common practice to have multiple environments in a typical IT organization such as Development, Testing, Staging, and Production. Terraform allows us to save all the infrastructure resources and their interdependencies specific to an environment as code in Hashicorp Configuration Language (HCL). We can use this code to quickly create a new environment as needed. 
For example, when we need to test a new feature and want to make sure our Testing environment is an exact copy of Production, we can quickly create a Test environment with the help of code that is used to create the Production, ensuring our changes will run smoothly when moved to Production after testing. 
Similarly, when developing a new feature we might need to create a new development environment for a short period of time. We can easily create and tear down one with the help of Terraform automation. The same concept applies to building recovery environments in case a disaster strikes and makes the Production unavailable.
<h3>Example 2. Use Multiple Clouds</h3>
Using more than one public cloud provider can be very beneficial if we want to have some fault tolerance for our application. In case cloud services for a particular region fail for a cloud provider, the application can continue to work if it is configured to use multiple cloud providers. It is also common to keep some resources on-prem and use a hybrid environment, combining private and public cloud resources. 
Terraform is cloud-agnostic. It can deploy applications across multiple clouds quickly and consistently. With Terraform, we don’t have to worry about using deployment tools specific to cloud providers. Instead, we can have a uniform experience working with different clouds.
<h3>Example 3. Deploy N-Tier Applications</h3>
N-Tier applications provide separation of concerns by having different tiers targeted to specific purposes. For example, a typical web application will have a tier dedicated to databases, and another tier for web servers. The web servers will depend on databases to function properly and will be behind a load balancer that will distribute requests among these web servers. 
Terraform can help ensure dependencies in this environment are implemented correctly, as databases will have to be deployed and be available before web servers. It is also easy to scale multi-tiered applications by adding more resources to a specific tier. 
For example, if you feel your application can be more robust with the help of an additional database server, it can be a matter of a simple configuration change and deployment with Terraform to add another server to the database tier.
<h3>Example 4. Work with Popular PaaS tools</h3>
Infrastructure provisioning is an important part of application deployment. However, it is not the only one required for successful deployment of applications. Modern applications use several tools to accomplish critical functions such as scheduling of resources, caching and routing, etc. Kubernetes is a popular orchestration platform used to productively deploy containers across multiple hardware resources. 
Terraform Providers not only work as abstractions for infrastructure hosts, but they can essentially interact with any API based platform such as Kubernetes. This allows us to use Terraform as a single tool to deploy infrastructure and then configure any required platforms like Kubernetes.
&nbsp;

Terraform solves several important infrastructure problems and naturally has some overlapping features with other infrastructure tools. Let’s take a look at some frequently asked questions about other tools in relation to Terraform
<ul>
<li style="font-weight: 400;" aria-level="1">
<h3>What is OpenTofu, and should I use it instead of Terraform?</h3>
<a href="http://opentofu.org/" target="_blank" rel="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 Terraform, being forked from Terraform version 1.5.6, created as a community-driven initiative supported by many of the most recognized companies and projects in the Terraform ecosystem in response to Hashicorp’s BSL license change.
OpenTofu is the future of the Terraform ecosystem and having a truly open-source project to support all your IaC needs is the main priority.
Key advantages of using OpenTofu instead of Terraform:
<ul>
<li style="font-weight: 400;" aria-level="1">Open-source nature: There are no restrictions on how you can use OpenTofu, either for commercial or personal use. The open-source nature of OpenTofu embodies the principles of openness and collaboration that characterize the tech community.</li>
<li style="font-weight: 400;" aria-level="1">Dynamic community: Developer contributions will make the project more robust and adaptable to different use cases. Bugs and issues will be identified and resolved quickly to ensure reliability and stability.</li>
<li style="font-weight: 400;" aria-level="1">Fast, reliable support: The growing community behind OpenTofu not only gives everyone the opportunity to influence the development of new features, but it also supplies the resources to ensure these features and bug fixes will be introduced rapidly.</li>
<li style="font-weight: 400;" aria-level="1">Minimal risk: OpenTofu is published under MPL and is a part of the Linux Foundation (with the goal of joining CNCF), which provides the guarantee the tool remains truly open-source, forever.</li>
</ul>
</li>
<li style="font-weight: 400;" aria-level="1">
<h3>Should I use Terraform or other popular configuration management tools like Chef or Puppet?</h3>
There is a basic difference between Terraform and configuration management tools. Terraform focuses on making it easy to provision and manage your infrastructure, whereas configuration management software is used to prepare the VMs and Servers to fit your application and environment needs after provisioning. Furthermore, Terraform can be used in conjunction with configuration management tools as they address separate concerns.</li>
<li style="font-weight: 400;" aria-level="1">
<h3>What about cloud specific tools like Cloud Formation and ARM Templates?</h3>
While cloud specific tools can be excellent at managing resources for a particular cloud provider, Terraform strives to be cloud agnostic. It allows you to use the same language to define your resources across different clouds and makes it easy to work with multi-cloud and hybrid cloud scenarios. 
</li>
<li style="font-weight: 400;" aria-level="1">
<h3>What about common orchestration tools such as Kubernetes?</h3>
</li>
</ul>
Similarly to configuration management tools, <a href="https://spacelift.io/blog/container-orchestration-tools" target="_blank" rel="noopener">container orchestration platforms</a> focus on a separate concern and can be easily used in collaboration with Terraform. They usually have a robust API that helps develop Terraform Providers that in turn can be used effectively with Terraform Core, for example. <a href="https://registry.terraform.io/providers/hashicorp/kubernetes/latest" target="_blank" rel="nofollow noopener">Kubernetes Terraform Provider</a> can be found in the Terraform Provider registry. 
<ul>
<li>
<h3>Why use Terraform instead of our home grown scripts?</h3>
There are several reasons for moving away from custom ad-hoc scripts. A common issue encountered is their limitation to scale and adapt to new infrastructure needs. A custom script typically addresses a specific environment and needs updating and refactoring as new applications and infrastructure are added to the IT organization. This creates an overhead in terms of time, effort, and budget to achieving business-critical goals.</li>
</ul>

In this post, we have briefly discussed the main features and use cases of Terraform that will help you get started. We encourage you also to explore <a href="https://docs.spacelift.io/" target="_blank" rel="noopener">how Spacelift makes it easy to work with Terraform</a>. Have questions? Drop us a line in the comments below.

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.

Whenever you're embarking on a new journey or seeking to refine your foundational knowledge.

How Spacelift Can Improve Your Infrastructure as Code

What is Terraform? What is Terraform used for? This guide has all the answers plus Terraform definition.

How to Rename an AWS S3 Bucket in Terraform – Step by Step

Get the newsletter

Recent posts

How to Rename an AWS S3 Bucket in Terraform – Step by Step

Alternative to Atlantis – Spacelift

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