Ioannis is a DevOps &amp; Site Reliability Engineer interested in Cloud Infrastructure, Automation, CI/CD Pipelines &amp; Containerization.

All posts by Ioannis Moustakis - Infrastructure as Code Expert

Ioannis Moustakis

Author title

Title category

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

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

Managing Infrastructure at Scale | Spacelift Blog

applepodcasts

spotify

missionctrl

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

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

In this article, we explore best practices for managing Infrastructure as Code (IaC) with Terraform. Terraform is one of the most used tools in the <a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">IaC</a> space that enables us to safely and predictably apply changes to our infrastructure. 
Starting with Terraform can feel like an intimidating task at first, but a beginner can quickly reach a basic understanding of the tool. After the initial learning period, a new user can then start running commands, creating, and refactoring Terraform code. During this process, many new users face nuances and issues around how to structure their code correctly, use advanced features, apply software development best practices in their IaC process, etc. 
Let’s check together some best practices that will assist you in pushing your Terraform skills to the next level. If you are entirely new to Terraform, look at the <a href="https://spacelift.io/blog/terraform" target="_blank" rel="noopener">Terraform Spacelift Blog</a>, where you can find a plethora of material, tutorials, and examples to boost your skills.

In this section, we will describe some key Terraform concepts briefly. If you are already familiar with these, you can skip this section.
<h3>Terraform Configuration Language</h3>
Terraform uses its own <a href="https://www.terraform.io/language" target="_blank" rel="noopener">configuration language</a> to declare infrastructure objects and their associations. The goal of this language is to be declarative and describe the system’s state that we want to reach.
<h3>Resources</h3>
Resources represent infrastructure objects and are one of the basic blocks of the Terraform language. 
<h3>Data Sources</h3>
<a href="https://spacelift.io/blog/terraform-data-sources-how-they-are-utilised" target="_blank" rel="noopener">Data sources</a> feed our Terraform configurations with external data or data defined by separate Terraform projects.
<h3>Modules</h3>
<a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Modules</a> help us group several resources and are the primary way to package resources in Terraform for reusability purposes. 
<h3>State</h3>
Terraform keeps the information about the state of our infrastructure to store track mappings to our live infrastructure and metadata, create plans and apply new changes. 
<h3>Providers</h3>
To interact with resources on cloud providers, Terraform uses some plugins named providers.

Before moving to Terraform, first, let&#8217;s check some fundamental best practices that apply to all Infrastructure as Code projects. These should be used in your processes regardless of your tool to manage your cloud infrastructure. 
<h3>1. Use version control and prevent manual changes</h3>
This seems like an obvious statement in 2022, but it’s the basis of everything else. We should treat our infrastructure configurations as application code and apply the same best practices for managing, testing, reviewing, and bringing it to production. We should embrace a <a href="https://www.weave.works/technologies/gitops/" target="_blank" rel="nofollow noopener">GitOps</a> approach that fits our use case and implement an automated CI/CD workflow for applying changes.
<h3>2. Shift your culture to Collaborative IaC</h3>
Keeping your infrastructure in version-controlled repositories is the first step to improving your manual infrastructure management. Next, we should strive to enable usage across teams with self-service infrastructure, apply policies and compliance according to our organization’s standards, and access relevant insights and information. Thankfully, <a href="http://spacelift.io/?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bterraform_best_practices%7D" target="_blank" rel="noopener">Spacelift</a> can assist you along the way to achieving these.

This section will explore some strategies for structuring our Terraform projects. In the world of Terraform, there is no right or wrong way to structure our configurations, and most of the suggested structures that you will find online are heavily opinionated.
When deciding how to set up your Terraform configuration, the most important thing is to understand your infrastructure needs and your use case and craft a solution that fits your team and the project.
If we are dealing with a small project with limited infrastructure components, it’s not a bad idea to keep our Terraform configuration as simple as possible. In these cases, we can configure only the necessary files for our root module, which are the configuration files that exist in the root directory. A small project can contain just these files main.tf, variables.tf, README.md. Some other files that you might find handy to use are the outputs.tf to define the output values of your project, versions.tf to gather any pinned versions for the configurations, and providers.tf to configure options related to the providers you use, especially if there are multiple. 
Our primary entry point is main.tf, and in simple use cases, we can add all our resources there. We define our <a href="https://spacelift.io/blog/how-to-use-terraform-variables" target="_blank" rel="noopener">variables</a> in variables.tf and assign values to them in terraform.tfvars. We use the file outputs.tf to declare <a href="https://spacelift.io/blog/terraform-output" target="_blank" rel="noopener">output values</a>. You can find a similar example project structure <a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/tree/master/terraform-best-practices/small-terraform-project-structure" target="_blank" rel="nofollow noopener">here</a>.

image2-21

smal Terraform project structure

When dealing with larger projects, things get a bit more complicated, and we have to take a step back to figure out the best structure for our projects. 
We first have to break down our Terraform code into reusable components that abstract details from consumers and different teams can use and customize accordingly. We can achieve this by creating separate modules for pieces of infrastructure that should be reused in different environments, projects, and teams. 
A common practice is to separate our modules according to ownership and responsibility, rate of change, and ease of management. For every module, we need to define its inputs and outputs and document them thoroughly to enable consumers to use them effectively. We can then leverage outputs and terraform_remote_state to reference values across modules or even different Terraform states. Beware that using the terraform_remote_state data source implies access to the entire state snapshot and this might post a security issue. Another option to share parameters between different states is to <a href="https://www.terraform.io/language/state/remote-state-data#alternative-ways-to-share-data-between-configurations" target="_blank" rel="nofollow noopener">leverage an external tool</a> for publishing and consuming the data like Amazon SSM Parameter Store or HashiCorp Consul.
We have to make the next decision to either keep all our Terraform code in a single repository (monorepo) or to separate our Terraform configurations in multiple code repositories. This is considered a <a href="https://www.hashicorp.com/blog/terraform-mono-repo-vs-multi-repo-the-great-debate" target="_blank" rel="nofollow noopener">great debate</a> since both approaches have drawbacks and benefits. There is a tendency in the industry to avoid gigantic monorepos and use separate configurations to enable faster module development and flexibility. Personally, this is the approach I prefer too.
Usually, we have to deal with a plethora of different Infrastructure environments, and there are multiple ways to handle this in Terraform. A good and easy practice to follow is to separate Terraform configurations for different environments. This way, different environments have their own state and can be tested and managed separately, while shared behavior is achieved with shared or remote modules. 
One option is using a separate directory per environment and keeping a separate state for each directory. Another option would be to keep all the Terraform configurations in the same directory and pass different environment variables per environment to parametrize the configuration accordingly. Check out the <a href="https://www.youtube.com/watch?v=wgzgVm7Sqlk" target="_blank" rel="nofollow noopener">Evolving Your Infrastructure with Terraform</a> and <a href="https://www.youtube.com/watch?v=Nr5Km_xGLVs" target="_blank" rel="nofollow noopener">How I Manage More Environments with Less Code in Terraform </a>talks for some inspiration around structuring your projects. 
<a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/tree/master/terraform-best-practices/separate-environments-project-structure" target="_blank" rel="nofollow noopener">Here</a>, you can find an example structure for three different environments per directory: production, staging, and test. Each environment has its own state and is managed separately from the others while leveraging common or shared modules.  Although this approach comes with some code duplication, we gain improved clarity, environment isolation, and scalability.

image1-21

Separate environments project structure

As a general rule, we want to define Terraform configurations with limited scope and blast radius with specific owners. To minimize risk, we should try to decompose our projects into small workspaces/stacks and segment access to them using Role-based access control(RBAC).

Alright, in the previous sections, we talked about some generic IaC best practices. We explored some options for optimizing our Terraform code according to our organizational structure and needs. 
In this part, we are deep-diving into specific points that will take our Terraform code to the next level. This list isn’t exhaustive, and some parts are opinionated based on my personal preferences and experiences. 
The goal here is to give you hints and guidance on experimenting, researching, and implementing the practices that make sense to your use case.
<h3>1. Remote state</h3>
It’s ok to use the local state when experimenting, but use a remote shared state location for anything above that point. Having a single remote backend for your state is considered one of the first best practices you should adopt when working in a team. Pick one that supports state locking to avoid multiple people changing the state simultaneously. Treat your state as immutable and avoid manual state changes at all costs. Make sure you have backups of your state that you can use in case of a disaster. For some backends, like AWS S3, you can enable versioning to allow for quick and easy state recovery.
<h3>2. Use existing shared and community modules</h3>
Instead of writing your own modules for everything and reinventing the wheel, check if there is already a module for your use case. This way, you can save time and harness the power of the Terraform community. If you feel like it, you can also help the community by improving them or reporting issues. You can check the <a href="https://registry.terraform.io/browse/modules" target="_blank" rel="nofollow noopener">Terraform Registry</a> for available modules. 
<h3>3. Import existing infrastructure</h3>
If you inherited a project that is a couple of years old, chances are that some parts of its infrastructure were created manually. Fear not, you can <a href="https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform" target="_blank" rel="noopener">import existing infrastructure into Terraform</a> and avoid managing infrastructure from multiple endpoints.  
<h3>4. Avoid variables hard-coding</h3>
It might be tempting to hardcode some values here and there but try to avoid this as much as possible. Take a moment to think if the value you are assigning directly would make more sense to be defined as a variable to facilitate changes in the future. Even more, check if you can get the value of an attribute via a data source instead of setting it explicitly. For example, instead of finding our AWS account id from the console and setting it in terraform.tfvars as

We can get it from a data source.

<h3>5. Always format and validate</h3>
In IaC, consistency is essential long-term, and Terraform provides us with some tools to help us in this quest. Remember to run terraform fmt and terraform validate to properly format your code and catch any issues that you missed. Ideally, this should be done auto-magically via a CI/CD pipeline or pre-commit hooks.
<h3>6. Use a consistent naming convention</h3>
You can find online many suggestions for naming conventions for your Terraform code. The most important thing isn’t the rules themselves but finding a convention that your team is comfortable with and trying collectively to be consistent with it. If you need some guidance, here’s a list of rules that are easy to follow:
<ul>
<li style="font-weight: 400;" aria-level="1">Use underscores(_) as a separator and lowercase letters in names. </li>
<li style="font-weight: 400;" aria-level="1">Try not to repeat the resource type in the resource name.</li>
<li style="font-weight: 400;" aria-level="1">For single-value variables and attributes, use singular nouns. For lists or maps, use plural nouns to show that it represents multiple values.</li>
<li style="font-weight: 400;" aria-level="1">Always use descriptive names for variables and outputs, and remember to include a description.</li>
</ul>
<h3>7. Tag your Resources</h3>
A robust and consistent tagging strategy will help you tremendously when issues arise or trying to figure out which part of your infrastructure exploded your cloud vendor’s bill. You can also craft some nifty access control policies based on tags when needed. Like when defining naming conventions, try to be consistent and always tag your resources accordingly.
The Terraform argument tags should be declared as the last argument(only depends_on or lifecycle arguments should be defined after tags if relevant). A handy option to help you with tagging is defining some default_tags that apply to all resources managed by a provider. Check out <a href="https://learn.hashicorp.com/tutorials/terraform/aws-default-tags" target="_blank" rel="nofollow noopener">this example</a> to see how to set and override default tags for the AWS provider. If the provider you use doesn’t support default tags, you must manually pass these tags through to your modules and apply them to your resources.
<h3>8. Introduce Policy as Code</h3>
As our teams and infrastructure scale, our trust in individual users is generally reduced. We should set up some policies to ensure our systems continue to be operational and secure. Having a Policy as Code process in place allows us to define the rules of what is considered secure and acceptable at scale and automatically verify these rules.  Spacelift leverages an open-source engine to achieve this, <a href="https://spacelift.io/blog/what-is-open-policy-agent-and-how-it-works" target="_blank" rel="noopener">Open Policy Agent(OPA)</a>. 
<h3>9. Implement a Secrets Management Strategy</h3>
Usually, users won’t admit that they have secrets in their Terraform code, but we have all been there. When you are starting with Terraform, it’s normal that secret management isn’t your top priority, but eventually, you will have to define a strategy for handling secrets. 
As you probably heard already, never store secrets in plaintext and commit them in your version control system. One technique that you can use is to pass secrets by setting environment variables with TF_VAR and marking your sensitive variables with sensitive = true.
A more mature solution would be to set up a secret store like Hashicorp Vault or AWS Secrets Manager to handle access to secrets for you. This way, you can protect your secrets at rest and enforce encryption without too much trouble. You can also opt for more advanced features like secret rotation and audit logs. Beware that this approach usually comes with the cost of using this managed service. 
<h3>10. Test your Terraform code</h3>
As with all other code, IaC code should be tested properly. There are different approaches here, and again, you should find one that makes sense for you. Running terraform plan is the easiest way to verify if your changes will work as expected quickly. Next, you can perform some static analysis for your Terraform code without the need to apply it. Unit testing is also an option to verify the normal operation of distinct parts of your system.
Another step would be to integrate a Terraform linter to your CI/CD pipelines and try to catch any possible errors related to Cloud Providers, deprecated syntax, enforce best practices, etc. One step ahead, you can set up some integration tests by spinning up a replica sandbox environment, applying your plan there, verifying that everything works as expected, collecting results, destroying the sandbox, and moving forward by applying it to production. 
There are a lot of tools out there that can help you with testing your Terraform code. I will list some of them in the “Helper Tools” section below.
<h3>11. Enable debug/troubleshooting</h3>
When issues arise, we have to be quick and effective in gathering all the necessary information to solve them. You might find it helpful to set the Terraform log level to debug in these cases.

