How to Implement Ansible Automation Workflows

Released in 2012, Ansible is an open-source configuration management tool that uses a simple YAML-based syntax to define tasks that can be executed across multiple remote virtual machines using SSH or WinRM. 

Ansible is agentless, so it just needs SSH or WinRM access to configure your remote systems. You don’t even need to have Ansible installed on these remote servers, making it a pretty lightweight tool.

Some of the common use cases for Ansible include:

• Configuration management: Install and configure various services such as Nginx, Apache, Docker, and ensure they are up and running. (Read more: Configuration Management with Ansible)
• Application deployment: Deploy applications across multiple environments, packaging them, and restarting their services.
• Infrastructure provisioning: You can provision infrastructure through different Ansible collections (although this is not where Ansible shines).

As a lightweight tool, Ansible is not reliable enough to be used in production environments on its own, and that’s where Ansible automation steps in.

Ansible automation refers to how you structure your workflow execution of Ansible playbooks, roles, and configurations through automation rather than doing it manually. It includes the orchestration of configuration management tasks, application deployments, and infrastructure provisioning (in some cases) through programmatic triggers, scheduling, and integration with external systems.

Leveraging Ansible automation techniques is paramount for your enterprise’s configuration management journey. Let’s explore some of the methodologies for automating your Ansible workflows.

1. Using a remote server for Ansible deployments

When CI/CD pipelines were less popular, the easiest way to enable collaboration for configuration management was to have a centralized remote server that could be accessed only by the engineers involved in the configuration management process.

A version control system could easily have hosted the playbooks, and whenever changes were made to them, one of the engineers would update these repositories on the centralized remote server.

This could potentially offer some high-level audit capabilities, as you could see, at least, who ran the playbooks and which inventory was used.

While this approach could work for small teams and projects even in today’s landscape, the following limitations make it less suitable for modern DevOps practices:

• Security concerns: Granting multiple engineers access to a remote server via SSH increases the attack surface in case of a breach.
• Lack of automation: Engineers need to connect manually to a server and run commands manually.
• Inconsistent environments: You have a greater chance of running untested playbooks against production infrastructure

You could combine this approach with different cron jobs for pulling code changes and running Ansible playbooks to achieve some level of automation, but it would not be enough. However, understanding the traditional approach has value because it laid the groundwork for the current approach to building automation.

2. Using a generic CI/CD pipeline

Compared with the previous option, using generic CI/CD pipelines takes Ansible to the next level. Generic CI/CD pipelines include Jenkins, GitHub Actions, GitLab CI/CD, or Azure DevOps, each of which offers a specific set of features for Ansible management.

While Ansible doesn’t have an exact equivalent to terraform plan, many tasks have implemented support for running in check mode. This mode simulates what Ansible would do without making any changes to your remote servers. 

Alongside linting and syntax checking, check mode can be part of your CI process to catch potential issues before any changes to your actual infrastructure are applied. Tools such as ansible-lint can be used to enforce coding standards and validate the structure of your playbooks or your roles, and making them a part of your CI processes greatly reduces the chances of misconfigurations.

Leveraging CI/CD pipelines brings the advantage of standardization and lets you define workflows that:

• Run tests on each pull request
• Lint and validate playbooks
• Run Ansible in check mode against a staging or test inventory
• Deploy only after all checks pass
• Notify teams via Slack, MS Teams, or others

This level of automation reduces the likelihood of human error and ensures a consistent and repeatable process for applying configurations. Another benefit is increased auditability. Every playbook run is traceable through pipeline logs, and changes are linked to commits, pull requests, and user activity.

In addition, if you are using a cloud provider for your compute, you can leverage dynamic credentials by using OIDC, for example, to authenticate from your CI/CD pipeline to your cloud provider, making the process of building the inventory easier.

One of the biggest challenges of using CI/CD pipelines for your Ansible workflows is maintaining, modifying, and continually ensuring the proper functioning of all these CI/CD configurations.

Another key thing you will be missing is observability. You will need to build or integrate external tooling for visibility, as it will be really hard to understand what happened or where. Generic CI/CDs offer basic logging, but they lack detailed insights into the Ansible runtime behavior.

3. Leveraging Ansible Automation Platform or AWX

Ansible Automation Platform (AAP) is a fully-fledged configuration management orchestration tool for Ansible that is designed to solve some of the challenges associated with managing your Ansible configurations. It provides a centralized dashboard, role-based access control, job scheduling, and logging to streamline automation workflows.

This tool solves some of the biggest challenges of running Ansible with generic CI/CD by providing a UI to understand what is happening with your Ansible playbooks, the ability to schedule jobs, logging, and using its API to build different integrations.

Some of the biggest challenges when using AAP are the fact that the product itself is not very customizable, has a steep learning curve, and is unaffordable for small and midsize businesses. 

AWX is an open-source version of AAP that offers almost the same functionality as AAP without the licensing fees. It can be a great choice for small and midsize businesses. 

With AWX, you can manage your Ansible playbooks, view details of your hosts, implement different levels of access control, and get better overall visibility than you would get with a generic CI/CD platform. Because it is open-source, it doesn’t offer the enterprise-grade support that AAP does, making it hard to use in an enterprise. 

See also: Step-by-Step Guide to Automation with Ansible AWX

Both AAP and AWX are specialized platforms for Ansible automation, and they have strengths and weaknesses. While they aim to offer a GitOps workflow, you need to consider that you can use only Ansible with them.

4. Leveraging an infrastructure orchestration platform

Spacelift is an infrastructure orchestration platform that helps you provision, configure, and govern your infrastructure in a single workflow. Apart from supporting Ansible, Spacelift specializes in Terraform, OpenTofu, Kubernetes, Terragrunt, Pulumi, and Cloudformation, making it a great choice for companies that use multiple infrastructure tools.

Spacelift offers a powerful observability feature for Ansible that lets you understand what happened with your hosts — which playbooks and roles ran, their details and logs, and the differences between runs.

With Spacelift, you also get stack dependencies, letting you easily create dependencies between your workflows and even share outputs (e.g., you can create a dependency between a Terraform workflow that provisions EC2 instances and an Ansible stack that deploys several tools on those instances, sharing the instances’ output directly). These dependencies can extend to as many nested levels as you want, making it easy to build a single end-to-end workflow that can be easily debugged in case of issues.

In addition, Spacelift offers self-service capabilities, so you can easily implement workflows that can be deployed by anyone on your team without having to learn how to use the platform. This is done using the Blueprints feature, and if your teams are already using ServiceNow, this feature integrates natively with it, meeting your developers where they are and empowering them to provision and configure resources from the tools they know how to use.

In addition, Spacelift integrates natively with the major cloud providers, lets you define policies based on Open Policy Agent (OPA), and enables drift detection and optional remediation.

By supporting multiple tools and offering all these other capabilities, Spacelift aims to deliver where AAP and AWX fall short.

Would you like to see this in action, or just get a tl;dr? Check out this video showing you Spacelift’s Ansible functionality:

In this post, we discussed four ways to implement Ansible automation and their strengths and weaknesses. You can choose from:

1. A remote server for Ansible deployments
2. A generic CI/CD pipeline
3. Ansible Automation Platform or AWX
4. An infrastructure orchestration platform

If you are interested in a product that shines at Ansible automation, infrastructure provisioning, and container orchestration, Spacelift is a great choice. To learn more about Spacelift, create a free account, or book a demo with one of our engineers.