Managing Terraform at scale | Spacelift Blog

The introduction of Infrastructure as Code or IaC has transformed the way you can provision and deploy high-performance cloud-based IT infrastructures.
IaC tools, such as Terraform, have been integrated into DevOps toolchains, saving DevOps IaC teams from the excessive manual effort.
While these tools undoubtedly help accelerate building IT infrastructures, their limitations can impact DevOps’ ability to optimize and improve control of their IaC processes supporting future business needs.
In this article, you’ll learn about IT infrastructure limitations that IaC DevOps teams deal with on a daily basis and how Spacelift is able to get past them.

One of the most frequent challenges while using more generic IaC tools is the non-intuitive workflow driven by its reliance on pull requests. Some solutions offer multiple workspaces, but the result can be fragile and nondeterministic. 
Since there’s no concept of mapping projects to branches or tags, anyone commenting 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. It is mostly driven by push and tag events, so building a sophisticated Git flow is much easier. Spacelift reports the outcome of its jobs as commit status checks, allowing you to block merging the code on a failing Spacelift check.
Triggering a run can be customized using <a href="https://docs.spacelift.io/concepts/policy/git-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 mono repo with hundreds of interdependent projects. You can read more about our approach to VCS integration <a href="https://docs.spacelift.io/integrations/github#tracked-branches" target="_blank" rel="noopener">here</a>.

The majority of generic tools don’t offer access control models but rely on comments on pull requests to drive infrastructure deployments. While it is usually fine when a single repository drives a single Terraform project, it 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 what their <a href="https://docs.spacelift.io/concepts/policy/stack-access-policy" target="_blank" rel="noopener">level of access</a> to each of the managed projects should be. Even our <a href="https://docs.spacelift.io/integrations/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/slack#managing-access-to-stacks-with-policies" target="_blank" rel="noopener">based on Slack-specific data</a> (think team, channel, user, etc.).

One thing that’s not in scope for most IaC solutions is the way to ensure that your infrastructure is compliant with industry best practices and your company policies.
Spacelift 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> on top of <a href="https://www.openpolicyagent.org/" target="_blank" rel="nofollow noopener">Open Policy Agent</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 the <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/git-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>.

Handling interdependencies between projects has always been Terraform’s Achilles’ heel. 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>. But it’s only a partial solution as it breaks the problem into smaller chunks.
<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. They 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. Read more <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">here</a> to discover other exciting possibilities.

Another problem to solve externally when using some of the generic tools is authoring and maintaining reusable <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform modules</a> 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 much more. Far from being just a glorified package manager, Spacelift adds a <a href="https://docs.spacelift.io/concepts/modules" 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, it’s likely that you just set your IaC 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 Terraform workspaces. The need to configure it each and every time become 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—you can add Terraform and/or <a href="https://docs.spacelift.io/concepts/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 users of generic CI tools, Spacelift entities such as stacks, contexts, modules or policies can be managed in a declarative way using your favorite infra-as-code tool (this rule applies also to their configuration). Yes, that’s right—<a href="https://docs.spacelift.io/integrations/terraform-provider" target="_blank" rel="noopener">Spacelift offers a Terraform provider</a> that allows you to programmatically manage the lifecycle of its own resources.
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.

Generic IaC platforms do not provide any mechanisms to detect if your infrastructure is undergoing drift. Drift is a condition that represents the difference between the desired and the actual state of the infrastructure managed by your tool of choice &#8211; <a href="https://www.terraform.io/" target="_blank" rel="nofollow noopener">Terraform</a>, <a href="https://www.pulumi.com/" target="_blank" rel="nofollow noopener">Pulumi</a>, <a href="https://aws.amazon.com/cloudformation/" target="_blank" rel="nofollow noopener">CloudFormation</a> or another. Drift can be caused by either or a combination of changes directly introduced by external actors &#8211; either humans or machines (scripts) or via the dependency of your resources on external data sources. In any case, drift is not good.
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 notify you whenever drift happens, and take immediate action. You can even go a step further 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.

General-purpose CI/CD platforms provide little to no insight into resource utilization from either a real-time or historical perspective. Which resources are over-or underutilized? 
Developers need to be able to intimately understand the material they’re working with. With regards to infra-as-code, the most important part of this story is understanding the managed resources in-depth. Both from the current perspective and through being able to put each resource in its historical context.
The resources view in Spacelift gives you greater visibility into each and every resource. With this deep insight into resources, DevOps are able to gain an understanding of the lifecycle of each resource managed by Spacelift and document it, regardless of the technology used — <a href="https://www.terraform.io/" target="_blank" rel="nofollow noopener">Terraform</a>, <a href="https://github.com/gruntwork-io/terragrunt" target="_blank" rel="nofollow noopener">Terragrunt</a>, <a href="https://www.pulumi.com/" target="_blank" rel="nofollow noopener">Pulumi</a>, or <a href="https://aws.amazon.com/cloudformation/" target="_blank" rel="nofollow noopener">CloudFormation</a>.

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

Spacelift is an innovative and sophisticated SaaS product for Infrastructure as Code which helps IaC DevOps develop and deploy new infrastructures or changes quickly and with confidence.
Spacelift offers a unique set of IaC management capabilities:
<ol>
<li style="font-weight: 400;" aria-level="1">an 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">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 work 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> </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/concepts/modules" 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/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/integrations/terraform-provider" target="_blank" rel="noopener">programmatic configuration</a> using Terraform</li>
<li style="font-weight: 400;" 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"><a href="https://docs.spacelift.io/concepts/resources" target="_blank" rel="noopener">resource visualization</a></li>
</ol>
… and a multitude of additional perks like <a href="https://docs.spacelift.io/concepts/context" target="_blank" rel="noopener">contexts</a>, <a href="https://docs.spacelift.io/concepts/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>.

There are many ways of working with Terraform. Each way is different in terms of complexity and offers a different set of features. It is important to keep in mind that choosing one way or another should be based on business and technical requirements. Most often, there is no point in implementing an in-house solution as the cost and effort of building and maintaining it may exceed its potential benefits. It is much easier and more efficient to leverage platforms such as Spacelift to provide these features for you instead.

5 Ways to Manage Terraform at Scale

Terraform Functions, Expressions and Loops

Terraform vs. Ansible: Key Differences

Most often, there is no point in implementing an in-house solution as the cost and effort of building and maintaining it may exceed its potential benefits. It is much easier and more efficient to leverage ready-to-go platform to provide these features instead.

How a Specialized Management Solution Can Improve Your IaC

The native language of Terraform, called HCL, can be an extremely comfortable and efficient tool, if you know it well. Although it is not a programming language (even though operators coding in HCL are often jokingly called “HCL Developers”), it does implement some structures and logic, that bear resemblance to regular programming. In this article, we will discuss the core of HCL &#8211; built-in functions, expressions and loops. What are those, and what are they for? Let’s talk about that.

What are Terraform Functions? Functions are a mean of manipulating the data, and provide you with possibilities to combine, transform or operate in other way, on provided values. For example, a “join” function looks like this:

Its purpose is to create a string out of the elements from the given list, with the given separator as a delimiter. So, if you’ll declare it like this:

The resulting output will be:

As you can see, the base principle is pretty easy. Things can go in, different things can come out. 
Functions are used for many, many things &#8211; from simple type conversions (E.g. string to number), value combinations (Such as getting all list elements to a single string as above), selecting (E.g. select the biggest number from a list of numbers), corrections (Trimming suffixes, prefixes, capitalizing the letters of each list element), getting date and time, hashing values, advanced technical tasks such as calculating IP addresses… And much, much more.
The list of functions you can use, is pretty extensive &#8211; but it is also finite. Terraform does not allow you to create your own functions, so you’re bound to use what is provided by default.

Expressions are the core of HCL itself &#8211; the logic muscle of the entire language. They allow you to get a value from somewhere, calculate or evaluate it. You can use them to refer to the value of something, or extend the logic of a component &#8211; for example, make one copy of the resource for each value contained within a variable, using it as an argument.
They are used pretty much everywhere &#8211; the most simple type of expression would be a literal value &#8211; so, there is a great chance that you have already used them before.
As it is an extremely extensive topic, I couldn’t possibly fit everything into this single article. Instead, let me tell you about the most notable/interesting expressions in my humble opinion: Operators, Conditional expressions, Splat Expressions, Constraints, and Loops.
<h3>Operators</h3>
Dedicated to logical comparison and arithmetic operations, operators are mostly used for doing math and basic Bool’s algebra. The way to go, if you need to know, if number A does equal number B, add them together, or know if both boolean A and boolean B are “true”. The following operators are available in Terraform:
<ul>
<li style="font-weight: 400;" aria-level="1">Arithmetic operators &#8211; the basic ones for typical math operations (+, -, *, /) and two special ones: “X % Y” would return the remainder of dividing X by Y, and “-X” that would return X multiplied by -1. Those can only be used with numeric values.</li>
<li style="font-weight: 400;" aria-level="1">Equality operators &#8211; “X == Y” is true, if X and Y have both the same value and type, “X != Y” would return false in this case. Will work with any type of value.</li>
<li style="font-weight: 400;" aria-level="1">Comparison operators &#8211; “&lt;, &gt;, &lt;=, &gt;=” &#8211; exclusive to numbers, returns true or false depending on the condition. </li>
<li style="font-weight: 400;" aria-level="1">Logical operators &#8211; the Bool’s algebra part of the pack. They work only with the boolean values of true and false. 
 &#8211; “X || Y” returns true if either X or Y is true, false if any of them is false. 
 &#8211; “X &amp;&amp; Y” returns true only, if both X and Y are true, false if any of them is false. 
            &#8211; “!X” is true, if X is false, false if X is true.</li>
</ul>
<h3>Conditionals</h3>
Sometimes, you might run into a scenario, where you’d want the argument value to be different, depending on another value. The conditional syntax looks as shown below:

The condition part is constructed using previously described operators. In this example, the bucket_name value is based on the “test” variable &#8211; if it’s set to true, the bucket will be named “dev” and if it’s false, the bucket will be named “prod”:

<h3>Splat Expressions</h3>
Splat expressions are used to extract certain values from complicated collections &#8211; like grabbing a list of attributes from a list of objects containing those attributes. Usually you would need an “for” expression to do this, but humans are lazy beings, we like to do complicated things easier.
For example, if you had a list of objects like this:

Instead of using the entire “for” expression:

You could go for the splat expression form:

And in both cases, get the same result:

Do note, that this behavior applies only if splat was used on a list, set, or tuple. Anything else (Except null) will be transformed into a tuple, with a single element inside, null will just stay as it is. This may be good or bad, depending on your use case. I would suggest you read <a href="https://www.terraform.io/docs/language/expressions/splat.html#single-values-as-lists" target="_blank" rel="nofollow noopener">the official documentation</a> on the topic.
<h3>Constraints</h3>
In simple terms, constraints regulate what can be what, and where something can, or cannot be used. There are two main types of constraints &#8211; for types and versions.
<ul>
<li style="font-weight: 400;" aria-level="1">Type constraints regulate the values of variables and outputs. For example, a string is represented by anything enclosed in quotes, bool value is either a literal true or false, a list is always opened with square brackets [ ], a map is defined with curly brackets { }.</li>
<li style="font-weight: 400;" aria-level="1">Version constraints usually apply to modules and regulate which versions should or should not be used. We have already explained those in <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">the article about Terraform Modules</a> &#8211; make sure to check it out! </li>
</ul>

Ah yes, the elephant in the room. Mentioned a few times, but still unexplained until now.
Loops are used to handle collections, and to produce multiple instances of a resource or module without repeating the code. There are three loops provided by Terraform to date:
<h3>Count</h3>
Count is the most primitive one &#8211; it allows you to specify a whole number, and produces as many instances of something, as this number tells it to. For example, this would order Terraform to create ten S3 buckets:

When count is in use, each instance of a resource or module gets a separate index, representing its place in the order of creation. To get a value from a single resource created this way, you must refer to it by its index value, e.g. if you’d wish to see the ID of the fifth created S3 bucket, you would need to call it as such:

Although this is fine for identical, or almost identical objects, as previously mentioned, count is pretty primitive. When you need to use more distinct, complex values &#8211; count yields to for_each.
<h3>For_each</h3>
As mentioned earlier, sometimes you might want to create resources with distinct values associated with each one &#8211; such as names or parameters (For example, memory or disk size). For_each will let you do just that, just provide a variable &#8211; map, or a set of strings, and the resources can access values contained within, via each.key and each.value:

As you can see, for_each is pretty powerful, but you haven’t seen the best yet. By constructing a map of objects, you can leverage a resource or module to create multiple instances of itself, each with multiple declared variable values:

Using this approach, you don’t have to touch anything except the .tfvars file, to provide new instances of resources you have already declared in your configuration. Absolutely awesome. 
<h3>For</h3>
For is made for picking out, iterating over, and operating on things from complex collections. Imagine that you have a list of words (strings), but unfortunately, all of them contain newline characters at the end, which you don’t want to have. Like this:

To fix this problem, you could do:

Which would result in:

As you can see, list went in, list goes out &#8211; but, this is not a must. The type of input, and brackets wrapping the for expression around, decide about the type of output it does produce. If you’d wrap it with curly brackets, and provide a map as an input, the output would be a map. Quite interesting. But there’s one thing that’s even more interesting &#8211; for expression can also be used to filter the input, as you please. By adding an if clause, you can conditionally operate or not operate on certain values, depending on your defined terms. Take this example, making every word start with a capital letter… Except if the word is “teapot”:

For can do all that, and much, much more. Check out <a href="https://www.terraform.io/docs/language/expressions/for.html" target="_blank" rel="nofollow noopener">this </a><a href="https://www.terraform.io/docs/language/expressions/for.html" target="_blank" rel="nofollow noopener">page</a> of the official Terraform documentation, if you want to know more &#8211; it’s really powerful and can help you with many tasks ahead.

Regarding the joke I have mentioned earlier &#8211; as you can see from this piece of Terraform syntax pie, HCL is very, very extensive. It couldn’t compete with most programming languages, but when it comes to infrastructure, Terraform most usually has what you need. HCL is also simple to learn, but very intricate under the hood &#8211; to the point from which to consider it a tiny programming language indeed, wouldn’t be much of a stretch. I hope this little glimpse into the world of Terraform functions, expressions, and loops will help you to bring the awesome powers they provide into your configurations &#8211; have fun, and have a productive day.

Importing Existing Infrastructure into Terraform - step by step

Alternative to Atlantis - Spacelift

Terraform functions are a mean of manipulating the data, and provide you with possibilities to combine, transform or operate in other way, on provided values. Expressions are the core of HCL itself - the logic muscle of the entire language.

Terraform functions, expressions and loops

Both Terraform and Ansible are DevOps tools, but how do these DevOps tools differ? In short, Terraform is an open-source, Infrastructure as Code platform, while Ansible is an open-source configuration management tool focused on the configuration of that infrastructure.
It is often a topic of discussion about whether one should use Terraform or Ansible for infrastructure management. Fortunately, there is an answer that lies in the Grey area. This answer seems the same when asked to people who have working experience on both the tools.
This post highlights similarities between Terraform and Ansible, explores the differences and concludes with the best way to manage infrastructure.

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

The previous section gives an overview of the two tools in their broadest similarities. At a high level, it sounds like both Terraform and Ansible are capable of provisioning and configuration management. However, a deeper dive into them makes us realize the benefits of one over the other in certain areas.
In general, both the tools are great in their own ways. They have an overlap of functions when it comes to infrastructure management. Infrastructure management broadly encompasses 2 aspects &#8211; orchestration and configuration management. 
Terraform and Ansible have their own ways of managing both &#8211; with strong and weak points when it comes to overlaps. Thus, it is important to delve into some details of both the tools to make a “perfect” choice or a combination with boundaries.
<h3>Orchestration vs. Configuration Management</h3>
Orchestration/provisioning is a process where we create the infrastructure &#8211; virtual machines, network components, databases, etc. Whereas, on the other hand, configuration management is a process of automating versioned software component installation, OS configuration tasks, network and firewall configuration, etc.
Both Terraform and Ansible are capable of performing both tasks. However, Terraform offers a comprehensive solution to manage infrastructure. Terraform uses cloud provider APIs to provision and de-provision the infrastructure based on declared resources. 
Ansible on the other hand is also capable of provisioning the cloud infrastructure but it is not comprehensive enough. It is mainly geared towards configuration management. Configuration management is a process of keeping the applications and dependencies up to date. This is where Ansible really shines as compared to Terraform.
Both the tools can perform both kinds of activities. However, there are limitations when implementing configuration management using Terraform, and infrastructure automation using Ansible. They are not flexible enough when it comes to complex infrastructure management.
Logically, we can identify orchestration as Day 0 activity and configuration management as Day 1 activity. Terraform works best for Day 0 activities and Ansible for Day 1 and onwards activities.
<h3>Declarative vs. Procedural</h3>
Terraform is used to write infrastructure as code (IaC). It uses HCL (Hashicorp Configuration Language) which is declarative in nature. It doesn&#8217;t matter in which sequence the code is written. The code could also be dispersed in multiple files.
No matter how you write the code, Terraform identifies the dependencies, and provisions infrastructure. Writing or translating existing infrastructure to code is easy in Terraform. Check this <a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform">post</a> if you would like to know more about importing infrastructure under Terraform management.
Ansible uses YAML syntax to define the procedure to perform on the target infrastructure. Ansible YAML scripts are procedural in nature &#8211; meaning when you write the script, it will be executed from top to bottom.
Ansible scripts are called “ansible playbooks”. When you have to perform certain series of tasks, you define the same in the playbook. The tasks will be performed in the sequence they are written. For example, to install an Apache server on the given virtual machine as a root user, you would have to write the user creation step before defining the task for installation.
<h3>Mutable vs. Immutable</h3>
A configuration is mutable when it is possible to change it without rebooting or replacing the infrastructure. If not, the configuration is considered immutable.
In the case of Terraform, the line between mutability and immutability depends on a few factors. Terraform takes the desired state of infrastructure as input and provisions it. When a change is introduced, Terraform bases its decision on the nature of the change itself.
If it is not possible for the cloud provider to implement the change without rebooting or replacing the infrastructure, then Terraform mutates the infrastructure. It destroys the older infra component and replaces it with a new one with the latest configuration setting. This mutability also depends on various dependencies within the resources, e.g., network components.
Other changes which do not require replacement, Terraform does not replace the infrastructure. For example, changing the instance type on the AWS EC2 instance does not cause resources to be replaced. However, changing the AMI causes the resource to be replaced.
Ansible on the other hand is immutable by default. Ansible attempts to keep the configuration changes consistent as per the latest version of the playbook. Any changes introduced do not cause any “replacement” of the underlying infrastructure. It only repairs or modifies configuration on the given component.
Over time, servers managed by Ansible record the changes to the configuration they have undergone. This may cause other servers to have different configurations if not managed properly. This phenomenon is known as configuration drift.
By default, although capable, Terraform works with a mutable approach, and Ansible works with an immutable approach. Having said that, the two tools are also capable of both approaches with limits.
<h3>State Management</h3>
Terraform manages the entire lifecycle of the resources under its management. It maintains the mapping of infrastructure resources with current configuration in state files. State management plays a very important role in Terraform.
States are used to track changes to the configuration and provision the same. It is also possible to import existing resources under Terraform management by importing the real-world infrastructure in state files. 
At any given time, it is possible to query the Terraform state files to understand the infrastructure component and their attributes currently available.
As opposed to this, Ansible does not support any lifecycle management. Since Ansible mainly deals with configuration management and considering it defaults to immutable infrastructure, any changes introduced in the configuration are executed automatically on the target resource.

As we have known till now, Terraform works best with orchestration and Ansible is great at configuration management. 
Of course, they have the capabilities to perform each other’s tasks, although in a limited manner. In such a situation, instead of making a firm choice, it is better to leverage both tools for infrastructure management, based on their respective strengths.
The answer to the question “which tool to use?” is &#8211; it depends. It depends on how the infrastructure management process is currently shaped. It is important to find the right balance of orchestration and configuration management to assign clear responsibilities to the respective tools.
If you are looking to manage infrastructure as code, <a href="https://spacelift.io/product" target="_blank" rel="noopener">Spacelift</a> is the way to go. It supports Git workflows, policy as code, programmatic configuration, context sharing, and many more great features. It currently works with Terraform and Pulumi, with support for Ansible and CloudFormation on the way!

What Are Terraform Modules and How to Use Them

Both Terraform and Ansible are DevOps tools, but how do these DevOps tools differ? In short, Terraform is an open-source, Infrastructure as Code platform, while Ansible is an open-source configuration management tool.

In this article, I want to give an overview of Open Policy Agent, why you would want to use it, as well as showcasing how you can use OPA with your Spacelift account. Although OPA can be used for many purposes, I&#8217;m going to focus on how it can be used alongside Infrastructure as Code.

Open Policy Agent provides a way of declaratively writing policies as code and then using those policies as part of a decision-making process. It uses a policy language called Rego, allowing you to write policies for various different services using the same language.
OPA can be used for a number of purposes, including:
<ul>
<li style="font-weight: 400;" aria-level="1">Authorization of REST API endpoints.</li>
<li style="font-weight: 400;" aria-level="1">Allowing or denying Terraform changes based on compliance or safety rules.</li>
<li style="font-weight: 400;" aria-level="1">Integrating custom authorization logic into applications.</li>
<li style="font-weight: 400;" aria-level="1">Implementing Kubernetes Admission Controllers to validate API requests.</li>
</ul>
OPA was originally created by<a href="https://www.styra.com/" target="_blank" rel="noopener"> Styra</a>, and is now a part of the Cloud Native Computing Foundation (CNCF), alongside other CNCF technologies like Kubernetes and Prometheus.

We can visualise how OPA works using the following diagram:

how-does-opa-work

how does opa work

As you can see, OPA accepts a policy, input and query, and generates a response based on that. The input can be any valid JSON document, allowing OPA to integrate with any tool that produces JSON output.

In the following sections, I&#8217;ll go into more specific examples of using OPA that should help make things clearer, but before I do here&#8217;s a quick list of reasons that I&#8217;m interested in using OPA:
<ul>
<li>Policies as code allow you to follow your standard development lifecycle with PRs, CI, etc, and provide you with a history of changes to your policies.</li>
<li>OPA is designed to work with any kind of JSON input, meaning it can easily integrate with any tool that produces JSON output.</li>
<li>Because OPA integrates with a number of different tools, it allows you to use a standard policy language across many parts of your system, rather than relying on multiple vendor-specific technologies.</li>
<li>OPA supports unit-testing, making it easier and faster to iterate your policies with confidence that they won&#8217;t break.</li>
</ul>

Let&#8217;s try to make that a bit less theoretical by using a specific example: Terraform. Terraform can produce a plan in JSON format via the terraform show command. This means that we can  define policies for our infrastructure, and use OPA to make a decision about whether a plan is safe to apply or not:

using-opa-with-terraform

using opa with terraform

For example, say we have the following terraform definition to create an EC2 instance:

Now say we want to ensure that every Terraform resource has a Name tag, we could enforce that by creating a file called plan.rego with the following content:

In order to use OPA to evaluate our policy, we need to take the following steps:
<ol>
<li>Generate a Terraform plan as JSON.</li>
<li>Run opa eval to verify whether that plan passes our policy or not.</li>
</ol>

<h3>Step 1 &#8211; Generate our Terraform plan as JSON</h3>
To get a JSON representation of our plan, we need to output our plan to a file, and then use the terraform show command to output that plan as JSON:

<h3>Step 2 &#8211; Run opa eval</h3>
We can then use opa eval to evaluate our plan against our policy:

As you can see, we&#8217;re using the query data.spacelift.allow because our policy is loaded as a data file, and we defined our allow rule in the spacelift namespace. You can also see that opa eval produced empty output ({}). This means that our allow rule didn&#8217;t evaluate to true, and so produced no output.
Let&#8217;s adjust our terraform definition to include a Name tag:

Now if we generate our plan and evaluate the policy again, we should get a slightly different output:

This tells us that the allow rule has evaluated true. We can get that in a slightly more concise way using the pretty format option:

At this stage, you can probably imagine how you could integrate this into your CI/CD pipeline to enforce naming schemes, security rules, and various other organizational policies.

The following examples illustrate some possible use-cases for OPA with Terraform. All of the examples have been taken from the Spacelift <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy#cookbook" target="_blank" rel="noopener">plan policy documentation</a>, but have been altered to work with plain vanilla Terraform.
<h3>Example 1. Require human review when resources are deleted or updated</h3>
Adding new resources is usually a fairly safe operation, but updating or deleting existing resources can carry more risk. You could flag these for human review using the following policy:

<h3>Example 2. Require commits to be reasonably sized</h3>
Once a PR goes over a certain size it becomes difficult to review without missing things. The same is true for Terraform plans. The following policy can be used to warn when the number of changes goes over a certain threshold:

<h3>Example 3. Blast radius</h3>
The following policy attempts to determine the risk of a particular plan by assigning different weightings to the change type (create, update, delete), along with the affected resource type (ECS cluster, EC2 instance, etc). It takes the approach that an update or delete is more risky than a create because it affects an existing resource:

How can we make sure that our policies work as we expect and that they don&#8217;t break over time as we make changes to them? You guessed it: unit testing! Luckily for us, OPA has first-class support for testing via the opa <code>test</code> command.
To create tests for our policy, all we need to do is create another Rego file with a series of rules prefixed with <code>test_</code>. Each rule starting with that prefix defines a separate test. 
Let&#8217;s go ahead and create a file called plan_test.rego, with the following contents:

As you can see, OPA makes it really easy to specify the policy input using the <code>&lt;variable&gt;</code> as <code>&lt;value&gt;</code> syntax. This allows us to create very concise tests by only including values we care about in the policy input, rather than having to use the entire plan output.
Let&#8217;s go ahead and run <code>opa test</code>:

Unsurprisingly our test passes. That&#8217;s not very exciting, so let&#8217;s add a new test to ensure our resources include an <code>Environment</code> tag:

Running opa test again shows us a failure:

Which we can fix by updating our policy:

At this stage if you run the test command again it should show 2 passes:

If you want to know more about OPA testing, the <a href="https://www.openpolicyagent.org/docs/latest/policy-testing/" target="_blank" rel="nofollow noopener">official docs</a> are full of great examples and information about what you can do.

At this stage, hopefully, you&#8217;ve got a pretty good idea of what OPA is as well as how it can be useful to you. It&#8217;s not too difficult to see how you could start integrating OPA into your development process or even use it as part of production systems.
Luckily for you, at Spacelift we&#8217;ve done all the heavy lifting for you, allowing you to get the benefits of using OPA for Policy-as-Code without having to implement everything from scratch for yourself. In this section, I want to showcase some of the functionality that Spacelift provides that relates to OPA.
<h3>1) Policy Types</h3>
Spacelift allows you to use OPA policies to manage various aspects of your Spacelift account,
not just during planning. For example, you can use policies to control who can login to your account, along with what they have access to. For more information see <a href="https://docs.spacelift.io/concepts/policy" target="_blank" rel="noopener">https://docs.spacelift.io/concepts/policy</a>.
<h3>2) PR Checks</h3>
Spacelift can automatically trigger planning runs whenever you push changes to your VCS provider. For example, here&#8217;s what you might see in GitHub after creating a PR:

