Inside Ansible Automation Platform’s Automation Services Catalog

Automation services catalog blog

Red Hat Ansible Automation Platform 2.2 introduces a technical preview of automation services catalog. 

Automation services catalog was first developed in the cloud at console.redhat.com, with capabilities for fast, agile development and feature release. Over time, Red Hat continually adapted features  to meet customer requirements and incorporate their feedback. As customers became more familiar with the benefits, they’ve since requested the ability to access these catalog components within their firewalled infrastructure with direct access to the Ansible clusters and their corporate identity services. We continue to listen and are providing a private version of automation services catalog, installed by the platform installer alongside automation controller and private automation hub.

 

Products, Portfolios and Platforms

As far as catalogs go, there is a fairly standard pattern to follow. Here is the first glimpse of the user interface.

This image shows what are known as “products”. Products reside within “portfolios,” which allow the administrator to group products into sharable, access controlled folders. Products are simply references to a job template or workflow. 

What I really like about having this new level of abstraction is that I can reference the same job template in a product multiple times. A good example of this is where I have created a job template that provisions a virtual machine. The job template takes inputs for CPUs, memory and storage as you would expect. As we extend automation to end users in the automation services catalog, it makes sense to control what the users can choose, otherwise every virtual machine requested on this job template is likely to have 20 CPUs and 20 GB of memory. The product abstraction allows the administrator to create three separate product instances: small, medium, and large. The administrator can then set default read-only values for the CPUs, memory and storage for each product instance. So the small is 1 CPU and 1 GB of memory, the medium is 2 CPU and 2 GB of memory and so on (see Illustration 1). The survey editor within automation services catalog allows for setting default values, hiding survey questions, or setting questions as visible but read-only. Hiding questions that exist in the job template is useful when presenting the job template as a product to less Ansible savvy users.

Screen Shot 2022-06-01 at 2.59.55 PM

 Illustration 1 – Mapping Products to Job templates

 

Multi-Level Approval

Other catalogs tend to throw in infinite code possibilities to this feature, but automation services catalog provides codeless, multi-level approval. As an approval administrator, you can create multiple levels of approvals pointing to groups coming from your corporate authentication directory. 

As an example, the small, medium and large product instances shown earlier can be arranged so that the large product offering requires approval by your datacenter administrators and finance team for budgetary control. The medium may only require approval by the project administrator and the small requires no approval at all. 

The large product offering, when ordered by an end user, will initiate an approval request for  the datacenter administrators, which will then be issued to finance to approve the order. If anyone in the datacenter group denies the request, finance will never receive the notification to review the order. Illustration 2 shows how approvals look for individual products as well as an entire portfolio.

Screen Shot 2022-06-01 at 3.03.44 PM

 Illustration 2

Approvers in automation services catalog get notifications either in the application itself, or via their registered email address in the corporate identity provider. Approvers can enter the automation services catalog UI and either approve, deny, or comment on a request. Commenting allows for interaction with other approvers in the same chain, whether checking on other requirements, confirming the scope of the requestor reviewing the full transcript history.

 

Easy Administration

Automation services catalog also includes some easy administrative functions, such as copying a product or an entire portfolio. This is beneficial when you are creating multiple portfolios of the same or similar product content. You can create it once, beautify all the products and then copy the portfolio many times, making small edits each time rather than recreating the entire portfolio.

Beautification is all about making the products look attractive for end users. The job templates and workflows in automation controller have limited meta data, so you can extend the name, description and add a product icon with automation services catalog. The following screenshot shows the order queue for a user, and how the products have their own icons and names.

In addition to beautification, automation services catalog has limited rebranding possibilities in technical preview so you can change the login splash screens and the automation services product images and text. This means you can brand the automation services catalog with your company logos, which is great for service providers.

 

Summary

If you wish to reduce friction in your Ansible team, expand automation to a broader user base or enable developers to self-serve. Automation services catalog extends your automation to the end user safely by providing out of the box, codeless, and multi level approval and portfolio sharing. Automation services catalog is in technical preview for Ansible Automation Platform 2.2. 

Originally posted on Ansible Blog
Author:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *