Introducing Spacelift’s Latest Ansible Functionality

It’s live! We are excited to announce the newest enhancement to our Ansible functionality. 

This update addresses key challenges we have identified with Ansible and configuration management:

• Running Ansible playbooks in large-scale or complex environments
• Linking provisioning and configuration management to create a fluid workflow across all your pipelines

Understanding your playbook activity, especially in vast environments, can be hard to track without a proper mechanism.  With this new version, you can easily gain insights into everything happening with your hosts, including what ran successfully and what failed, logs about what is going on, and other insights about them.

Spacelift now includes:

• Better playbook automation – Manage the execution of Ansible playbooks from one central location.
• Inventory observability – View all Ansible-managed hosts and related playbooks, with clear visual indicators showing the success or failure of recent runs.
• Playbook run insights – Audit Ansible playbook run results with detailed insights to pinpoint problems and simplify troubleshooting.
• Improved integrated IaC & Ansible workflows – Easily define workflows that combine Terraform and Ansible to streamline infrastructure provisioning and configuration management.
• Developer Self-service – Integrate Ansible playbooks into infrastructure self-service for developers.

I’ve put together a short video summing up these challenges, the benefits of linking provisioning and configuration management, and the way Spacelift’s new enhancements address those challenges:

Want to dig deeper? Then keep reading as we walk through some of the use cases you can achieve with the new Ansible support. All code examples use Spacelift’s OpenTofu/Terraform provider and are configuring AWS EC2 instances. The only thing you will need to change for the code work is to provide a cloud integration id in the examples’ tfvars file.

For each example, we will create an administrative stack based on the code in the examples folder and walk you through how easy it is to do it.

You can find the code repository here. Forking it is the easiest way to get started with it.

Here are the scenarios we will walk through:

1. Using Ansible standalone
2. Using Ansible with Infrastructure as Code (IaC)
3. Using Ansible with security vulnerability scanning
4. Using Ansible for self-service
5. Using Ansible with IaC and Container Orchestration (CO)

You can use Ansible standalone by either providing an inventory file or by generating an inventory using the necessary plugins. 

For this first use case example, we will generate a dynamic inventory based on some constraints. The code for this example is here.

The above snippet will build the inventory based on all ec2 instances in the eu-west-1 region, that have a dev tag, and are in a running state. You can change the conditions to suit you.

In this example, we assume that the SSH keys required to connect to the EC2 instances are uploaded into SSM in this path: `/ec2_standalone/ssh/private_key` to ensure we can connect to them. If you don’t want to handle the creation of the EC2 instances manually, here is an example code that will create the instances so that they respect all the conditions mentioned before.

Let’s create the administrative stack that will create everything required for Ansible. First, go to Create Stack, add a name, and select a space for your stack:

Next, select the repository and specify the branch and a folder for your code. If you’ve forked the repo and haven’t changed how it is structured, the folder should be the same as below: 

In the next step, choose either Terraform or OpenTofu as your vendor:

Then click on Create & Continue and go to Define behavior (optional) and enable the Administrative option:

Now you can save and skip to the summary. 

In the summary, after you ensure everything is configured correctly, click on Confirm to create your stack successfully.

Remember, this just creates the administrative stack, so you will repeat these steps for all examples, changing the example folder in the second step.

Now, your administrative stack is up and running and you can trigger a run:

These are all the resources that will be created by this example:

Confirm the run and wait for them to be created:

Now, you will see an Ansible stack being created:

Let’s trigger a run and wait for the plan to finish:

As you can see, we have matched three hosts, two tasks were skipped (because in the playbook we’ve disabled the checks in the dry_run mode), and two tasks will make changes.

A legend at the bottom shows the possible statuses for a task or role:

• Green is OK.
• Yellow is Changed.
• Orange is Unreachable.
• Red is Failed.
• Blue is Skipped.
• Teal is Rescued.
• Purple is Ignored.

This makes it very easy to observe all the statuses at a glance.

Clicking on any task will show its output:

In the playbook, we set the disk threshold for available disk space to 10GB. We are using t2.micro instances, so this will probably fail.

Let’s confirm the run and wait for it to apply:

The first thing we notice is that the available disk space is 6GB, so the run will fail once we reach a  task that fails because the disk space is lower than 10GB:

To make the run work, we can either modify the playbook (which we won’t do because we want to be able to replicate this error on other occasions) or use a custom runtime config when we trigger the run.

Let’s go back to the stack, click on the arrow next to the trigger button, and select the Trigger with the custom runtime config option:

Here we will need to specify a custom value for our disk_space_threshold and then click on trigger:

All the required tasks have run successfully:

Would you like to provision and configure everything in a single workflow? We’ve got you covered with Spacelift’s stack dependencies, which let you create dependencies between different configurations (tools included, too). 

This means that you can easily create a dependency between an OpenTofu or Terraform stack and an Ansible one. The best part? You can even share outputs between them, so in this use case, we will build an ec2 output in a name => {env: env_value, public_dns: public_dns_value} fashion and share it with the Ansible stack. 

Based on this output, we will build the inventory on the Ansible level.

We will create an administrative stack as we’ve done before for the example from here.

As you can see, this administrative stack takes care of the creation of a Terraform or OpenTofu stack that will create some ec2 instances, and then passes the ec2 instances output to Ansible. Based on a command embedded in the lifecycle hooks from Ansible, we are building the inventory:

echo \”$INSTANCE_JSON\” | jq -r ‘to_entries | group_by(.value.env) | .[] as $group | \”[\” + $group[0].value.env + \”]\\n\” + ($group | map(.value.public_dns) | join(\”\\n\”)) + \”\\n\”‘ > /mnt/workspace/ansible_inventory.ini

Now, if we run the IaC stack, a run will be triggered on the Ansible one:

As soon as the IaC stack finishes, the Ansible one will be triggered:

In this case, whenever your infrastructure changes, Ansible will detect the changes and recreate the inventory based on its current status, making it easy to avoid manual work.

Security vulnerability scanning is not just for your IaC, you can rely on it for configuration management too. 

This example can be found here. We will use Checkov for security vulnerability scanning in the Ansible code.

A custom input policy has been created for Checkov:

The policy will show you the total number of failed and passed checks. Based on this number, you can decide what to do for your run.

This is an example result of a run:

In this example, we are using roles. To make it easier to understand what is part of a standalone task and what is part of a role, the run item has the keyword “Role” inside it:

What about configuring infrastructure using self-service? Self-service is not just for provisioning: It should enable you to provision, configure, and govern everything in one go. Spacelift Blueprints paired with administrative stacks give you the option to do all of these together. 

You can also build an Ansible forms functionality, meaning that you can enable or disable functionality based on the inputs you give to a form. Here is an example.

If you’ve replicated the example, this is the form you will end up with:

The playbook we are using for this example installs Apache and can customize the message in the index.html file. Based on flags, it can also trigger a run upon stack creation and install htop.

Provisioning infrastructure, configuring it, and orchestrating containers all in one go can be very difficult. However, it’s easy to do it with Spacelift by leveraging stack dependencies.

The example can be found here.

The Terraform/OpenTofu configuration sends two outputs: one to Ansible for building the inventory and one to the Kubernetes cluster containing the command needed to log in to an EKS cluster. Remember that these dependencies can go on as many nested levels as you want.

As soon as the infrastructure changes, the Ansible and K8s stacks will detect the changes, and recreate the inventory or the EKS login command (if needed in both cases). They will then run and configure the instances and orchestrate the containers in the EKS cluster.

Spacelift’s Resource View feature enables you to easily see all the infrastructure resources that have been deployed with your Spacelift account.

This unparalleled visibility is now also available for Ansiblel. If you select the Configuration Management option on top, you will see all our hosts and everything that has been configured on them:

Now, you can observe everything that is happening in your infrastructure from a single place, filter on many different criteria, and even create your own custom views.

Our latest Ansible enhancements solve three of the biggest challenges engineers face when they are using Ansible:

• Having a centralized place in which you can run your playbooks
• Combining IaC with configuration management to create a single workflow
• Getting insights into what ran and where

Provisioning, configuring, governing, and even orchestrating your containers can be performed with a single workflow, separating the elements into smaller chunks to identify issues more easily.

Would you like to see this in action – or just want a tl;dr? Check out this video I put together showing you Spacelift’s new Ansible functionality:

If you want to learn how to improve your infrastructure workflows, create a free account with Spacelift, or book a demo with one of our engineers.