pr-checks-1

Opa pr checks

If all goes well your check will succeed, but if a policy is violated, a failed check will be reported:

pr-checks-2

opa pr checks

You can then view the details of the failure in Spacelift:

pr-checks-3

<h3>3) Manual Approvals</h3>
Spacelift <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">plan policies</a> use a slightly different format than we used in our example policies earlier in this post. Not only do they allow you to specify a message to be displayed, but they also have the concept of <code>deny</code> and <code>warn</code>:

The <code>deny</code> rule fails the run completely, while the <code>warn</code> rule just displays a warning in the logs.
warn rules take on another role when a run is going to deploy changes (vs just showing the planned changes against a PR). If any warnings are reported during a deployment, the run will wait for manual approval before applying any changes.
Let&#8217;s use the following example policy, designed to warn if a certain set of suggested tags aren&#8217;t found on our resources:

If we then attempt to add resources that don&#8217;t contain all of those tags, Spacelift will block before applying the changes, and give us the chance to manually approve or deny the run:
&nbsp;

manual-approvals

manual approvals

This allows you to build complex workflows where certain changes are completely blocked, but others are allowed as long as the changes are reviewed first.
Check out our <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy#cookbook" target="_blank" rel="noopener">plan policy cookbook</a> for more ideas about what you can do.

Spacelift provides a <a href="https://registry.terraform.io/providers/spacelift-io/spacelift/latest/docs" target="_blank" rel="nofollow noopener">Terraform provider</a> for managing your Spacelift account. This means that you can manage the policies available within your account, along with the Stacks they apply to in code.
For example, to add the policy we defined earlier to Spacelift we can use the <code>spacelift_policy</code> resource like this:

We can then attach this policy to a Spacelift Stack using the <code>spacelift_policy_attachment</code> resource:

Taking this a step further, we could create a custom module for defining Spacelift Stacks that ensured that all Stacks had a certain set of policies attached by default.

I hope you&#8217;ve enjoyed this post, and can see the value that OPA brings to the table. If you&#8217;re interested in trying out Spacelift to see what we have to offer, why not sign up for a <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">free trial</a>? You can setup a Spacelift account in minutes, and get started on your Open Policy Agent journey!

How a Specialized Management Platform Can Improve Your IaC

Open Policy Agent provides a way of declaratively writing policies as code, and then using those policies as part of a decision making process. It uses a policy language called Rego, allowing you to write policies for various different services using the same language.

What is Open Policy Agent (OPA) and how it works

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://www.terraform.io/docs/cloud/index.html" target="_blank" rel="nofollow 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.
Spacelift embraces all those characteristics of Atlantis but offers them in as 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 work 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/concepts/modules" 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/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/integrations/terraform-provider" target="_blank" rel="noopener">programmatic configuration</a> using Terraform;</li>
<li style="font-weight: 400;" aria-level="1">… and a myriad of creature comforts like <a href="https://docs.spacelift.io/concepts/context" target="_blank" rel="noopener">contexts</a>, <a href="https://docs.spacelift.io/concepts/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/git-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/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/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/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/git-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.

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/concepts/modules" 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 Terraform workspaces, 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/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/integrations/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/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/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/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.

How does Open Policy Agent (OPA) work

The top alternatives to Atlantis include Spacelift, Heroku, Red Hat OpenShift, Hasura. Spacelift embraces all the characteristics of Atlantis but offers them in as a modern and sophisticated SaaS product

Spacelift Blog

Categories

How a Specialized Management Platform Can Improve Your IaC

Terraform Functions, Expressions and Loops

Terraform vs. Ansible: Key Differences

Read also

How does Open Policy Agent (OPA) work

Alternative to Atlantis – Spacelift