Ansible Guides and Tutorials | Spacelift Blog

Author title

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

Title category

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

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

Managing Infrastructure at Scale | Spacelift Blog

Introducing Stack Dependencies v.2  🎉 🎉

applepodcasts

spotify

missionctrl

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

Ansible

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

Terraform Guides and Tutorials | Spacelift Blog

Terraform

Flavius Dinu

In the worlds of infrastructure as code (IaC) and configuration management, Terraform and Ansible have emerged as two key players. Both of these tools are powerful on their own, but you can use them together to achieve end-to-end elevated workflows.

Terraform is an IaC tool developed by HashiCorp that focuses on managing and provisioning infrastructure across a wide array of cloud platforms and other platforms such as Kubernetes, and RabbitMQ.
It uses a declarative language called HashiCorp Configuration Language (HCL) that describes what the desired state should be. This contrasts with imperative approaches, where commands are given to reach the desired state. The language is developed for reusability, enabling engineers to implement modules (reusable IaC components), use loops and conditionals, and define different input variables for the configurations.
<a href="https://spacelift.io/blog/terraform-state" target="_blank" rel="noopener">Terraform maintains a state file</a> to keep track of the resources it manages. This enables it to identify the difference between the current state of the infrastructure and the desired state defined in the configuration files.

Ansible is an agentless configuration management tool that relies on SSH for Linux hosts or WinRM for Windows hosts to communicate and execute commands directly, eliminating the need for a separate agent to be installed. Sometimes you will see it called ssh on steroids, which is really accurate. 
Ansible configurations are written in playbooks using YAML, and these playbooks describe automation jobs. A single playbook can consist of one or multiple plays, each targeting a set of hosts.
One of Ansible&#8217;s core features is idempotence, which means that you can run the same command any number of times and the result will always be the same. This is critical for configuration management and automation, ensuring consistent results.
Ansible can also be used for infrastructure provisioning, but it is not on par with Terraform’s capabilities.

Terraform is used for managing your infrastructure, but if you want to install and configure software on your compute instances, Ansible is the way to go. You could use Terraform’s provisioners to achieve Ansible’s configuration management capabilities, but they are unreliable, and even HashiCorp recommends using them as the last resort. 
Alternatively, you could use Ansible to provision your infrastructure via collections implemented for cloud providers, but it is much harder to have a highly customized infrastructure without writing a ton of code. 
Although they can sometimes overlap in functionality, they excel in different areas. 
See also &#8211; <a href="https://spacelift.io/blog/ansible-vs-terraform" target="_blank" rel="noopener">Terraform vs. Ansible: Key Differences and Comparison</a>

<ul>
<li><a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">How to Automate Terraform Deployments</a></li>
<li><a href="https://spacelift.io/blog/terraform-with-generic-ci-cd-tools" target="_blank" rel="noopener">Why You Shouldn’t Manage Terraform with Generic CI/CD Tools</a></li>
<li><a href="https://spacelift.io/blog/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener">Why DevOps Engineers Recommend Spacelift</a></li>
</ul>

A common pattern is to use Terraform to set up base infrastructure, including networking, VM instances, and other foundational resources. Once that&#8217;s done, Ansible can be invoked (either manually or via Terraform) to configure those instances, set up necessary software, and deploy applications.
Let’s look at an example that will provision a couple of EC2 instances in AWS and after that will configure them with Ansible:

In the above example, we are creating three EC2 instances, and adding an ssh key to all of them. 
We are assigning public ips to these instances, to speed up the process of configuring them via Ansible. In the real world, usually, all these instances will have only private ips, and they will be configured through a bastion host.
As the code was written with a for_each loop, we can easily extend the number of instances, just by modifying the local Terraform variable.
We’ve also created an output containing all the public ips of the instances:

After running an apply, this is what we observe:

We can now prepare an inventory file based on the above servers for Ansible. The <a href="https://spacelift.io/blog/ansible-inventory" target="_blank" rel="noopener">inventory file in Ansible</a> is a configuration file for your hosts and groups and hosts that tells Ansible where to execute tasks, allowing users to define specific variables and configurations for different hosts. 
This is how I created my inventory file:

We will create a simple ansible playbook that installs htop.

Now we can run Ansible and install htop on all of the servers:

Now, if we add another EC2 instance in the Terraform configuration, we will have to manually re-run both Terraform and Ansible, which can sometimes be problematic. Whenever you have multiple things to do after you commit your code, the chances for errors increase. 
This is where Spacelift comes to the rescue.

<a href="https://docs.spacelift.io/concepts/stack/stack-dependencies" target="_blank" rel="noopener">Stack dependencies v2</a> is a game changer when it comes to deploying multiple configurations in the correct order, without having to do manual interventions. 
Stack dependencies are Directed Acyclic Graphs (DAG) of dependencies that can nest on how many levels you want. This allows you to create powerful end-to-end workflows that can even combine multiple IaC tools such as Terraform, OpenTofu, Ansible, CloudFormation, Kubernetes, Terragrunt, or even Pulumi.
We will create two stacks (one for Terraform and one for Ansible) and a dependency between them.
We will start by creating a context so we can share the ssh keys to both stacks. This is done by going to Contexts, creating a new context and adding the public and private keys as mounted files inside of it:

ansible-with-terraform

ansible with terraform

Next, as we don’t want to use static credentials, we are going to leverage a cloud Integration to AWS. This is easily done by following the guide from <a href="https://docs.spacelift.io/integrations/cloud-providers/aws" target="_blank" rel="noopener">here</a>.
In the end, your cloud integration will be similar to this:

terraform-and-ansible

terraform and ansible

I’ve added the code I’ve shown before in a repository:
<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/saturnhead/blog-examples/tree/main/tf-ansible-stack-dependencies/tf" target="_blank" rel="nofollow noopener">Terraform configuration</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/saturnhead/blog-examples/tree/main/tf-ansible-stack-dependencies/ansible" target="_blank" rel="nofollow noopener">Ansible configuration</a></li>
</ul>
Next, let’s create two stacks based on the mentioned configurations.
<h3>Terraform stack</h3>
First go to Stacks and select Create Stack.

terraform-with-ansible

terraform with ansible

Add a name for your stack and select a space. Next, put in the details related to your VCS configuration:

ansible-and-terraform

ansible and terraform

In the next two screens accept the defaults and click on Save Stack.
We need to attach the previously created context and cloud integration to this stack. 
Let’s start with the context. Go to the stack settings and select Contexts, choose the context from the drop down list, and click on Attach.

spacelift-context-terraform-with-ansible

spacelift context terraform with ansible

Similarly, for the cloud integration, go to the stack settings, select Integrations and then AWS.

cloud-integration-ansible-terraform

cloud integration ansible terraform

Now let’s create the Ansible stack.
<h3>Ansible stack</h3>
The process of creating the Ansible stack is similar to the one for creating the Terraform stack. We will add a name for our stack and select the repository, but we will have to make some changes to the Configure Backend and Define Behaviour Tabs.
In the Configure Backend tab, we will select Ansible and specify the playbook file:

backend-terraform-ansible

backend terraform ansible

In the Define Behavior tab we will make some changes in the before init runner phase:

We need to ensure the ssh permissions for the private key are 600 (read and write for the owner and no permissions for the group or others).
To ensure there are no problems with the ssh key permissions, add the chmod 600 before the apply phase as well.
With the following two commands, we are building the inventory dynamically. The output of the Terraform stack will be similar to this:

As my plan is to create a stack dependency between these two stacks and pass this output from the Terraform stack to the Ansible one, I want to ensure these ips are going in the correct format in the inventory file. Based on the configuration above, I will have to name this output “instances”. 
Before jumping in and creating the dependency per se, let’s do a couple more configurations to the Ansible stack.
First, let’s attach the context in the same way we did for the Terraform one. Next, go to the Environment tab of the Ansible stack and add the following environment variables:
<ul>
<li style="font-weight: 400;" aria-level="1">ANSIBLE_PRIVATE_KEY_FILE – this is the path to the ssh private key used to connect to the ec2 instances</li>
<li style="font-weight: 400;" aria-level="1">ANSIBLE_INVENTORY – path to the inventory file</li>
<li style="font-weight: 400;" aria-level="1">ANSIBLE_REMOTE_USER – the remote user used for the ssh connection</li>
</ul>

ansible-environment-variables

ansible environment variables

<h3>Creating the stack dependency</h3>
Go to the Terraform stack, select Dependencies, click on Add Dependencies, and select the Ansible stack:

stack-dependency-ansible-terraform

stack dependency ansible terraform

Next, click on Add output reference, select the output and call it instances to ensure our Ansible configuration will work properly:

terraform-ansible-instances

terraform ansible instances

Click on Add. Now we can run our configuration.
After the run finishes successfully on the Terraform stack, it will automatically trigger a run on the Ansible stack:

trigger-stacks-terraform-ansible

trigger stacks terraform ansible

run-ansible-with-terraform

run ansible with terraform

Now, if I add a new instance to my Terraform configuration by adding a new map to the local variable, this will be picked up by my Terraform stack and it will get configured with my Ansible one after that.

terraform-configuration-with-ansible

terraform configuration with ansible

As you can see, there will be another instance created after I accept the plan. In the meantime, the Ansible stack reached a queued state until the EC2 instances stack finishes the run. If that is successful, it will start the run on the Ansible one.

run-ansible-stacks

run ansible stacks

As soon as it finished creating the EC2 instance, the Ansible stack started the run to configure it. Now that’s finished, all EC2 instances are configured successfully.

ec2-instance-ansible-terraform

ec2 instance ansible terraform

Despite activating in the same areas for some of their use cases, Terraform and Ansible complement each other. Using them together, can greatly enhance your workflows and simplify the tasks around managing, provisioning, and configuring your infrastructure.
Spacelift greatly simplifies and elevates your workflow for both of these tools, and the capability of creating dependencies between stacks and passing outputs gives you the possibility to make end-to-end deployments while just making a small change.
If you want to learn more about Spacelift, <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">create a free account today</a> or <a href="https://spacelift.io/schedule-demo" target="_blank" rel="noopener">book a demo with one of our engineers</a>.

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 for infrastructure management.

How to Use Different Types of Ansible Variables (Examples)

Working with Ansible Playbooks - Tips & Tricks with Examples

10 Popular Terraform Alternatives You Should Know in 2023

In this tutorial, you'll learn how to use Terraform and Ansible together. See how Spacelift can greatly simplify and elevate your workflow for both tools.

291-terraform-and-ansible

291.terraform and ansible

Using Terraform and Ansible Together

Ioannis Moustakis

This blog post will dive deep into using the Ansible shell module and explore different ways of executing remote commands on nodes with Ansible as part of our automation efforts. We will review different options and modules for running remote commands and discuss their differences and when to use each.
If you are new to Ansible or interested in other Ansible concepts, <a href="https://spacelift.io/blog/ansible" target="_blank" rel="noopener">these Ansible tutorials</a> on Spacelift’s blog might be handy. 
We will cover:
<ol>
<li><a href="https://spacelift.io/blog/ansible-shell-module#what-is-the-ansible-shell-module">What is the Ansible shell module?</a></li>
<li><a href="https://spacelift.io/blog/ansible-shell-module#using-ansibe-shell-module-examples">Using Ansible shell module examples</a></li>
<li><a href="https://spacelift.io/blog/ansible-shell-module#alternative-options-to-run-remote-commands-with-ansible">Other options to run remote commands with Ansible</a></li>
<li><a href="https://spacelift.io/blog/ansible-shell-module#when-to-use-the-ansible-shell-module-vs-command-module">When to use the shell module vs. command module</a></li>
</ol>

The Ansible <a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/shell_module.html" target="_blank" rel="nofollow noopener">shell module</a> is used to execute shell commands in the remote target machines. The <code>shell</code> module takes the command name followed by a list of space-delimited arguments.  
The <code>shell</code> module does not execute directly on the target but in a shell environment (<code>/bin/sh</code>) on the target. This makes it possible to use shell-specific features and functions such as pipe <code>|</code>, redirection <code>&lt;</code>, <code>&gt;</code>, <code>&gt;&gt;</code>, and so forth. 
If you are targeting Windows nodes, use the <a href="https://docs.ansible.com/ansible/latest/collections/ansible/windows/win_shell_module.html#ansible-collections-ansible-windows-win-shell-module" target="_blank" rel="nofollow noopener">ansible.windows.win_shell</a> module.

Let’s take a look at some examples of using the shell module in action.
<h3>Example 1: Ansible shell module to execute a single command</h3>

In this example, we are using the <code>shell</code> module to get the last ten lines of the <code>/var/log/syslog</code> file and pipe the output to a file <code>tail_syslog.txt</code>. The <code>shell</code> module is indeed here, as the <code>&gt;</code> operator is a feature of the shell. 
<h3>Example 2: Run a command using the shell module if a file doesn’t exist</h3>

The above example would run the command only if the file <code>file_to_check.txt</code> doesn’t exist. This is achieved with the <code>creates</code> parameter and is useful in cases where we need to check if commands that produce a specific artifact have already been executed.
<h3>Example 4: Show disk usage</h3>

In the above example, we use the <code>df -h</code> command to show disk usage and pipe it to filter only results for <code>/dev/sda1</code>. This is an example of a command that can’t be run correctly with the <code>command</code> module. 
The command output is registered in the <code>disk_usage</code> variable and displayed in the next task.

ansible-shell-output

ansible shell output

<h3>Example 5: Execute command in a specific directory</h3>

That’s another example of using the <code>args</code> keyword with <code>chdir</code> to execute a shell command in a specific directory. 
The <code>make install</code> command will be executed in the <code>path/to/source/code</code> directory in this case.
<h3>Example 6: Execute multiple commands</h3>

Another example would be to chain multiple commands together with the <code>&amp;&amp;</code> operator, as shown above. In this case, the shell module executes the commands one by one from top to bottom.
<h3>Example 7: Check if a process is running</h3>

In this example, we use <code>ps aux</code> to list all the processes and then the pipe operator <code>|</code> to find the <code>nginx</code> process we&#8217;re interested in. 
We also use a second pipe and <code>grep</code> to exclude our own grep command from the results.
<h3>Example 8: Select the shell used to execute the command</h3>

In this example, we are using the <code>executable</code> parameter to specify the shell used to execute the command. This can be useful in cases where the default <code>/bin/sh</code> doesn’t support a feature we want to leverage.
<h3>Example 9: Use Templated Variable in the command</h3>

In the above example, we use a templated variable in a command.  
When using <a href="https://spacelift.io/blog/ansible-variables" target="_blank" rel="noopener">Ansible variables</a> in commands, make sure to use <code>{{ var | quote }}</code> instead of <code>{{ var }}</code> to add quotes around the variable value, which helps to avoid injection and ensure the contents of the variable are treated as a single argument and not interpreted by the shell.

<div class="styles_textWrapper___qfEA">
<div class="bodyTextWrapper WysiwigContent_wysiwigContent__duACp">
<ul>
<li><a href="https://spacelift.io/blog/self-service-infrastructure" target="_blank" rel="noopener">Why You Need Self-Service Infrastructure</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
<li><a href="https://spacelift.io/blog/ansible-best-practices" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;44 Ansible Best Practices to Follow [Tips &amp; Tricks]&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">44 Ansible Best Practices to Follow</a></li>
</ul>
</div>
</div>

We generally prefer using specialized <a href="https://spacelift.io/blog/ansible-modules" target="_blank" rel="noopener">Ansible modules</a> over raw shell or command scripts. Task-specific Ansible modules are designed to be idempotent and to abstract away the underlying complexities of tasks, which makes them preferable to directly executing commands via the shell or command modules, for example.
Even more, specialized modules handle errors gracefully. 
If something goes wrong, they often provide helpful error messages to aid in troubleshooting and are safer to use than arbitrary shell commands, which can inadvertently open up security risks. Ansible modules can report whether they made a change on the remote system, which helps to understand better changes performed to the targeted systems.
On some occasions, you might not be able to leverage any task-specific module to achieve your desired outcome. We can use Ansible to execute commands directly on remote hosts in these cases. Ansible provides several ways to execute commands on remote nodes. 
We’ve already seen the <code>shell</code> module, and next, we will look at the <code>command</code>, <code>expect</code>, <code>script</code>, and <code>raw</code> modules for this purpose.
<h3>Ansible command module</h3>
The <a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/command_module.html" target="_blank" rel="nofollow noopener">command module</a> in Ansible executes commands on all selected hosts. It&#8217;s one of the most straightforward modules; it takes the command name followed by a list of space-delimited arguments. If you are targeting Windows nodes, use the <a href="https://docs.ansible.com/ansible/latest/collections/ansible/windows/win_command_module.html#ansible-collections-ansible-windows-win-command-module" target="_blank" rel="nofollow noopener">ansible.windows.win_command</a> instead.
It’s important to note that commands aren’t processed through the local shell with the <code>command</code> module. This means that variables like <code>$HOSTNAME</code> won’t work, and shell-specific functions like piping commands and redirection operators (<code>&lt;</code>, <code>&gt;</code>, <code>&gt;&gt;</code>, <code>|</code>, etc.) won&#8217;t be interpreted correctly. 
This behavior makes the <code>command</code> module safer and more predictable than the <code>shell</code> module that we will discuss later. When using the <code>command</code> module, you can be sure the command will execute exactly as you&#8217;ve written it, without any unexpected side effects from shell processing.
Here’s a basic example showcasing how to leverage the <code>command</code> module in a task:

In the above example, <code>ls /var/log</code> is the command being executed. The command output is registered in the <code>log_files</code> variable, which is then displayed using the <code>debug</code> module in the next task.
Here’s an example output of the above two tasks:

ansible-shell-register

ansible shell register

Here’s another example of using the <code>command</code> module to check whether a package is installed in a target system:

Here, we check whether NGINX is installed by running the <code>which nginx</code> command and checking the return code(rc). 
The <code>changed_when: false</code> line ensures that Ansible doesn’t report a change every time the <a href="https://spacelift.io/blog/ansible-playbooks" target="_blank" rel="noopener">Ansible playbook</a> is executed, and <code>failed_when: false</code> makes the command succeed and not block the playbook from continuing even if the package isn’t found. 
Here’s an example output of the above two tasks:

ansible-shell-args

ansible shell args

Finally, here’s an example with <code>with_items</code> to run multiple commands with one task. This approach could be helpful when running a sequence of commands as part of your playbook.

<h3>Ansible expect module</h3>
The <a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/expect_module.html" target="_blank" rel="nofollow noopener">expect module</a> in Ansible executes commands and responds to prompts. It’s often used to automate interactions with applications that require responses to prompts. 
When using the <code>expect</code> module, you must specify the command that will be run and the responses. The responses are a mapping of expected string/regex and string to respond with. 
Note that commands aren’t processed through the shell. 
Here’s an example usage of the <code>expect</code> module that responds to user input during the installation process of a package.

Consider the security implications of automating prompt responses and handling sensitive data when using the <code>expect</code> module. 
Since the <code>expect</code> module has been designed for simple use cases, consider using the <code>shell</code> or <code>scripts</code> module for more complex and advanced use cases.
<h3>Ansible script module</h3>
The <a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/script_module.html" target="_blank" rel="nofollow noopener">script module</a> executes a local script on remote nodes after transferring it. This module takes the script name followed by a list of space-delimited arguments. The given script will be processed through the shell environment on the remote node.
 Note that if the path to the local script contains spaces, it needs to be quoted.
Here’s a basic usage of the script module:

Here’s a more advanced example using the <code>args</code> keyword to control the script environment.

In the above example, we run a script while setting the shell to use, the directory to change into before running the script, and checking if a file exists before running the script. 
As discussed previously, using or writing Ansible modules is usually preferable rather than running long scripts. Consider converting your script to an Ansible module to make your playbooks more readable and understandable.
<h3>Ansible raw module</h3>
The <a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/raw_module.html" target="_blank" rel="nofollow noopener">raw module</a> executes raw commands on remote hosts, much like how you might execute commands over SSH. It executes low-down and dirty SSH commands, not going through the module subsystem. 
This module does not require Python on the remote system, making it useful in scenarios where Python is not installed or when you&#8217;re dealing with devices that don&#8217;t support Python. 
This module is also supported for Windows targets.
Here’s an example of using the <code>raw</code> module to install Python with <code>yum</code>:

It’s worth noting that the raw module is less safe, idempotent, and predictable than most other Ansible modules, and it doesn’t support advanced Ansible features such as variable substitutions, loops, conditionals, etc. 
Its usage should be avoided unless there is no other way. It may be better to use the <code>shell</code> module to execute a command securely and predictably.

Previously, we discussed in detail the usage of <code>shell</code> and <code>command</code> modules and went through various examples. Next, let’s define some cases where we should prefer one over the other. 
Unlike the <code>command</code> module, <code>shell</code> module does not execute directly on the target but in a shell environment on the target. This makes it possible to use shell-specific features and functions such as pipe <code>|</code>, redirection <code>&lt;</code>, <code>&gt;</code>, <code>&gt;&gt;</code>, and others. If your commands contain any such shell-specific features, such as piping commands, variable substitution, redirecting output to files, you have to use the shell module. 
Another use case for the <code>shell</code> module would be if your command involves a script that must be executed in the shell context. Since the <code>shell</code> module allows the use of shell functionalities, it might also make your playbooks less portable.
On the other hand, the <code>command</code> module is preferred in most cases as the most straightforward way to run a command on a remote host. Using the <code>command</code> module to execute a command is considered more secure and produces more predictable results. 
Best practices when writing playbooks will follow the trend of using the <code>command</code> module unless using shell features is explicitly required.
Check out more <a href="https://spacelift.io/blog/ansible-best-practices" target="_blank" rel="noopener">Ansible best practices</a>.

In this blog post, we explored how to leverage the Ansible shell module and other different options for executing remote commands with Ansible. We have gone through detailed examples and explained the intricacies and particularities of each different option. 
Lastly, we saw examples of each module in action while discussing the different use cases that will make you select one over the other.
You can also explore how <a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a>’s vibrant ecosystem and excellent GitOps flow can greatly assist you in managing and orchestrating Ansible. By introducing Spacelift on top of Ansible, you can then easily <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">create custom workflows</a> based on pull requests and apply any necessary <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">compliance checks</a> for your organization. Get started on your journey by <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">creating a free trial account</a>.
Thank you for reading, and I hope you enjoyed this as much as I did!

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure. It helps overcome common state management issues and adds several must-have features for infrastructure management.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure. It helps overcome common state management issues and adds several must-have features for infrastructure management.

How to Create Ansible Template [Examples]

Working with Ansible Inventory - Basics and Use Cases

Infrastructure as Code (IaC) and Policy as Code Scanning for Vulnerabilities

Learn how to run remote commands with Ansible shell module. See examples. The difference between Ansible shell vs. command.

246-ansible-shell

ansible run shell script

Using Ansible Shell Module to Execute Remote Commands

Ioannis is a Cloud Architect with a background in DevOps &amp; Site Reliability Engineering interested in Cloud Infrastructure, Automation, CI/CD Pipelines &amp; Containerization. In his free time, he curates a personal blog at <a href="https://devopsmadness.com" rel="noopener nofollow">devopsmadness.com</a> and <a href="https://moustakisioannis.medium.com" rel="noopener nofollow">moustakisioannis.medium.com</a>. Opinions expressed are solely his own.

How To Create and Use Templates in Ansible

In this blog post, we will explore templating with Ansible to parametrize configuration files and leverage variables in templates.
What are Ansible templates? Templates are useful in cases where we would like to reuse a file but with different parameters for various use cases or environments.
If you are new to Ansible or interested in other Ansible concepts, <a href="https://spacelift.io/blog/ansible" target="_blank" rel="noopener">these Ansible tutorials</a> on Spacelift’s blog might be handy.

With Ansible templating, users can dynamically generate text-based files using templates, variables, and <a href="https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_vars_facts.html#vars-and-facts" target="_blank" rel="nofollow noopener">facts</a> for configuration and other purposes. The main objective of using templates is to facilitate and automate the management of configuration files for different targets and requirements.
Imagine that you need to maintain multiple similar environments but with different requirements or specifications. Instead of manually creating, maintaining, and editing configuration files for each target system, we can leverage Ansible templates. We can then combine the templates with other Ansible concepts, such as facts and variables, to generate files tailored to each system&#8217;s specific needs without code duplication.
Updating configuration files becomes more manageable with this approach since we only have to perform the changes in one place and handle any inputs with variables that will be replaced with actual values during the playbook execution.
Ansible uses <a href="https://palletsprojects.com/p/jinja/" target="_blank" rel="nofollow noopener">Jinja2</a> as the default templating engine to create dynamic content.

<ul>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;10 Ways to Improve Your Infrastructure as Code&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">10 Ways to Improve Your Infrastructure as Code</a></li>
<li><a href="https://spacelift.io/blog/spacelift-ansible-integration-beta" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to manage Ansible more securely&quot;}" data-sheets-userformat="{&quot;2&quot;:6723,&quot;3&quot;:{&quot;1&quot;:0},&quot;4&quot;:{&quot;1&quot;:2,&quot;2&quot;:16777215},&quot;9&quot;:0,&quot;12&quot;:0,&quot;14&quot;:{&quot;1&quot;:2,&quot;2&quot;:0},&quot;15&quot;:&quot;Arial&quot;}">How to Manage Ansible More Securely</a></li>
<li><a href="https://spacelift.io/blog/devops-best-practices" target="_blank" rel="noopener">16 DevOps Best Practices to Follow</a></li>
</ul>

Jinja2 is a full-featured template engine for Python. The Jinja2 templating engine is quite powerful and widely used with other frameworks and applications such as Flask and Django. 
Jinja2 templates combine plain text files and special syntax to define and substitute dynamic content, embed variables, expressions, loops, and even conditional statements to generate complex output. According to the <a href="https://jinja.palletsprojects.com/en/3.0.x/templates/" target="_blank" rel="nofollow noopener">documentation</a>, expressions are enclosed in double curly braces <code>{{ }}</code>, statements in curly braces with percent signs <code>{% %}</code>, and comments in <code>{# #}</code>.
Let’s have a look at some examples below:
<ul>
<li>Jinja2 example with a variable named <code>favourite_color</code></li>
</ul>

<ul>
<li>Jinja2 if statement example</li>
</ul>

<ul>
<li>Jinja2 loop example</li>
</ul>

Something worth mentioning is that the templating happens before the task is sent to the target machine. Therefore this approach doesn’t require the installation of any extra packages on the target machine and minimizes the amount of data sent. 
Another helpful functionality is utilizing the <a href="https://jinja.palletsprojects.com/en/3.1.x/templates/#builtin-filters" target="_blank" rel="nofollow noopener">standard filters and tests</a> included in Jinja2 to perform different operations. Ansible also implements extensions to Jinja2, including extra filters for selecting and transforming data and <a href="https://docs.ansible.com/ansible/latest/plugins/lookup.html#lookup-plugins" target="_blank" rel="nofollow noopener">Lookup plugins</a> for retrieving data from external sources.

To use templates in <a href="https://spacelift.io/blog/ansible-playbooks" target="_blank" rel="noopener">Ansible playbooks</a>, we can use the <a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/template_module.html" target="_blank" rel="nofollow noopener">template module</a>, which takes as inputs the template and the target file, and other necessary parameters to customize the final output file. 
In the first example, we will create a template file <code>test.conf.j2</code> with the contents of the example we saw earlier.
test.conf.j2

Now let’s create a simple playbook and use Ansible&#8217;s <code>template</code> module. Our playbook contains some values for the variables and only one templating task. 
test_templates_playbook.yml

If we execute this playbook the <code>/tmp/test.conf</code> file will be created based on the template and the inputs. Let’s check its contents after we have executed the above playbook.
/tmp/test.conf

We have used variables, if statements, and for loops to produce a final configuration file based on our input and the base template.
Finally, let’s see an example with a real use case. In the second example, we will use a template to create a configuration file for an <a href="https://docs.nginx.com/nginx/admin-guide/web-server/" target="_blank" rel="nofollow noopener">Nginx web server</a>.
Here’s the template that we will use.
nginx.conf.j2

We will use this template in the playbook below to provision an Nginx web server.
main_playbook.yml

We also used a simple custom <code>index.html</code> file for the homepage of our web server.
index.html

Let’s go ahead and run this playbook. For this demo, we have created a virtual machine locally with <a href="https://www.vagrantup.com/" target="_blank" rel="nofollow noopener">Vagrant</a> to serve as Ansible&#8217;s target.

ansible-tempates-main-playbook

ansible tempates main playbook

Last step, let’s ssh into the local host, verify that everything has run successfully, and check the file <code>/etc/nginx/sites-available/default</code> generated from the template.

vagrant-ansible-templates

vagrant ansible templates

The templating has worked as a charm, and our web server is up and running!

This blog post deep-dived into the templating capabilities of Ansible. Ansible leverages <a href="https://jinja.palletsprojects.com/en/latest/templates/" target="_blank" rel="nofollow noopener">Jinja2</a> to enable dynamic expressions and parametrization of files with variables, loops, conditions, and more. We discussed the characteristics and syntax of Jinja2, and we saw various templating examples. Finally, we reviewed a playbook that uses the <a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/template_module.html" target="_blank" rel="nofollow noopener">template</a> module to produce a configuration file for a web server. 
You can also explore how <a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a>’s vibrant ecosystem and excellent GitOps flow can greatly assist you in managing and orchestrating Ansible. By introducing Spacelift on top of Ansible, you can then easily <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">create custom workflows</a> based on pull requests and apply any necessary <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">compliance checks</a> for your organization.
Thank you for reading, and I hope you enjoyed this as much as I did.

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

44 Ansible Best Practices to Follow [Tips & Tricks]

Ansible Modules - How To Use Them Efficiently (Examples)

What are Terraform Templates? Examples and Use Cases

See how to use Ansible templates to parametrize configuration files and leverage variables in templates with Jinja2 and Ansible Playbooks.

186-ansible-templates

How to Keep Your Playbooks Secure With Ansible Vault

This blog post will dive deep into Ansible Vault as a mechanism for keeping your sensitive values and secrets secure in your playbooks and other Ansible files. We will explore different options for working with encrypted content and password management options. 
If you are new to Ansible or interested in other Ansible concepts, <a href="https://spacelift.io/blog/ansible" target="_blank" rel="noopener">these Ansible tutorials</a> on Spacelift’s blog might be handy.

Ansible Vault is a feature that provides a native way to handle sensitive information. Ansible Vault allows users to encrypt secrets and other sensitive data such as API keys, passwords, and other credentials to protect them at rest.
Instead of storing secrets in plaintext, Ansible Vault gives you a secure, native, and low-effort option to manage sensitive information by leveraging encryption. Using Ansible Vault, encrypted content can be stored in <a href="https://spacelift.io/blog/ansible-playbooks" target="_blank" rel="noopener">playbooks</a>, variable files, and roles, persisted under source control, and shared without exposure risks. 
Ansible Vault protects your sensitive content only at rest. Users are responsible for not exposing decrypted content in the console or any other way. Check out the <a href="https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#keep-secret-data" target="_blank" rel="nofollow noopener">no_log</a> option for tasks to hide their output if necessary.

We must use passwords to encrypt and decrypt sensitive data with Ansible Vault. The passwords are used to create encrypted variables or files, decrypt, and view or edit the encrypted content. 
To supply the password for these operations, you can either leverage the <code>ansible-vault</code> command and get prompted for it, set up a location of a password file in your main configuration definition, <code>ansible.cfg</code>, or integrate with an external secret store solution that holds your passwords. 
As you can imagine, since you have to keep track of your vault passwords, there is a process involved around password management in any of these cases. You might leverage the same password for all your encrypted content for simple cases, small teams, and a few encrypted values. This approach simplifies your password management process since you only have to deal with a single password. Store and handle this password and other sensitive data in your secret management system. 
You might have to create and manage more vault passwords for complex systems and different access levels for different teams and people. For example, you might use a different password per team, per environment, per ansible role, application, directory, or any other pattern that fits your needs. 
You can specify a dedicated vault id for every password in such cases. Whenever you generate newly encrypted content, you can pass the dedicated id with the flag <code>--vault-id</code>.  Store this id along with the password and pass it with the password during decryption. 
We will look into more examples of leveraging vault IDs in the next section on how to encrypt sensitive values. 
As discussed previously, a simple but not really secure option would be to store passwords in a local file. If you decide to go that way, make sure the file has the correct permissions, store the password as a string in a single line, and don’t persist it in any code repositories. 
A more secure and scalable way would be to use an external secret store for storing passwords and fetch them dynamically with the help of a vault password client script. A vault password client script is responsible for connecting to the remote secret store, fetching the secret, and printing the password to standard output. Look at the <a href="https://docs.ansible.com/ansible/latest/vault_guide/vault_managing_passwords.html#storing-passwords-in-third-party-tools-with-vault-password-client-scripts" target="_blank" rel="nofollow noopener">Storing passwords in third-party tools with vault password client scripts</a> section of the official documentation for details on how to create and use such scripts.

Ansible Vault can assist users with encrypting mainly two types of data, <a href="https://spacelift.io/blog/ansible-variables" target="_blank" rel="noopener">variables</a> and files. This means we can encrypt either whole files or only specific values stored in encrypted variables. 
By encrypting specific variables, our content will be decrypted on demand only when needed. This option allows us to mix encrypted and plaintext content according to our needs inside playbooks and roles. One drawback of this approach is that it works only with variables and that changing or rotating the password might be a bit cumbersome since there isn’t a command that supports this.  
On the other hand, encrypting whole files allows us to encrypt other content (for example, tasks) apart from variables, and then decryption happens when the file is referenced. We can easily use the <code>rekey</code> command to change or rotate the password used for encryption on files, and in general file-level encryption is easier to use and manage.
A disadvantage of this approach is that since we are encrypting the whole content of the files, we are trading away readability and accessibility since we can’t read the file without effort and get an understanding of its contents. One way to bypass this issue could be to keep the names or references of your encrypted content in a separate non-encrypted file. Look at <a href="https://docs.ansible.com/ansible/latest/tips_tricks/ansible_tips_tricks.html#tip-for-variables-and-vaults" target="_blank" rel="nofollow noopener">Keep vaulted variables safely visible</a> for more information on the topic. 
Let’s look at some examples next. We will start by encrypting a variable.
<h3>Encrypting Ansible Variables</h3>
To encrypt a string to use in a variable, you can leverage the <code>ansible-vault encrypt_string</code> command. 
To encrypt the string <code>encrypt_this_string_please</code> named <code>encrypted_string</code> and provide the password via the command line:

ansible-vault-encrypt_this_string_please

ansible vault encrypt_this_string_please

Notice that the produced encrypted content starts with the <code>!vault</code> tag, which indicates to Ansible that this value is encrypted and needs decryption to use. After this tag, Ansible adds a header before the encrypted content that includes the format ID, the vault format version, and the cipher algorithm used for encryption. 
If you create the encrypted variable with a vault ID, this is also included in the generated content. If you are interested in more information, check out the <a href="https://docs.ansible.com/ansible/latest/vault_guide/vault_using_encrypted_content.html#format-of-files-encrypted-with-ansible-vault" target="_blank" rel="nofollow noopener">format of files created with Ansible Vault</a> section of the official docs.

ansible-vault-vault-id

ansible vault vault ID

You can also select the password source. For example, let’s use a file named <code>password_file</code> as our password source.

ansible-vault-password_file

ansible vault password_file

To avoid persisting the secret value in your shell history, don’t pass directly with the command, but opt to be prompted for a string to encrypt like this:

You can find more command options by using the <code>--help</code> flag.

<ul>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
<li><a href="https://spacelift.io/blog/ansible-best-practices" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;44 Ansible Best Practices to Follow [Tips &amp; Tricks]&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">44 Ansible Best Practices to Follow</a></li>
<li><a href="https://spacelift.io/blog/spacelift-ansible-integration-beta" target="_blank" rel="noopener">How to Manage Ansible More Securely </a></li>
</ul>

<h3>Encrypting Ansible Files</h3>
To encrypt whole files that include structured data, you can leverage the <code>ansible-vault create</code> or the <code>ansible-vault encrypt</code> commands. Different files that can be encrypted include group, host, defaults, roles, and other custom variable files, tasks files, handlers files, binary, or other arbitrary files.
<h4>Creating a New Encrypted File</h4>
To create a new encrypted file, <code>encrypted_file.yml</code>, with vault ID dev, and get prompted for the password, use this command:

This will open your configured editor (by default it would be vi) to provide the content to be encrypted. The same considerations discussed earlier for storing and using Ansible Vault passwords apply here.
After you provide your plain text content to the file and save and exit from it, you will only see the encrypted one when you try to view the content. To view it in plain text again, you will need to decrypt it.

<h4>Encrypting an Existing File</h4>
Before encrypting an existing file, let’s take a look at its content:

Next, let’s encrypt it. This operation is as simple as running this command:

You will be prompted for a password, so ensure you will remember it, as it will be required for the decrypt operation.
Now if we want to check the content of the file, this is what we will see:

In the previous section, we explained the process and went over several options for encrypting different content with Ansible Vault. Now, let’s look at how we can utilize and work with encrypted content. 
One of the most common operations for a user is to be able to view the encrypted content if necessary. You can leverage the <code>debug</code> module to view the plaintext value of encrypted content. 
Let’s create a simple encrypted variable and pass the password via the prompt:

ansible-vault-pass-the-password-via-the-prompt

ansible vault pass the password via the prompt

Next, we store this variable in a file named <code>file_with_stored_encrypted_variable.yml</code>.

ansible-vault-store-variable-in-a-file

ansible vault store variable in a file

To view the encrypted value, use the <code>debug</code> module and pass the location of the password as we have seen earlier:

<h3>Viewing Encrypted Files</h3>
Viewing the contents of encrypted files is quite simple with the <code>ansible-vault view</code> command:

<h3>Editing Encrypted Files</h3>
Another handy option when working with encrypted files is the ability to edit the encrypted content with the <code>ansible-vault edit</code> command:

This command prompts the user for the password, decrypts the content to a temporary file, allows the user to edit the encrypted content with the configured editor, and finally saves and re-encrypts the file. 
<h3>Decrypting Encrypted File</h3>
To permanently decrypt an encrypted file, use the <code>ansible-vault decrypt</code> command. You will need to provide the encryption password:

Now if we go back and check the content of that file, it will be human-readable again:

<h3>Changing the Password for Encrypted Files</h3>
Another common operation is to rotate or change the password used for encryption. As briefly discussed in the previous section, this can be achieved with the <code>ansible-vault rekey</code> command. 
To change the password for an encrypted file, use the command below, and pass the current and the new password when prompted:

You will need to provide the old password and then provide a new password and confirm it for this to work.
When you need to decrypt content from a playbook with encrypted variables that have been created with different passwords and vault IDs, pass multiple <code>--vault-id</code> flags when executing the playbook. For example:

In case you use a specific vault ID or a password source more frequently than others, you can define default options and avoid passing them every time. Leverage <a href="https://docs.ansible.com/ansible/latest/reference_appendices/config.html#default-vault-identity-list" target="_blank" rel="nofollow noopener">DEFAULT_VAULT_DENY_LIST</a> and <a href="https://docs.ansible.com/ansible/latest/reference_appendices/config.html#default-vault-password-file" target="_blank" rel="nofollow noopener">DEFAULT_VAULT_PASSWORD_FILE</a> to set this up.

Here are best practices to consider when you are using Ansible Vault:
<ul>
<li>Use strong passwords for encryptions – You should avoid easily guessed passwords, and ensure your passwords are strong and complex.</li>
<li>Avoid storing Vault passwords in VCS – It goes without saying that you should never commit Vault passwords to a git repository because this will result in instant password breaches</li>
<li>Rotate secrets regularly – Regularly rotate secrets stored in Ansible Vault to reduce the risk of unauthorized access in case of a breach.</li>
<li>Audit and Review access – Ensure that only authorized people have access to Vault files and passwords.</li>
<li>Integrate with Secret Management tools – Integrate with external secret management tools such as HashiCorp Vault or AWS Secrets Manager if you require advanced features and integrations.</li>
</ul>

In this blog post, we explored different options for encrypting sensitive information by leveraging Ansible Vault. We explained Ansible Vault’s main functionality and discussed various options for handling sensitive content, passwords, and files. Lastly, we went over examples and use cases of using encrypted content. 
You can also explore how <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a>’s vibrant ecosystem and excellent GitOps flow can greatly assist you in managing and orchestrating Ansible. By introducing Spacelift on top of Ansible, you can then easily <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">create custom workflows</a> based on pull requests and apply any necessary <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">compliance checks</a> for your organization.
Thank you for reading and I hope you enjoyed this as much as I did!

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;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.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">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.

Terraform vs. Ansible : Key Differences and Comparison of Tools

Ansible Roles: Basics, Creating & Using

Explore different options for encrypting sensitive information by leveraging Ansible Vault with examples and use cases of using encrypted content.

134-ansible_vault

How to Use Ansible Vault to Keep Your Playbooks Secure

In this blog post, we will dive deep into different concepts around building an Ansible inventory, along with best practices. We will look into basic functionality, managing variables, and combining multiple inventory sources and options for working with dynamic inventories. 
If you are new to Ansible or interested in other Ansible concepts, <a href="https://spacelift.io/blog/ansible" target="_blank" rel="noopener">these Ansible tutorials</a> on Spacelift’s blog might be handy.

An Ansible inventory is a collection of managed hosts we want to manage with Ansible for various automation and configuration management tasks. Typically, when starting with Ansible, we define a static list of hosts known as the inventory. These hosts can be grouped into different categories, and then we can leverage various patterns to run our playbooks selectively against a subset of hosts. 
By default, the inventory is stored in <code>/etc/ansible/hosts</code>, but you can specify a different location with the <code>-i</code> flag or the <a href="https://docs.ansible.com/ansible/latest/installation_guide/intro_configuration.html#configuration-file" target="_blank" rel="nofollow noopener">ansible.cfg</a> configuration file. 
Let’s take a look at what a simple inventory looks like. The most common formats are either INI or <a href="https://spacelift.io/blog/yaml" target="_blank" rel="noopener">YAML</a>.

In this example, we use the INI format, define four managed hosts, and we group them into two host groups; webservers and databases. The group names can be specified between brackets, as shown above.
Inventory groups are one of the handiest ways to control Ansible execution. Hosts can also be part of multiple groups.

Note: By default, we can also reference two groups without defining them. The <code>all</code> group targets all our hosts in the inventory, and the <code>ungrouped</code> contains any host that isn’t part of any user-defined group.
We can also create nested groups of hosts if necessary.

To list a range of hosts with similar patterns, you can leverage the range functionality instead of defining them one by one. For example, to define ten hosts (host01, host02, …. host10):

Learn about Ansible inventory basic functionality, managing variables, and combining multiple inventory sources and options for dynamic inventories.

Using Terraform and Ansible Together

Get the newsletter

Recent posts

Using Ansible Shell Module to Execute Remote Commands

How to Create Ansible Template [Examples]

How to Use Ansible Vault to Keep Your Playbooks Secure

Working with Ansible Inventory – Basics and Use Cases

44 Ansible Best Practices to Follow [Tips & Tricks]

Ansible + Spacelift = Better Together

Ansible Modules – How To Use Them Efficiently (Examples)

Ansible Roles: Basics, Creating & Using

How to Use Different Types of Ansible Variables (Examples)

Working with Ansible Playbooks – Tips & Tricks with Examples

Ansible Tutorial for Beginners: Ultimate Playbook & Examples

Terraform vs. Ansible : Key Differences and Comparison of Tools