Another thing that you might find helpful is to persist logs in a file by setting the TF_LOG_PATH environment variable. Check out this <a href="https://spacelift.io/blog/terraform-debug" target="_blank" rel="noopener">Terraform Debug &amp; Troubleshoot</a> tutorial for some hands-on examples.
<h3>12. Leverage Helper tools to make your life easier</h3>
Terraform is one of the most used and loved IaC tools out there, and naturally, there is a big community around it. Along with this community, many helper tools are being constantly created to help us through our Terraform journey. Picking up and adopting the right tools for our workflows isn’t always straightforward and usually involves an experimentation phase. Here you can find a list of tools that I find helpful based on my experience, but it is definitely not an exhaustive list. 
<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/terraform-linters/tflint" target="_blank" rel="nofollow noopener">tflint</a> &#8211; Terraform linter for errors that the plan can’t catch.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/tfutils/tfenv" target="_blank" rel="nofollow noopener">tfenv</a> &#8211; Terraform version manager</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/bridgecrewio/checkov/" target="_blank" rel="nofollow noopener">checkov</a> &#8211;  Terraform static analysis tool </li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/gruntwork-io/terratest/" target="_blank" rel="nofollow noopener">terratest</a> &#8211; Go library that helps you with automated tests for Terraform</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/antonbabenko/pre-commit-terraform" target="_blank" rel="nofollow noopener">pre-commit-terraform</a> &#8211; Pre-commit git hooks for automation </li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/terraform-docs/terraform-docs" target="_blank" rel="nofollow noopener">terraform-docs</a> &#8211; Quickly generate docs from modules</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bterraform_best_practices%7D" target="_blank" rel="noopener">spacelift</a> &#8211; Collaborative Infrastructure Delivery Platform</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/runatlantis/atlantis" target="_blank" rel="nofollow noopener">atlantis</a> &#8211; Workflow for collaborating on Terraform projects</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/antonbabenko/terraform-cost-estimation" target="_blank" rel="nofollow noopener">terraform-cost-estimation</a> &#8211; Free cost estimation service for your plans.</li>
</ul>
Check out also this list that includes a lot more <a href="https://github.com/shuaibiyy/awesome-terraform#tools)" target="_blank" rel="nofollow noopener">awesome terraform tools</a>.

We have explored many different best practices for Terraform and Infrastructure as Code, analyzed various options for handling and structuring our Terraform projects, and saw how adopting helper tools could make our life easier. 
Remember, this isn’t a recipe that you have to follow blindly but a guide that aims to provide pointers and cues and trigger you to build your own optimal Terraform workflows and projects.
Thank you for reading, and I hope you enjoyed this “Terraform Best Practices” article as much as I did.

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

How to Deploy your Infrastructure in CI/CD using Terraform

5 Ways to Manage Terraform at Scale - Best Practices

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

Learn some best practices that will assist you in pushing your Terraform skills to the next level. See how they can make your IaC management easier.

57-terraform_best_practices-2

terraform best practices

Terraform Best Practices for Better Infrastructure Management

This blog post will deep dive into how Terraform handles output and how we can leverage and use output values efficiently across our Terraform projects. Output values allow us to share data between modules and workspaces while also providing us the flexibility to pass values to external systems for automation purposes.
You have come to the right place if you are new to Terraform! Spacelift has curated a ton of valuable material, tutorials, and <a href="https://spacelift.io/blog/terraform" target="_blank" rel="noopener">blog posts around Terraform</a> and how industry experts use it on its Spacelift blog.

Input variables permit us to customize Terraform configurations without hardcoding any values. This way, we can reuse <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform modules</a> while assigning custom values based on our needs. Usually, we refer to them as just variables in the context of Terraform.
To define input variables, we must declare them using a variable block:

The variable&#8217;s name is the label we set following the variable keyword. For every variable, we have the option to set some arguments such as default, type, description, validation, sensitive, and nullable. Check the official documentation about these arguments and how to set them in detail <a href="https://www.terraform.io/language/values/variables#arguments" target="_blank" rel="nofollow noopener">here</a>. 
After declaring our input variables, we can utilize them in modules by referencing them like this var.&lt;variable_name&gt; where &lt;variable_name&gt; matches the label following the variable keyword. For example, to reference the variable ec2_instance_type that we defined above:

On the other hand, output values empower us to export helpful information from our Terraform projects that we have defined and provisioned with Terraform. In the context of Terraform, we refer to output values as just outputs for simplicity. 
Combining input and output variables, we get the flexibility to customize, automate, reuse and share our Terraform code easily. Input variables are similar to function arguments in traditional programming, while output variables work similarly to the return values of a function. Both are equally important to make our Terraform projects functional and facilitate data&#8217;s incoming and outgoing flow.

More specifically, output values are quite helpful in certain use cases:
<ul>
<li style="font-weight: 400;" aria-level="1">We can expose information from child modules to a parent module using outputs.</li>
<li style="font-weight: 400;" aria-level="1">Even more, from a root module, we can print outputs in the command line or pass these output values to external systems for automation purposes. </li>
</ul>
When we use a remote state, we can access the root module outputs by other configurations using the <a href="https://www.terraform.io/language/state/remote-state-data" target="_blank" rel="nofollow noopener">terraform_remote_state</a> data source. Output values from child modules aren&#8217;t accessible.

In order to define an output value, we have to use the output block:

In the above example, we define an output value with the name instance_public_ip. This way, we can pass the value to the parent module or display it to the end-user if it’s an output of the root module.
The value argument, which is the returned output value, takes an expression referencing other resources or module attributes. Terraform only renders and displays outputs when executing terraform apply and not when executing terraform plan. 
To use outputs of nested modules from parent modules, we have to reference them as: 
module.&lt;module_name&gt;.&lt;output_value_name&gt;
For example, to reference the output value instance_public_ip that we have declared above in a module named aws_web_server_instance from its parent module, we have to use:

Let’s examine how we can use all this in a real-world example. In <a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/tree/master/terraform-output" target="_blank" rel="nofollow noopener">this GitHub repository</a>, we define the Terraform configuration for this example’s infrastructure. To follow along, you will need to <a href="https://spacelift.io/blog/how-to-install-terraform" target="_blank" rel="noopener">install Terraform</a>, have an <a href="https://aws.amazon.com/console/" target="_blank" rel="nofollow noopener">AWS account</a> ready, and <a href="https://registry.terraform.io/providers/hashicorp/aws/latest/docs" target="_blank" rel="nofollow noopener">authenticate with your AWS keys</a> via the command line. Note that you might be charged a few dollars in your AWS account if you follow along.
In this example, we create the necessary infrastructure for a webserver. For the needs of this demo, we split our Terraform configuration into three modules, the root one and two child modules responsible for handling VPC-related resources and EC2 instance-related resources. 

The project structure looks like this:

image6-5

The project structure

For each module, we define a main.tf file that handles the main functionality of the module. 
Variable’s declarations and default values are populated in variables.tf files, while for the root module, we also use a terraform.tfvars file to set some variable values.
A good practice is to define our outputs in separate outputs.tf files, as you can see in the above example project structure. By declaring output values in an outputs.tf file per module, we improve the clarity of our modules as it’s easier for users to understand what outputs to expect from them quickly. 
The root module utilizes and configures the aws provider and then just simply calls two child modules aws_web_server_vpc and aws_web_server_instance in main.tf of the top directory. 
root module main.tf

We notice that when calling the module aws_web_server_instance, we are passing two expressions using output values from the aws_web_server_vpc module with the notation module.&lt;module_name&gt;.&lt;output_value_name&gt; we have seen earlier. 
root module outputs.tf

We define three output values for our root module, and we expect to see them at the command line after our infrastructure is provisioned. Checking the value parameter of each block, we notice that all of them are coming from output values of the two child modules, and by declaring them as output values of the root module, we are able to pass them through to the command line.
root module variables.tf

root module terraform.tfvars

Let’s examine next our two child modules and how we use output values to pass parameters between them.
aws-web-server-vpc module main.tf

In the above module, we define some resources necessary for the networking layer of our infrastructure.
aws-web-server-vpc module variables.tf

aws-web-server-vpc module outputs.tf

The two outputs we export here from this module are passed to the aws-web-server-instance module as parameters in order to create the EC2 instance inside the vpc and subnet that we have just created. We saw how this was handled in the main.tf file of the root module. The output value vpc_id is passed along as an output of the root module and should be printed in the command line after we apply the plan.
Finally, the Terraform configuration for the aws-web-server-instance module uses the passed info from the aws-web-server-vpc module. It creates and configures the web server instance accordingly.  
aws-web-server-instance module main.tf

aws-web-server-instance module variables.tf

The two output values that we pass through the root module are also defined in this module’s outputs.tf file.

Time to wrap up everything and execute the plan to provision our demo infrastructure.

image8-6

plan to provision the demo infrastructure

Our terraform plan shows 7 new resources to be added and displays the changes to our three output values declared in the root module. Let’s go ahead and apply the plan.

image3-13

Apply the plan

As expected, the three outputs declared in the root module are displayed at the command line, sweet! 
We could use these values to automate other parts of our systems and process, but for now, we can get the value from instance_public_ip and head to http://&lt;instance_public_ip&gt;, and we should see our demo web server up and running.

image7-6

demo web server

Great! Everything works as expected.

Output values are stored in the state Terraform file. Since we have successfully applied our plan, we can now access these output values at will. We can leverage the terraform output command for this purpose.

image2-15

Terraform output command

Additionally, we can query individual output values by name like this
terraform output &lt;output_value_name&gt;

image5-10

individual output values

To get the raw value without quotes, use the -raw flag.
terraform output -raw &lt;output_value_name&gt; 
To get the JSON-formatted output, we can use the -json flag.

image1-15

the -json flag

This is quite useful when we want to pass the outputs to other tools for automation since JSON is way easier to handle programmatically. Note that Terraform does not protect sensitive output values when using the -json flag.
When we are done, let’s go ahead and delete all these resources to avoid paying for them. 
From the top of our repository, execute:
<code><a href="https://spacelift.io/blog/how-to-destroy-terraform-resources" target="_blank" rel="noopener">terraform destroy</a></code>

When defining output values, we have a couple of options that might help us better define and organize them. 
The argument description is optional, but it is always considered good practice to include it in our output declarations to document their purpose. This argument should briefly explain each output&#8217;s intent and should be used as a helper description for the users of the module. We have already seen examples like this since we defined the description argument in all our output block declarations in our previous demo.
In cases where we want to handle sensitive values and suppress them in command line output, we can declare an output value as sensitive. Terraform will redact the values of sensitive outputs when planning, applying, destroying, or querying outputs to avoid printing them to the console. In practice, this is a good use case when we would like to pass values to other Terraform modules or automation tools without exposing them to the intermediate users.

Note that Terraform won’t redact sensitive output values when you query a specific output by name. After we apply a plan with an output declared as sensitive, the console displays a message with the value redacted.

image4-12

Outputs

These values are still recorded in the state files, so anyone who can access them can also access any sensitive values of our Terraform configuration. 
The depends_on argument on output declarations is used to define dependencies explicitly when this is necessary. Most of the time, Terraform handles this automatically, but there are some rare uses cases where you might find this option handy when it’s not the case. Consider including a comment when you use this option to explain why this is necessary.

