Red Hat Ansible Automation Platform introduces automation services catalog, a new hosted service for Red Hat Ansible customers to extend their automation in a controlled way to the various end users who need it. This is a deep dive into the capabilities and features of the offering.
Users
The automation services catalog is designed to be a familiar experience, providing an easy and intuitive user interface for ordering products (automation resources).
Products to Order
The idea is that those using the automation services catalog may not know that what they are ordering is actually Ansible Automation. For example, a product could be a business function, like ordering a new OpenShift project or onboarding a user to a new platform.
Ordering a product will present the user with options to facilitate the order. This could be provisioning the datacenter or applying permissions for a Kubernetes project. Upon submitting the order, the user can see the progress in their order queue. Users can search for past orders and see those currently in progress indicated by statuses including: Order, Failed, Approval Pending and Completed. Orders that are pending approval can be compared with ordering a product from a website and seeing the delivery information. Users can see who needs to approve the order and any notes or status on the approval.
Users Order Queue
During the progress of an order, the lifecycle link of the automation job is recorded, allowing for deeper inspection of the automation as long as the user has access to theplatform running the job. Along with the lifecycle link, the user has access to the progress messages of the order allowing for easy debugging of any failures in the catalog infrastructure supporting the execution of the order.
Administrators
The administrators who manage the automation services catalog often manage Red Hat Ansible Automation Platform as well, namely the Ansible Tower component. This person is compelled to publish more automation into the automation services catalog as more users doing self service will lessen the burden on their role to support and execute automation.
The administrators will connect their Ansible Tower servers to the automation services catalog. Multiple job templates or workflows can be added as products to one or more portfolios. This means you can have one job template shown in the catalog many times, which allows for fixing the parameters or extra variables driving the automation for each product. For example, a job template provisions virtual machines and allows for a wide range of CPUs and memory to be entered when executed as a job within Ansible Tower. When this job template is represented as a product within the automation services catalog, the administrator can limit the values for the extra variables or parameters. This means you can have a small, medium and large offering for the one job template, making it easier for users to consume and provide governance for medium and large offerings while allowing the small offering to go through as auto approval.
Product Extra Variables and Parameters
Products are arranged into portfolios. The portfolios provide a way to group applications and can be shared to specific groups of users defined in cloud.redhat.com. Users can be in projects while administrators or project leads use the automation services catalog to present products to different projects, depending on its needs. An example would be frontend developers getting products for creating user interfaces and database developers getting testing tools and database optimization applications.
Sharing Portfolios to User Groups
Previously mentioned governance can be applied in a number of different ways, as product and portfolios can both have single or multiple sets of approval processes. This results in approval supporting single or multiple levels of approval. Another way to apply approval is to set it on platform inventories. The use case for this would be where the administrator wishes that any product ordered that’s irrelevant to its portfolio will require approval, such as if the inventory is targeting production systems you would wish for production support to approve the request. This allows the administrator to delegate the creation and management of products in chosen portfolios and back those product workflows with governance.
There are also some simple functional features that make the automation services catalog easy to use for the administrator. They can create a master portfolio, set up the desired look for all of the products and then copy either products or entire portfolios over and over. An undo feature also allows deletions within the automation services catalog to return to the original state. Products can also have extended details such as a long description, documentation and support URLs.
Finally something that was touched on earlier was the ability to lock down the values that drive additional automation variables and parameters. This is known as survey editing; automation services catalog takes the surveys that exist within the Ansible Tower server for the job templates and workflows, allowing the administrator to set defaults, hide or disable questions, and set validation rules on the values to the questions. These survey features help enable the administrator to simplify the way automation is presented to the users, which helps limit incorrect orders, over provisions and general mistakes in user input.
Approvers
Automation services catalog set out to help ensure that the approver user could interact with the application without logging into it. This means that as an approver, you are notified via email. The email contains both a login URL and a special URL that allows the administrator to process the request from a normal browser. The idea is that an approver may be on their smartphone out at lunch, but they can still easily click to approve, deny or update the transcript with a comment without needing a special app or to log into automation services catalog hosted service. Comments can be left for other approvers to see in the transcript, such as, “can we check we have the resources in the datacenter for this request” or “this request is on hold”.
The approvers are notified by the system because they are in a person’s group that has been specified in an approval process. An approval process can have multiple groups, which means that when a single approval process with multiple groups is used on a product, portfolio or inventory, the groups are all notified simultaneously. However, it does take all groups to approve the request, so if any of the groups deny the approval request, it will be stopped and the user will be notified that they did not get approval. When multiple approval processes are set on a product, portfolio or inventory the processes are executed in an order defined by the administrator. This results in each process notifying its group audience to approve or deny, example being that if production support and finance are required to approve in that order, finance is not notified until production support approves the request, and only then will Finance get their notification.
Summary
Automation services catalog extends customers’ automation to their business users in an intuitive and familiar experience. Unleashing automation comes with business governance to protect production systems in the form of multi-level approval. Finally for the administrator a code-less setup. If you’d like to speak with anyone regarding automation services catalog or have any questions about Ansible, join our ask the experts – here to help webinar series running from now through the end of June. And as always, if you need to speak with someone immediately, please reach out or contact your Red Hat account team.
Originally posted on Ansible Blog
Author: