Red Hat’s Ansible Automation Platform: A GitOps approach to automation

Karl Fischer, CTO of Obsidian Systems.

---

Managing infrastructure efficiently has become an important aspect of today’s business operations. We often explore how tools like Red Hat’s Ansible Automation Platform (AAP) can help companies streamline their environments. For instance, GitOps pipelines can integrate with Ansible to facilitate the likes of disaster recovery, automated provisioning and source-code-first methods of managing complex infrastructure.

In a recent product demonstration, I showed how Obsidian’s AAP runs on a test OpenShift environment, with a standard deployment that helps us simulate real-world infrastructure conditions. Using GitOps pipelines, we can streamline the process of provisioning and maintaining infrastructure, which allows us to ‘lift and shift’ tasks easily. The demonstration highlighted a practical use case – managing source code for infrastructure in a disaster recovery situation by linking it directly with GitOps and providing an audit trail and a seamless recovery process.

To accomplish this, I configured GitLab as the triggering mechanism for our Ansible playbooks. Our pipeline set-up is straightforward: first, it runs a linting check to ensure there are no syntax or code compliance issues, followed by triggering the Ansible playbook itself. This approach aligns with best practices by detecting potential issues in the code before deployment, ensuring that only compliant configurations are applied.

For this demonstration, I thought it would be fun to inject a bit of Star Trek inspiration. We configured our GitOps pipeline to deploy instances named after beloved Star Trek starships and stations, like Deep Space Nine and Voyager. While this set-up may seem whimsical, it actually illustrates a critical capability of AAP: flexibility in provisioning customised resources at scale.

Each deployment in this demo involved a range of steps, from reading configurations to creating custom inventories and credential sets. By structuring our project with well-defined inventories for each ‘organisation’ (ie, starship), we demonstrated how infrastructure can be customised yet unified under a central platform. The GitLab pipeline’s playbook is then executed against each inventory to set up various resources – like users and credentials – within the Ansible environment.

One of the standout features of this set-up is how Ansible Playbooks manages configurations. For example, we set up the playbook to reference variables stored in Git, which ensured that everything from customer labels to organisational details was pulled directly from the source code. This method of using a single source of truth aligns with the GitOps philosophy, providing clarity and consistency across environments.

Once the playbook was triggered, it created credentials and templates, linking back to our Star Trek-themed inventories. By using a ‘wrapper’ playbook to deploy these items, we kept the configuration process efficient and straightforward, reducing potential clutter from unnecessary repositories. This approach also prevents code drift, as the codebase is continuously updated and maintained in Git.

Inventory management in AAP is where much of the magic happens. In this demo, each customer’s inventory was stored as YAML files in GitOps. These were then mapped to the corresponding hosts within Ansible, creating a tightly integrated inventory system. For example, running a ping or gather-facts command against a specific inventory, like Deep Space Nine, would automatically trigger the sync, pulling down the latest data.

This approach has immense potential for companies with diverse infrastructure, allowing them to keep inventories updated automatically. In our Star Trek example, the inventory files stored information on ship classes, captains and roles for each starship. By syncing these inventory files directly from GitOps, we ensured that our infrastructure definitions remained consistent across all environments.

Beyond configurations, AAP also allows for customised user management. For each company in the demo, I created users based on characters from Star Trek (eg, Wesley Crusher for Next Generation). Each user had a unique e-mail and role, demonstrating how AAP can manage specific access permissions for infrastructure across different teams.

Through our playbook, we assigned roles and permissions programmatically, which illustrates the power of automation in enhancing security and operational efficiency. AAP’s robust credential management further ensures that sensitive information like passwords and SSH keys remain secure, as they are reset with each playbook run without exposing data through the API.

Overall, the demo highlights how Red Hat’s AAP, integrated with GitOps, enables a streamlined and reliable approach to managing infrastructure. By centralising configurations and automating deployments with Ansible, we achieve consistency, compliance and scalability.

If you are interested in exploring how automation and GitOps can transform your infrastructure, feel free to reach out to Obsidian Systems. With AAP, we can help you set up a similar environment tailored to your business needs.

To watch the Red Hat's Ansible Automation Platform demo, go to: https://youtu.be/aDs3Ag9ZF78.