Product

Introducing Spacelift’s Latest Ansible Functionality

spacelift ansible integration

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.

integration_id = "01H79TE7EP3W7K4AMMV447J189"

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)

1. Using Ansible standalone

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.

plugin: aws_ec2
regions:
 - eu-west-1
filters:
 tag:Env: dev
 instance-state-name: running

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:

1 create ansible 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: 

2 select the repository

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

3 choose opentofu or terraform vendor

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

4 enable administrative option

Now you can save and skip to the summary. 

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

6 administrative stack

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

7 ansible example resources

Confirm the run and wait for them to be created:

8 confirm the run

Now, you will see an Ansible stack being created:

9 created ansible stack

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

10 trigger a run

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:

11 task 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:

12 confirm the run

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:

13 task failed

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:

14 trigger run with custom runtime config

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

15 runtime config details

All the required tasks have run successfully:

16 successful run

2. Using Ansible with an IaC tool

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.

17 ansible opentofu dependency

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:

18 run the iac stack

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

19 ansible stack 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.

3. Using Ansible with security vulnerability scanning

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:

package spacelift

warn [sprintf(message, [p])] {
   message := "This is the number of passed checks: %d"
   results := input.third_party_metadata.custom.checkov.results.passed_checks
   p := count(results)
}
sample = true


warn [sprintf(message, [p])] {
   message := "This is the number of failed checks: %d"
   results := input.third_party_metadata.custom.checkov.results.failed_checks
   p := count(results)
}
sample = true

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:

20 policy 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:

21 configuration management items

4. Enabling Ansible self-service

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:

22 ansible self service stack

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.

5. Using Terraform/OpenTofu, Ansible, and Kubernetes together

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.

23 ansible kubernetes and terraform

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.

Resource View

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

24 ansible resource view

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:

25 ansible account resources

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.

Key points

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.

Elevate Your Ansible Automation

Managing large-scale playbook execution is hard. Spacelift enables you to automate Ansible playbook execution with visibility and control over resources, and seamlessly link provisioning and configuration workflows.

Learn more

The Practitioner’s Guide to Scaling Infrastructure as Code

Transform your IaC management to scale

securely, efficiently, and productively

into the future.

ebook global banner
Share your data and download the guide