Occasionally, we might need to share data between different Terraform configurations with separate states. This is where the terraform_remote_state data sources come into play. We can retrieve the root module outputs from another Terraform configuration using this data source. This built-in data source is available without any extra configuration needed. 
Following up on our previous example, let’s say that we would like to create a new subnet in the vpc of our aws-web-server-vpc module. This time, the new subnet needs to be defined in a completely separate Terraform configuration that has its own state. We can leverage the terraform_remote_state to get the value of the vpc_id defined as an output of our previous example’s root module. In this case, we use the local backend to reach the state of another configuration in the local machine. The backend could be any remote backend that points to a Terraform state in a real-world scenario.

Note that only the output values of the root module are accessible from the remote state. If we want to pass values from nested modules, we have to configure a passthrough output value declaration as we defined earlier in the root module of our previous example. 
Although this option is handy for some use cases, it also has some caveats. To use this data source, the user must have access to the entire state snapshot, which could potentially expose sensitive data. Check out the official docs to find <a href="https://www.terraform.io/language/state/remote-state-data#alternative-ways-to-share-data-between-configurations" target="_blank" rel="nofollow noopener">alternative ways to share data between configurations</a>.

We have seen how Terraform handles and exports output values between modules and the different options for outputs configuration. Even more, we compared input and output variables and examined multiple use cases where the use of outputs is helpful. Finally, we went through a complete example of using output values in our Terraform configuration between different modules and printing them to the console. 
Thank you for reading, and I hope you enjoyed this “Terraform Outputs” blog post as much as I did.

Terraform Count vs. For Each Meta-Argument - When to Use It

What are Terraform outputs? See how Terraform handles and exports output values between modules and the different options for outputs configuration.

66-terraform_output

Terraform Outputs

Terraform Output Values : Complete Guide & Examples

Ansible Guides and Tutorials | Spacelift Blog

Ansible

This blog post deep dives into Ansible Variables, which allow us to parametrize different Ansible components. Variables store values for reuse inside an Ansible project. 
If you are still learning how to use Ansible, you might also find helpful the introductory <a href="https://spacelift.io/blog/ansible-tutorial" target="_blank" rel="noopener">Ansible Tutorial</a> or <a href="https://spacelift.io/blog/ansible-playbooks" target="_blank" rel="noopener">Working with Ansible Playbooks</a> blog posts. You can find this article&#8217;s code on this <a href="https://github.com/spacelift-io-blog-posts/Blog-Technical-Content/tree/master/ansible-variables" target="_blank" rel="nofollow noopener">repository</a> if you wish to follow along.

The use of variables simplifies the management of dynamic values throughout an Ansible project and can potentially reduce the number of human errors. We have a convenient way to handle variations and differences between different environments and systems with variables. 
Another advantage of variables in Ansible is that we have the flexibility to define them in multiple places with different precedence according to our use case. We can also register new variables in our playbooks by using the returned value of a task.
<a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_vars_facts.html#vars-and-facts" target="_blank" rel="nofollow noopener">Ansible facts</a> are a special type of variables that Ansible retrieves from any remote host for us to leverage them in Ansible projects. For example, we can get information regarding the operating system distribution with ansible_distribution, information about devices on the host, the python version that Ansible is using with ansible_python_version, and the system architecture, among others. To access this data, we have to reference the ansible_facts variable.

Ansible has a strict set of rules to create valid variable names. Variable names can contain only letters, numbers, and underscores and must start with a letter or underscore. Some strings are reserved for other purposes and aren’t valid variable names, such as <a href="https://docs.python.org/3/reference/lexical_analysis.html#keywords" target="_blank" rel="nofollow noopener">Python Keywords</a> or <a href="https://docs.ansible.com/ansible/latest/reference_appendices/playbooks_keywords.html#playbook-keywords" target="_blank" rel="nofollow noopener">Playbook Keywords</a>.

The simplest use case of variables is to define a variable name with a single value using standard YAML syntax. Although this pattern can be used in many places, we will show an example in a playbook for simplicity.

In the above example, after the vars block, we define the variable username, and assign the value bob. Later, to reference the value in the task, we use <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_templating.html" target="_blank" rel="nofollow noopener">Jinja2 syntax</a> like this &#8220;{{ username }}&#8221; 
If a variable&#8217;s value starts with curly braces, <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#when-to-quote-variables-a-yaml-gotcha" target="_blank" rel="nofollow noopener">we must quote the whole expression</a> to allow YAML to interpret the syntax correctly.

There are many other options to define more complex variables like lists, dictionaries, and nested structures. To create a variable with multiple values, we can use YAML lists syntax:

To reference a specific value from the list we must select the correct field. For example, to access the third value v3:

Another useful option is to store key-value pairs in variables as dictionaries. For example:

Similarly, to reference the third field from the dictionary, use the bracket or dot notation:

Note that the bracket notation is preferred as you might encounter problems using the dot notation in special cases.
Sometimes, we have to create or use nested variable structures. For example, facts are nested data structures. We have to use a bracket or dot notation to reference nested variables.

There are certain types of variables that we consider special in the context of Ansible. These include magic variables, connection variables, and facts. The names of these variables are reserved. 
Ansible allows us to access information about itself, hosts, groups, inventory, roles, and other Ansible manifests with the so-called magic variables. For a complete list of different options, have a look <a href="https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html#magic-variables" target="_blank" rel="nofollow noopener">here</a>.
We already talked about facts. These variables contain all the information that Ansible can get from the current host. To use them, Ansible has to gather them first. To see all the facts that you can gather on a host, execute:

Lastly, we have connection variables. They are used to configure Ansible execution behavior and actions on hosts. The most common ones configure the user that Ansible logs in, set privilege escalation, set the IP of the target host, etc.

During our plays, we might find it handy to utilize the output of a task as a variable that we can use in the following tasks. We can use the keyword register to create our own custom variables from task output.

In the above example, we register the output of the command find /etc/hosts, and we showcase how we can use the variable in the next task by printing its value.

image3-12

Registering Variables

A powerful pattern is to combine registered variables with conditionals to create tasks that will only be executed when certain custom conditions are true.

Here, we registered in the variable hosts_contents the contents of /etc/hosts file, and we execute the second task only if the file contains the word localhost.

image2-14

Registered Variables localhost

Since registered variables are stored in memory, it’s not possible to use them in future plays, and they are only available for the current playbook run.

When we want to reuse and share variables, we can leverage YAML anchors and aliases. They provide us with great flexibility in handling shared variables and help us reduce the repetition of data.
Anchors are defined with &amp;, and then referenced with an alias denoted with *. Let’s go and check a hands-on example in a playbook.

Here, since some options are shared between users, instead of rewriting the same values, we share the common ones with the anchor &amp;user_info. For every subsequent user declaration, we use the alias *user_info to avoid repeating ourselves as much as possible.
The values for state and create_home are the same for all the users, while name and groups are replaced using the merge operator &lt;&lt;. 
Similarly, we reuse the user_groups declaration in the definition of the user_info anchor. This way, we don&#8217;t have to type the same groups again for user_2 while we still have the flexibility to override the groups, as we do for user_3. 
The result is that user_1 and user_2 are added to groups devs and support, while user_3 is added only to the support group.

image4-11

Share variables with YAML anchors and aliases

Ansible provides many options on setting variables, and the ultimate decision on where to set them lies with us based on the scope we would like them to have. Conceptually, there are three main options available for scoping variables. 
First, we have the global scope where the values are set for all hosts. This can be defined by the Ansible configuration, environment variables, and command line. 
We set values for a particular host or group of hosts using the host scope. For example, there is an option to define some variables per host in the inventory file.
Lastly, we have the play scope, where values are set for all hosts in the context of a play. An example would be the vars section we have seen in previous examples in each playbook.

Variables can be defined with Ansible in many different places. There are options to set variables in playbooks, roles, inventory, var files, and command line. Let’s go and explore some of these options. 
As we have previously seen, the most straightforward way is to define variables in a play with the vars section.

Another option is to define variables in the inventory file. We can set variables per host or set shared variables for groups. This example defines a different ansible user to connect for each host as a host variable and the same HTTP port for all web servers as a group variable.

To better organize our variables, we could gather them in separate host and group variables files. In the same directory where we keep our inventory or playbook files, we can create two folders named group_vars and host_vars that would contain our variable files. For example:

Variables can also be set in custom var files. Let’s check an example that uses variables from an external file and the group_vars and host_vars directories.

The vars/variables.yml file:

The group_vars/webservers file:

The host_vars/host1 file:

The host_vars/host2 file:

The inventory file contains a group named webservers that includes our two hosts, host1 and host2:

If we run this playbook, we notice the same value is used in both hosts for the group variable  http_port but a different one for the host variable app_version.

image1-14

Variable setting options & precedence

A good use case for having separate variables files is that you can keep in them sensitive values without storing them in playbooks or source control systems.
Occasionally we might find it helpful to define or override variables at runtime by passing them at the command line with &#8211;extra-vars or &#8211;e argument. For example:

Since variables can be set in multiple places, Ansible applies variable precedence to select the variable value according to some hierarchy. The general rule is that variables defined with a more explicit scope have higher priority.
For example, role defaults are overridden by mostly every other option. Variables are also flattened to each host before each play so all group and hosts variables are merged. Host variables have higher priority than group variables. 
Explicit variables definitions like the vars directory or an include_vars task override variables from the inventory. Finally, extra vars defined at runtime always win precedence. For a complete list of options and their hierarchy, look at the official documentation <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#understanding-variable-precedence" target="_blank" rel="nofollow noopener">Understanding variable precedence</a>.

Since Ansible provides a plethora of options to define variables, it might be a bit confusing to figure out the best way and place to set them. Let’s go and check some common &amp; best practices around setting variables that might help us better organize our Ansible projects.
<ul>
<li style="font-weight: 400;" aria-level="1">Always give descriptive and clear names to your variables. Taking a moment to properly think about how to name variables always pays off long-term.</li>
<li style="font-weight: 400;" aria-level="1">If there are default values for common variables, set them in group_vars/all</li>
<li style="font-weight: 400;" aria-level="1">Prefer setting group and host vars in group_vars and host_vars directories instead of in the inventory file.</li>
<li style="font-weight: 400;" aria-level="1">If variables related to geography or behavior are tied to a specific group, prefer to set them as group variables.</li>
<li style="font-weight: 400;" aria-level="1">If you are using roles, always set default role variables in roles/your_role/defaults/main.yml</li>
<li style="font-weight: 400;" aria-level="1">When you call roles, pass variables that you wish to override as parameters to make your plays easier to read.</li>
</ul>

<ul>
<li style="font-weight: 400;" aria-level="1">You can always use &#8211;extra-vars or &#8211;e to override every other option.</li>
<li style="font-weight: 400;" aria-level="1">Don’t store sensitive variables in your source code repository in plain text. You can leverage <a href="https://docs.ansible.com/ansible/latest/user_guide/vault.html#creating-encrypted-variables" target="_blank" rel="nofollow noopener">Ansible Vault</a> in these cases.</li>
</ul>
In general, try to keep variables usage as simple as possible. You don’t have to use all the existing options and spread variables definition all over the place because that makes debugging your Ansible projects difficult. Try to find a structure that suits your needs best and stick to it!

In this article, we deep-dived into Ansible Variables and saw how we can define and use them in playbooks. Moreover, we explored different options for sharing, setting, and referencing them, along with some guidelines and best practices to make our Ansible journey easier.
Thank you for reading, and I hope you enjoyed this “Ansible Variables” article as much as I did.

Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities s for infrastructure management.

Terraform vs. Ansible : Key Differences and Comparison of Tools

Ansible Tutorial for Beginners: Playbook & Examples

Working with Ansible Playbooks - Tips & Tricks with Examples

Learn how to work with Ansible Variables, with special and registering variables. See where to set them and best practices.

62-ansible_variables

Ansible variables

Ansible Variables: How to Use Different Types of Ansible Variables (Examples) 

In this article, we are exploring Ansible Playbooks, which are basically blueprints for automation actions. Playbooks allow us to define a recipe with all the steps we would like to automate in a repeatable, simple, and consistent manner. 
If you are entirely new to Ansible, check out this introductory <a href="https://spacelift.io/blog/ansible-tutorial" target="_blank" rel="noopener">Ansible Tutorial</a> first.

<dfn>Playbooks</dfn> are one of the basic components of Ansible as they record and execute Ansible&#8217;s configuration. Generally, a playbook is the primary way to automate a set of tasks that we would like to perform on a remote machine. 
They help our automation efforts by gathering all the resources necessary to orchestrate ordered processes or avoid repeating manual actions. Playbooks can be reused and shared between persons, and they are designed to be human-friendly and easy to write in YAML.

A playbook is composed of one or more plays to run in a specific order. A play is an ordered list of tasks to run against the desired group of hosts. 
Every task is associated with a module responsible for an action and its configuration parameters. Since most tasks are idempotent, we can safely rerun a playbook without any issue.
As discussed, playbooks are written in <a href="https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html#yaml-syntax" target="_blank" rel="nofollow noopener">YAML</a> using the standard extension .yml with minimal syntax. 
We must use spaces to align data elements that share the same hierarchy for indentation. Items that are children of other items must be indented more than their parents. There is no strict rule for the number of spaces used for indentation, but it&#8217;s pretty common to use two spaces while Tab characters are not allowed. 
Below is an example simple playbook with only two plays, each one having two tasks:

We define a descriptive name for each play according to its purpose on the top level. Then we represent the group of hosts on which the play will be executed, taken from the inventory. Finally, we define that these plays should be executed as the root user with the become option set to yes.
You can also define many other <a href="https://docs.ansible.com/ansible/latest/reference_appendices/playbooks_keywords.html" target="_blank" rel="nofollow noopener">Playbook Keywords</a> at different levels such as play, tasks, playbook to configure Ansible&#8217;s behavior. Even more, most of these can be set at runtime as command-line flags in the ansible configuration file, ansible.cfg, or the inventory. Check out the <a href="https://docs.ansible.com/ansible/latest/reference_appendices/general_precedence.html#general-precedence-rules" target="_blank" rel="nofollow noopener">precedence rules</a> to understand how Ansible behaves in these cases.
Next, we use the tasks parameter to define the list of tasks for each play. For each task, we define a clear and descriptive name. Every task leverages a module to perform a specific operation. 
For example, the first task of the first play uses the ansible.builtin.copy module. Along with the module, we usually have to define some module arguments. For the second task of the first play, we use the module ansible.builtin.user that helps us manage user accounts. In this specific case, we configure the name of the user, the state of the user account, and its uid accordingly.

When we are running a playbook, Ansible executes each task in order, one at a time, for all the hosts that we selected. This default behavior could be adjusted according to different use cases using <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_strategies.html#playbooks-strategies" target="_blank" rel="nofollow noopener">strategies</a>. 
If a task fails, Ansible stops the execution of the playbook to this specific host but continues to others that succeeded. During execution, Ansible displays some information about connection status, task names, execution status, and if any changes have been performed. 
At the end, Ansible provides a summary of the playbook&#8217;s execution along with failures and successes. Let&#8217;s see these in action by running the example playbook we saw earlier with the ansible-playbook command.

image1-13

Running a playbook

From the output, we notice the Play names, the Gathering Facts task, the Play tasks, and the Play Recap in the end. Since we didn&#8217;t define a databases hosts group, the second play of the playbook was skipped. 
We can use the &#8211;limit flag to limit the Playbook&#8217;s execution to specific hosts. For example:

Variables are placeholders for values that you can reuse throughout a Playbook or other Ansible objects. They can only contain letters, numbers, and underscores and start with letters. 
Variables can be defined in Ansible in multiple levels, so look at <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable" target="_blank" rel="nofollow noopener">variable precedence</a> to understand how they are applied. For example, we can set variables at the global scope for all hosts, at the host scope for a particular host, or at the play scope for a specific play. 
To set host and group variables, create the directories group_vars and host_vars. For example, to define group variables for the databases group, create the file group_vars/databases. Set common default variables in a group_vars/all file.
Even more, to define host variables for a specific host, create a file with the same name as the host under the hosts_vars directory.
To substitute any variables during runtime, use the -e flag. 
The most straightforward method to define variables is to use a vars block at the beginning of a play. They are defined using standard YAML syntax.

Another way is to define variables in external YAML files.

To use them in tasks, we have to reference them by placing their name inside double braces using the <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_templating.html" target="_blank" rel="nofollow noopener">Jinja2 syntax</a>:

If a variable&#8217;s value starts with curly braces, <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#when-to-quote-variables-a-yaml-gotcha" target="_blank" rel="nofollow noopener">we must quote the whole expression</a> to allow YAML to interpret the syntax correctly. 
We can also define variables with multiple values as lists.

It&#8217;s also possible to reference individual values from a list. For example, to select the first value foo1:

Another possible option is to define variables using YAML dictionaries. For example:

Similarly, to get the first field from the dictionary:

To reference nested variables, we have to use a bracket or dot notation. For example, to get the example_name_2 value from this structure:

We can create variables using the register statement that captures the output of a command or task and then use them in other tasks.

At times, we would need to access sensitive data (API keys, passwords, etc.) in our playbooks. Ansible provides Ansible Vault to assist us in these cases. Storing them as variables in plaintext is considered a security risk so we can use the ansible-vault command to encrypt and decrypt these secrets.
After the secrets have been encrypted with a password of your choice, you can safely put them under source control in your code repositories. Ansible Vault protects only data at rest. After the secrets are decrypted, it&#8217;s our responsibility to handle them with care and not accidentally leak them. 
We have the option to encrypt variables or files. Encrypted variables are decrypted on-demand only when needed, while encrypted files are always decrypted as Ansible doesn&#8217;t know in advance if it needs content from them. 
In any case, we need to think about how are we going to <a href="https://docs.ansible.com/ansible/latest/user_guide/vault.html#managing-vault-passwords" target="_blank" rel="nofollow noopener">manage our vault passwords</a>. To define encrypted content, we add the !vault tag, which tells Ansible that the content needs to be decrypted and the | character before our multi-line encrypted string.
To create a new encrypted file:

Then, an editor is launched to add our content to be encrypted. It&#8217;s also possible to encrypt existing files with the encrypt command:

To view an encrypted file:

To edit an encrypted file in place, use the edit command to decrypt the file temporarily:

To use a different password on an encrypted file, use the rekey command by using the original password:

In case you need to decrypt a file, you can do so with the decrypt command:

Similarly, we use the encrypt_string command to encrypt individual strings that we can use later in variables and include them in playbooks or variables files:

For example, to encrypt the db_password string &#8216;12345679&#8217; using the ansible vault:

image4-10

Ansible Vault

Since we omitted the &lt;password_source&gt;, we manually entered the Vault password. This could also be achieved by passing a password file with &#8211;vault-password-file.
To view the contents of the above example encrypted variable that we saved in the vars.yml file, use the same password as before with the &#8211;ask-vault-pass flag:

For managing multiple passwords, use the option &#8211;vault-id to set a label. For example, to set the label dev on a file and prompt for a password to use:

To suppress output from a task that might log a sensitive value to the console, we use the no_log: true attribute:

If we run this task we will notice that the message isn&#8217;t printed on the console:

Finally, let&#8217;s use the example encrypted variable we created above in a playbook and execute it.

image3-11

Encrypted variable

image2-13

Example secrets playbook

Nice, we verified that we could decrypt the value successfully and use it in tasks.

In general, Ansible modules are idempotent and can be executed safely multiple times, but there are cases where we would like to run a task only when a change is made on the host. For example, we would like to restart a service only when updating its configuration files. 
Ansible uses handlers triggered when notified by other tasks to solve this use case. Tasks only notify their handlers, with the notify: parameter, when the tasks actually change something. 
Handlers should have globally unique names, and it&#8217;s common to author them at the bottom of the playbooks.

In the above example, the Restart apache task will only be triggered when we change something in the configuration. In reality, handlers can be considered inactive tasks waiting to be triggered with a notify statement.
An important thing to note about handlers is that they run by default after all the other tasks have been completed. This way, the handlers only run once, even if triggered many times.
To control this behavior, we can leverage the meta: flush_handlers task that triggers any handlers that have been already notified at that time.
It&#8217;s also possible for a task to notify more than one handler in its notify statement.

To further control execution flow in Ansible, we can leverage conditionals. Conditionals allow us to run or skip tasks based on if certain conditions are met. Variables, facts, or results of previous tasks along with operators, can be used to create such conditions. 
Some examples of use cases could be to update a variable based on a value of another variable, skip a task if a variable has a specific value, execute a task only if a fact from the host returns a value higher than a threshold.
To apply a simple conditional statement, we use the when parameter on a task. If the condition is met, the task is executed. Otherwise, it is skipped.

In the above example, the task is executed since the condition is met. 
Another common pattern is to control task execution based on attributes of the remote host that we can obtain from facts. Check out this list with <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#commonly-used-facts" target="_blank" rel="nofollow noopener">commonly-used facts</a> to get an idea of all the facts we can utilize in conditions.

It&#8217;s possible to combine multiple conditions with logical operators and group them with parenthesis:

Then when statement supports using a list in cases when we have multiple conditions that all need to be true:

Another option is to use conditions based on registered variables that we have defined in previous tasks:

Ansible allows us to iterate over a set of items in a task to execute it multiple times with different parameters without rewriting it. For example, to create several files, we would use a task that iterates over a list of directory names instead of writing five tasks with the same module.
To iterate over a simple list of items, use the loop keyword. We can reference the current value with the loop variable item.

The output of the above task that uses loop and item:

It&#8217;s also possible to iterate over dictionaries:

Another useful pattern is to iterate over a group of hosts of the inventory:

By combining conditionals and loops, we can select to execute the task only on some items in the list and skip it for others:

Finally, another option is to use the keyword until to retry a task until a condition is true.

In the above example, we check the file example_log 10 times, with a delay of 15 seconds between each check until we find the word success. If we let the task run and add the word success to the example_log file after a while, we notice that the task stops successfully.

Check out the <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html" target="_blank" rel="nofollow noopener">official Ansible guide on Loops</a> for more advanced use cases.

Keeping these tips and tricks in mind when building your playbooks will help you be more productive and improve your efficiency.
<h3>1) Keep it as simple as possible</h3>
Try to keep your tasks simple. There are many options and nested structures in Ansible, and by combining lots of features, you can end up with fairly complex setups. Spending some time simplifying your Ansible artifacts pays off in the long term.
<h3>2) Place your Ansible artifacts under version control</h3>
It&#8217;s considered best practice to store playbooks in git or any other version control system and take advantage of its benefits. 
<h3>3) Always give descriptive names to your tasks, plays, and playbooks</h3>
Choose names that help you and others quickly understand the artifact&#8217;s functionality and purpose.
<h3>4) Strive for readability</h3>
Use consistent indentation and add blank lines between tasks to increase readability.
<h3>5) Always mention the state of tasks explicitly</h3>
Many modules have a default state that allows us to skip the state parameter. It&#8217;s always better to be explicit in these cases to avoid confusion.
<h3>6) Use comments when necessary</h3>
There will be times when the task definition won&#8217;t be enough to explain the whole situation, so feel free to use comments for more complex parts of playbooks.

In this article, we had a look into Ansible&#8217;s core automation component, playbooks. We saw how to create, structure, and trigger playbook runs.
Moreover, we explored leveraging variables, handling sensitive data, controlling task execution with handlers and conditions, and iterating over tasks with loops.
Thank you for reading, and I hope you enjoyed this &#8220;Ansible: Working with Playbooks&#8221; article as much as I did.
Btw. If you are looking to manage infrastructure as code, <a href="https://spacelift.io/product?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bansible_vs_terraform%7D" 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, Pulumi, and CloudFormation, with support for Ansible on the way! You can test drive it for free, by going <a href="https://spacelift.io/free-trial?utm_source=blog&amp;utm_medium=text&amp;utm_id=blogpost&amp;utm_content=%7Bansible_vs_terraform%7D">here</a> and creating a trial account.

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

Infrastructure Problems that Spacelift Solves

Playbooks are one of the basic components of Ansible. Learn how to use them and see detailed examples with best practices.

Ioannis Moustakis

Terraform Best Practices for Better Infrastructure Management

Get the newsletter

Recent posts

Terraform Output Values : Complete Guide & Examples

How to Use Different Types of Ansible Variables (Examples)

Working with Ansible Playbooks – Tips & Tricks with Examples

Ansible Tutorial for Beginners: Playbook & Examples