Using Kerberos for Windows in Ansible Automation Platform 2

Kerberos is often the preferred authentication method for managing Windows servers in a domain environment. Red Hat Ansible Automation Platform has allowed customers to leverage Kerberos authentication for a number of years now. So why revisit this subject? 

Ansible Automation Platform 2 was released in July 2021 and was a major re-architecture of the platform. One of the fundamental changes was the introduction of automation execution environments  - the use of containers to consistently package, distribute and execute Ansible Playbooks. Without going into the weeds, automation execution environments consist of a RHEL base image, Ansible Core and any dependencies required to execute our Ansible automation - these are typically Ansible Content Collections and Python libraries. 

The move to containers means that we sometimes need to consider that localhost is now a container. There is an excellent blog post that goes into the details of how localhost isn’t what it seems when it comes to automation execution environments.

With all of this in mind, let’s go through a guided example of how to configure Kerberos authentication in Ansible Automation Platform 2, how to test the configuration and how to configure automation controller to use Kerberos.

Example configuration

Continue reading

Private automation hub – Multi-Hub for resilience

Ansible Content Collections have become the new standard for distributing Ansible content (playbooks, roles, modules, and plugins). Collections have been fully supported since Ansible 2.9 and for the last 2 years, the Ansible community has been on a journey to move to this new way of packaging and consuming Ansible content. With Ansible 2.9, Collections were optional, but as of 2.10 they are a requirement. The ability to be able to install and use Collections as needed is increasingly important.

To help customers manage Collections, private automation hub was released with Red Hat Ansible Automation Platform 1.2. Private automation hub can be deployed in a datacenter or cloud provider and allows users to synchronise and curate content from various sources:

• Certified and supported content from automation hub hosted on console.redhat.com
• Self-supported community content from Ansible Galaxy
• Private content

With private automation hub in place, customers can control the Ansible content that they publish and make available within their organisation. Users can either consume these Collections from the command line or directly from within automation controller. 

With this increased reliance on Collections and therefore private automation hub, Ansible Automation Platform 2.1 introduced the Continue reading

On-Demand execution with Red Hat OpenShift

Being able to dynamically scale infrastructure is no longer a nice-to-have - it is a requirement. The advent of cloud and container platforms have shifted the expectations in terms of consuming IT infrastructure and services. As a result, any tool that is used to manage infrastructure needs to be able to handle this ever-changing landscape. 

Red Hat Ansible Automation Platform provides customers with the tools that they need to build an automation solution. The component automation controller helps enterprises automate and scale with confidence. 

One of the ways we can scale our automation is to leverage container groups. Container groups are part of automation controller, and allow customers to leverage an existing OpenShift cluster to create on-demand execution capacity for Ansible Playbooks. When a job is executed from automation controller, it creates pods on the target OpenShift cluster, which runs the automation job. Once the job is complete, the pods are terminated. This provides a number of benefits:

• Fewer wasted resources - infrastructure isn’t sitting idle while waiting for automation jobs. Once a job completes, the resources are instantly freed up.
• Deliver execution capacity quicker - we don’t need to provision infrastructure up front.
• Less focus on capacity Continue reading

Using an Inventory Plugin from a Collection in Ansible Tower

Many IT environments grow more and more complex. It is more important than ever that an automation solution always has the most up to date information about what nodes are present and need to be automated. To answer this challenge, the Red Hat Ansible Automation Platform uses inventories: lists of managed nodes.

In its simplest form, inventories can be static files. This is ideal when getting started with Ansible, but as the automation is scaled, a static inventory file is not enough anymore:

1. How do we update and maintain a list of all of our managed nodes if something changes, if workloads are spun up or teared down?
2. How do we classify our infrastructure so that we can be more selective in what managed nodes we automate against?

The answer to both of these questions is to use a dynamic inventory: a script or a plugin that will go to a source of truth and discover the nodes that need to be managed. It will also automatically classify the nodes by putting them into groups, which can be used to more selectively target devices when automating with Ansible.

Inventory plugins allow Ansible users to use external platforms to Continue reading