Seeding Ansible Automation Platform Content At Installation Time

In a previous blog, I announced the tech preview of containerized Red Hat Ansible Automation Platform. With that we introduced a new feature to enable you to pre-seed configuration and content at installation time. This blog will take you through how that works.

At Red Hat, we are very lucky to have some super talented people. Some of these great folks have worked tirelessly on producing Ansible Content Collections for managing configuration within the platform. Using this as the foundation, we have wrapped enablement around that to provide a fully automated way of doing this, in a seamless fashion.

The Benefits

Many people today already use a configuration-as-code (CaC) approach to managing the platform and laying down standards for their users. If that’s your case, then this simply extends and simplifies this capability.

If this is a new concept to you, then these examples may be of interest:

• Standardize your user’s out of the box (OOTB) experience, in one go, at installation time.
  • Are there platform artifacts that you always need to apply to each and every installation? Define those as code and simply point the installation at that code and it will pre-configure the platform

• The ability Continue reading

Announcing Containerized Ansible Automation Platform

Everything you know and love about Ansible Automation Platform in containerized form

We’re excited to announce something that we’ve been working on for a while now, the technical preview of a containerized Red Hat Ansible Automation Platform solution.

Currently, this will allow you to install and run containerized automation controller, Ansible automation hub, and the Event-Driven Ansible controller services on just one or more underlying RHEL hosts on x86_64 and ARM64 architectures. This does not require a kubernetes-based platform, as it just uses native RHEL podman on top of a RHEL host.

The rationale behind containerized Ansible Automation Platform

As Ansible Automation Platform evolved, we added more services and components into the stack. Over time, the increasing complexity and inter-dependencies between these components have introduced new challenges in terms of maintenance, installation, and support. They have also opened up opportunities for growth and innovation.

Containerized Ansible Automation Platform is the first step towards a more streamlined and improved platform management experience, incorporating our future vision and strategy.

The benefits

Just containerizing existing services was not enough for us, so we set some goals to provide:

• a slimmed down installation experience
• a layered installation approach
• a containerized Continue reading

Subscription and Host Metric Changes in Ansible Automation Platform 2.4

What and Why?

Our customers use Ansible Automation Platform across a multitude of platforms, in a plethora of ways. Providing an accurate accounting and reporting capability is sometimes difficult across the various types of use cases we encounter.

If you have traditionally used the platform with infrequently changing or more static types of managed hosts, you’re probably pretty much covered. If however, you administer a more diverse and dynamic set of hosts, there may be occasions where you require more flexibility, when accounting for managed hosts against your purchased subscription.

That’s why in Ansible Automation Platform 2.4, we’ve introduced a new Host Metrics dashboard tab with the ability to:

• View high level automation run details per managed host

• The first and last time automated (this metric already existed)
• The number of times automation has been run or attempted to be run against a host (new in 2.4)
• The number of times a managed host has been deleted (new in 2.4)

The ability to view the number of times automation has been run on hosts is a simple but really useful metric:

• Instantly see your most commonly automated hosts
• See which hosts exist in Continue reading

Ansible Automation Platform Moving Towards Smarter Inventory

TL;DR What is this?

It has been a long term ask and our desire to make Smart Inventory, well, smarter. We’ve listened to feedback, and are now addressing not only direct customer asks but also presenting solutions to make it better overall.

The current Red Hat Ansible Automation Platform  Smart Inventory

The current Smart Inventory has a number of shortcomings:

• The smart inventory host_filter cannot express that a variable EQUALS a value, or do basic logic like NOT.
• Host/group/inventory variables cannot be filtered as a combined unit, as these are separate fields.
• Resultant smart inventories do not contain groups.
• The smart inventory host_filter has its own custom syntax, which isn’t the most friendly.

All of these issues stem from the original design of Smart Inventory, and the fact that Inventory Django models (Inventory, Group, and Host) save their “variables” in text form as YAML/JSON, as they appear in the UI. We then have to parse these into a dictionary form so they are in some way usable. This introduces new challenges and constraints.

A better solution: “constructed inventory”

So rather than continuing down a sub-optimal route, we’ve taken stock of the options (there were many and they got Continue reading

Ansible Automation Platform 2.3 Configuration as Code Improvements

On November 29, we launched Red Hat Ansible Automation Platform 2.3, which included new and exciting features including improvements for Configuration as Code (CaC). Ansible Automation Platform 2.3 also includes improvements to automation controller as well as the introduction of Ansible validated content. This blog post will walk you through what CaC is and the benefits it can bring to your organization, including a UI and API walkthrough of automation controller and how to take a full Configuration as Code approach to your automation infrastructure.  

What is Configuration as Code (CaC) in Ansible Automation Platform?

CaC is a term generally referring to the separation of configuration settings from the actual code. The ideal being you can store that configuration data in source control, and easily run and tweak it to match different environments.

In Ansible Automation Platform terms, we can use the features within the automation controller in combination with CaC to provide a more flexible, richer experience. Essentially we’ve added ‘Prompt on Launch’ to everything within a job template, many of which will also trickle down into workflows.

‘Prompt on launch’ is our Ansible Automation Platform way of saying ‘this is the Continue reading

AAP 2.3 Introducing Remote Execution Mesh Nodes for Openshift

Last year Ansible Automation Platform (AAP) 2 introduced major changes around the mechanics on how automation is run. The main focus was to enhance the foundational pieces of the platform while providing flexibility and simplicity for automators to automate at enterprise scale. One of those foundational pieces introduced was automation mesh. 

Automation mesh provides a simple, flexible and reliable way to scale automation of large inventories across diverse network topologies, platforms and teams. It was important to evolve how the platform was developed, managed, operated to meet business demands and needs, for the large majority of customers.

Pre 2.3 Automation Mesh in OCP

Prior to AAP 2.3, the automation mesh was mostly a VM deployment base option and feature. I’ve tried to highlight the main differences between platform choices in this diagram:

We are now starting to level up the feature parity, and this brings remote mesh execution nodes to non-VM supported deployments. Before we look more at the new feature, let’s look at the options that were available before:

For VM based deployments, the automation mesh introduced horizontal scaling, the ability to scale your automation needs out, whether locally or globally. We did this by Continue reading

When localhost isn’t what it seems in Red Hat Ansible Automation Platform 2

With Red Hat Ansible Automation Platform 2  and the advent of automation execution environments, some behaviors are now different for. This blog explains the use case around using localhost and options for sharing data and persistent data storage, for VM-based Ansible Automation Platform 2  deployments.

With Ansible Automation Platform 2  and its containerised execution environments, the concept of localhost has altered. Before Ansible Automation Platform 2, you could run a job against localhost, which translated into running on the underlying tower host. You could use this to store data and persistent artifacts, although this was not always a good idea or best practice.

Now with Ansible Automation Platform 2, localhost means you’re running inside a container, which is ephemeral in nature. This means we must do things differently to achieve the same goal. If you consider this a backwards move, think again. In fact, localhost is now no longer tied to a particular host, and with portable execution environments, this means it can run anywhere, with the right environment and software prerequisites already embedded into the execution environment container.

So, if we now have a temporal runtime container and we want to use existing data or persistent data, Continue reading