Using self-service automation portal
Use self-service automation portal
Abstract
Preface Copy linkLink copied to clipboard!
Thank you for your interest in Red Hat Ansible Automation Platform. Ansible Automation Platform is a commercial offering that helps teams manage complex multi-tier deployments by adding control, knowledge, and delegation to Ansible-powered environments.
This guide describes how to add templates to your self-service automation portal instance, and how to launch them to run automation jobs. It also describes how to configure role-based access control (RBAC) so that you can restrict the teams and users who can run the jobs.
This document has been updated to include information for the latest release of Ansible Automation Platform.
Providing feedback on Red Hat documentation Copy linkLink copied to clipboard!
If you have a suggestion to improve this documentation, or find an error, you can contact technical support at https://access.redhat.com to open a request.
Chapter 1. Overview Copy linkLink copied to clipboard!
You can launch templates from self-service automation portal to execute job templates from your existing Ansible Automation Platform setup.
- Auto-generated self-service templates are automatically synced from the job templates in Ansible Automation Platform to the self-service automation portal. The forms for the auto-generated templates are identical to the forms for the job templates.
- You can import custom self-service templates from a Git repository. A configuration file links each custom template to a specific job template in Ansible Automation Platform and contains the forms that users must complete.
You can associate multiple custom self-service templates with a single Ansible Automation Platform job template. You can use role-based access control (RBAC) to assign different custom self-service templates for users with different levels of automation experience. For example, you can design a simplified template with a narrow scope for configuration for new users, and a more detailed template for automation experts.
Chapter 2. Logging in to self-service automation portal Copy linkLink copied to clipboard!
Learn how to access and authenticate to the self-service automation portal using your Ansible Automation Platform credentials.
2.1. Signing in to self-service automation portal Copy linkLink copied to clipboard!
Log in to the deployed self-service automation portal using your existing Ansible Automation Platform credentials. The portal uses these credentials for authentication.
Prerequisites
- You have configured an OAuth application in Ansible Automation Platform for self-service automation portal.
- You have configured a user account in Ansible Automation Platform.
Procedure
In a browser, navigate to the URL for self-service automation portal to open the sign-in page.
- Click .
The sign-in page for Ansible Automation Platform appears:
- Enter your Ansible Automation Platform credentials and click Log in.
- The self-service automation portal web console opens.
Troubleshooting
If you are using custom or self-signed SSL certificates and when attempting to log in to self-service automation portal, it displays the error:
Login failed; caused by Error: Failed to send POST request: fetch failed
This error indicates that self-service automation portal cannot verify the SSL certificate from your Ansible Automation Platform instance.
To resolve this issue, configure self-service automation portal to trust your custom CA certificate. For more information, see Section 2.2, “Configuring custom SSL certificates for self-service automation portal”.
While you can disable SSL validation by setting checkSSL: false in the Helm chart configuration, this approach is not recommended for production environments as it reduces security. Instead, configure self-service automation portal to trust your custom CA certificate.
2.2. Configuring custom SSL certificates for self-service automation portal Copy linkLink copied to clipboard!
If your Ansible Automation Platform instance uses custom or self-signed SSL certificates, you must configure self-service automation portal to trust those certificates. Without this configuration, authentication between self-service automation portal and Ansible Automation Platform fails with SSL verification errors.
Prerequisites
- You have administrator access to your OpenShift Container Platform cluster.
- You have the custom Certificate Authority (CA) certificate file used by your Ansible Automation Platform instance.
- self-service automation portal is installed in your OpenShift Container Platform cluster.
Procedure
Obtain the CA certificate file from your Ansible Automation Platform instance.
If you do not have the CA certificate file, you can extract it from your Ansible Automation Platform server:
openssl s_client -showcerts -connect <aap-hostname>:443 </dev/null 2>/dev/null | openssl x509 -outform PEM > aap-ca-cert.pemReplace
<aap-hostname>with your Ansible Automation Platform hostname.- Log in to your OpenShift Container Platform cluster with administrator privileges.
Create a ConfigMap containing your custom CA certificate:
oc create configmap custom-ca-bundle \ --from-file=ca-bundle.crt=aap-ca-cert.pem \ -n <namespace>Replace
<namespace>with the namespace where self-service automation portal is installed.Update your self-service automation portal Helm chart values to mount the custom CA certificate:
upstream: backstage: extraEnvVarsSecrets: - custom-ca-bundle extraVolumes: - name: custom-ca configMap: name: custom-ca-bundle extraVolumeMounts: - name: custom-ca mountPath: /etc/pki/ca-trust/source/anchors/ readOnly: trueApply the updated configuration by upgrading the self-service automation portal Helm chart:
helm upgrade <release-name> <chart-name> \ -f values.yaml \ -n <namespace>Replace
<release-name>with your Helm release name and<chart-name>with the self-service automation portal chart name.- Wait for the self-service automation portal pods to restart with the new configuration.
Verification
Verify that the self-service automation portal pods are running:
oc get pods -n <namespace>All self-service automation portal pods should show a status of
Running.Attempt to sign in to self-service automation portal using your Ansible Automation Platform credentials.
If the SSL certificate configuration is correct, you can authenticate successfully without SSL verification errors.
Check the self-service automation portal logs for SSL-related errors:
oc logs -n <namespace> <pod-name> | grep -i sslIf you see no SSL verification errors, the custom CA certificate is trusted correctly.
Troubleshooting
If you continue to experience SSL verification errors after following this procedure:
- Verify that the CA certificate file contains the complete certificate chain.
- Ensure that the certificate file is in PEM format.
- Confirm that the Ansible Automation Platform hostname in your configuration matches the hostname in the SSL certificate.
-
Check that the
checkSSLparameter in your Helm values is set totrue(the default). Setting it tofalsedisables SSL verification entirely, which is not recommended for production environments.
2.3. Viewing templates Copy linkLink copied to clipboard!
View your accessible automation templates, displayed as tiles, on the Templates landing page of the self-service automation portal console.
Prerequisites
- You have signed in to self-service automation portal.
Procedure
- In a browser, sign in to self-service automation portal.
In the navigation pane, select Templates to open a landing page where tiles are displayed, representing the templates that you have access to.
2.4. Synchronizing auto-generated templates Copy linkLink copied to clipboard!
The auto-generated self-service templates are synchronized from the job templates in Ansible Automation Platform to self-service automation portal. You can manually trigger a sync from the Templates page.
This synchronization fetches updates for auto-generated self-service templates only.
Procedure
- In a browser, sign in to self-service automation portal.
In the navigation pane, select Templates to display the templates that you have access to.
- Select Sync now to launch a synchronization.
2.5. Viewing task run history Copy linkLink copied to clipboard!
You can view a list of all the tasks that have been run from self-service automation portal. You can manually trigger a sync from the Templates page.
Procedure
- In a browser, sign in to self-service automation portal.
In the navigation pane, select History.
The Task list page displays the tasks that have been run.
Troubleshooting
If the Task List page does not display the tasks that have been run, contact your administrator to ensure that the scaffolder.task.read permission is selected in RBAC for your account.
Chapter 3. Working with templates Copy linkLink copied to clipboard!
Understand how to deploy and manage both auto-generated and customized templates within the self-service automation portal to run your automation jobs.
3.1. Customized self-service templates Copy linkLink copied to clipboard!
Custom self-service templates are stored as YAML files in repositories in GitHub or Gitlab. When a user launches a software template from self-service automation portal, they must fill in a form with the values needed to run the associated job template in Ansible Automation Platform.
The custom self-service template YAML file must have a token: section that includes a ui:field: key for the authentication token for Ansible Automation Platform. This generates a field for the token in the form that appears when the user launches the template in self-service automation portal. The user enters the token: it is used to authenticate job template execution in Ansible Automation Platform.
The following example shows the token: section in a template. For security reasons, set the value of token.ui:backstage.review.show to false to ensure that the token is not visible to the user.
spec:
...
parameters:
...
properties:
token:
title: Token
type: string
description: Oauth2 token
ui:field: AAPTokenField
ui:widget: hidden
ui:backstage:
review:
show: false
Setting the ui:widget: hidden field hides the Red Hat Ansible Automation Platform token input in the form.
3.2. Understanding auto-generated templates Copy linkLink copied to clipboard!
self-service automation portal automatically generates templates from Ansible Automation Platform Job Templates. Each Ansible Automation Platform Job Template with the appropriate configuration becomes a template that users can execute from self-service automation portal.
Templates in self-service automation portal use Backstage Software Templates as the underlying technology. For details on supported usage, see the self-service automation portal support policy.
Auto-generated templates include:
- Form fields generated from Ansible Automation Platform Job Template Surveys and "Prompt on Launch" options.
- Metadata (name, description, labels) mapped from Ansible Automation Platform Job Template properties.
-
A single step that launches the Ansible Automation Platform Job Template using the
rhaap:launch-job-templateaction. - Output that displays the job execution results to the user.
Users only see and execute templates for Ansible Automation Platform Job Templates they have Job Template Execute permission in Ansible Automation Platform.
3.2.1. What users see Copy linkLink copied to clipboard!
Auto-generated templates appear in the template catalog alongside custom templates. Users browse or search the catalog and select a template to run.
When a user opens an auto-generated template, self-service automation portal checks the Ansible Automation Platform Job Template for Prompt on Launch options and Survey questions. If the Job Template has Prompt on Launch options or Survey questions, self-service automation portal displays a form. Users select Ansible Automation Platform resources by name (such as Inventories or Credentials) and answer survey questions (such as application name or environment). self-service automation portal handles authentication automatically, so credentials are not visible on the form. If the Job Template has no Prompt on Launch options or Survey questions, the Job Template starts running automatically without displaying a form.
After the user submits the form or execution starts automatically, self-service automation portal launches the Ansible Automation Platform Job Template and displays an output page. The output page shows the job ID, job status, and optional links such as a direct link to the job in Ansible Automation Platform.
Users do not need to understand YAML or the template structure. The form collects the required input, and the output page displays the results.
3.2.2. Auto-generated template example Copy linkLink copied to clipboard!
The following example shows a template that self-service automation portal auto-generates from an existing Ansible Automation Platform Job Template. Every field in the generated YAML maps directly to an Ansible Automation Platform artifact:
-
The Ansible Automation Platform Job Template name and description become
metadatafields. -
Each Prompt on Launch option becomes an
AAPResourcePickerfield. - Each Ansible Automation Platform Survey question becomes a standard form field.
-
The
stepssection launches the original Ansible Automation Platform Job Template using therhaap:launch-job-templateaction.
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
# Namespace is hardcoded to "default"
namespace: default
# AAP artifact: Job Template name → lowercase with hyphens
name: deploy-application
# AAP artifact: Job Template name → title (copied directly)
title: Deploy Application
# AAP artifact: Job Template description → description (copied directly)
description: Deploy application to target environment
# AAP artifact: Job Template labels → tags (lowercase)
tags:
- automation
- aap
# AAP artifact: Job Template URL → annotations
annotations:
backstage.io/techdocs-ref: url:https://aap.example.com/#/templates/job_template/42
backstage.io/source-location: url:https://aap.example.com/#/templates/job_template/42
spec:
type: service
parameters:
- title: "Please enter the following details"
required:
- token
- inventory
- app_name
properties:
# Always present: OAuth token for AAP authentication (hidden from user)
token:
title: Token
type: string
description: Oauth2 token
ui:field: AAPTokenField
ui:widget: hidden
ui:backstage:
review:
show: false
ui:options:
disabled: true
hidden: true
# AAP artifact: "Prompt on Launch" → Inventory (users select by name; self-service portal resolves to AAP ID)
inventory:
title: Inventory
description: Please enter the inventory you want to use the services on
resource: inventories
ui:field: AAPResourcePicker
default: Production Servers
# AAP artifact: Survey question → "Application Name" (variable, title, type, default from survey spec)
app_name:
title: Application Name
description: Name of the application to deploy
type: string
default: my-app
steps:
- id: launch-job
# AAP artifact: Job Template name used as the step name
name: Deploy Application
action: rhaap:launch-job-template
input:
token: ${{ parameters.token }}
values:
# AAP artifact: Job Template name identifies which template to launch
template: Deploy Application
# "Prompt on Launch" values passed as launch parameters
inventory: ${{ parameters.inventory }}
# Survey answers passed as extra variables to AAP
extraVariables:
app_name: ${{ parameters.app_name }}
output:
text:
- title: Deploy Application template executed successfully
content: |
**Job ID:** ${{ steps['launch-job'].output.data.id }}
**Job status:** ${{ steps['launch-job'].output.data.status }}
The following table maps each generated field to its Ansible Automation Platform source:
| Ansible Automation Platform source | Ansible Automation Platform value | Generated field | Transformation |
|---|---|---|---|
| N/A |
|
|
Hardcoded to |
| Job Template → Name | Deploy Application |
| Lowercase with hyphens. |
| Job Template → Name | Deploy Application |
| Copied directly. |
| Job Template → Description | Deploy application to target environment |
| Copied directly. |
| Job Template → Labels |
|
| Lowercase, special characters replaced with hyphens. |
| Always present | OAuth2 token |
| Auto-populated and hidden from user. |
| Prompt on Launch → Inventory | Production Servers |
|
|
| Survey → Question 1 | app_name (text, required, default: "my-app") |
| Variable, title, type, and default copied from Survey spec. |
| Job Template → Name | Deploy Application |
| Identifies which Ansible Automation Platform Job Template to launch. |
| Prompt on Launch value |
|
| Name resolved to Ansible Automation Platform ID at launch. |
| Survey answers |
|
|
Passed as |
3.2.3. How templates are generated Copy linkLink copied to clipboard!
When synchronization runs, self-service automation portal reads Ansible Automation Platform Job Template configurations and generates corresponding templates. self-service automation portal maps Ansible Automation Platform Job Template properties to template fields as follows.
3.2.3.1. Metadata mapping Copy linkLink copied to clipboard!
The following table shows how Ansible Automation Platform Job Template properties are mapped to template metadata fields:
| Ansible Automation Platform Job Template property | Generated template field | Transformation |
|---|---|---|
| Name |
| Converted to lowercase with hyphens |
| Name |
| Copied directly |
| Description |
| Copied directly |
| Labels |
| Converted to lowercase, special characters replaced with hyphens |
| N/A |
|
Hardcoded to |
3.2.3.2. Parameter mapping Copy linkLink copied to clipboard!
The following table shows how Ansible Automation Platform Job Template sources are mapped to template parameters:
| Ansible Automation Platform Job Template source | Generated template parameter type |
|---|---|
| Survey questions |
Standard form fields ( |
| "Prompt on Launch" options |
|
3.2.3.3. Field order Copy linkLink copied to clipboard!
self-service automation portal generates form fields from two sources in the Ansible Automation Platform Job Template configuration. Fields appear in the following order:
- OAuth token (hidden): Auto-populated with the user’s authentication token. This field is always present and always hidden.
-
"Prompt on Launch" fields: Each enabled "Prompt on Launch" option becomes an
AAPResourcePickerfield. Users select Ansible Automation Platform resources by name (Inventories, Credentials, Execution Environments). self-service automation portal resolves names to Ansible Automation Platform internal IDs at launch time. -
Survey questions: Each survey question becomes a form field with the matching input type (
text,dropdown,password,textarea,integer,float,multiplechoice,multiselect).
3.2.3.4. Defaults and required fields Copy linkLink copied to clipboard!
- Survey question defaults and required/optional settings are preserved from the Ansible Automation Platform Job Template Survey.
- "Prompt on Launch" fields use the current Ansible Automation Platform Job Template settings for defaults and required/optional status.
- Ansible Automation Platform resource picker fields display resource names, not internal IDs.
3.3. Adding a template to self-service automation portal Copy linkLink copied to clipboard!
You can add a custom self-service template to the Templates view of your self-service automation portal instance. Custom self-service templates are stored in git repositories. self-service automation portal supports GitLab and GitHub Source Control Management (SCM).
Names for custom self-service templates must be unique. Custom self-service templates must have a different name to auto-generated job templates and also to other custom self-service templates.
Prerequisites
- You have created repositories in your Git SCM for the templates that you want to use.
-
In the git repository for your custom templates, ensure that the
metadata.namefield is unique and does not match an existing auto-generated template or another custom self-service template. For example, append*-customto the value of themetadata.namekey.
metadata:
name: provision-database-custom
- You must be logged in to self-service automation portal as an Ansible Automation Platform platform administrator.
Procedure
- In a browser, navigate to your self-service automation portal instance and sign in with your Ansible Automation Platform credentials.
- Navigate to the Templates Page.
- Click .
- Enter a valid Git SCM URL for the template that you want to add.
- Click to fetch the template.
- After the template has been fetched, review the list of what will be imported and added to the catalog.
- Click .
Verification
After the import is complete, return to the Templates page to view the newly created template. You can now launch your template.
3.4. Launching a template Copy linkLink copied to clipboard!
This procedure describes how to launch a template from a tile in the Templates view of your self-service automation portal instance.
Prerequisites
- You have configured RBAC in Ansible Automation Platform for templates that are associated with Ansible Automation Platform job templates.
Procedure
- In a browser, navigate to your self-service automation portal instance and sign in with your Ansible Automation Platform credentials.
- Navigate to the Templates page. The templates you have set up are displayed as tiles on the page.
In the template that you want to launch, click Start.
A description of the template is displayed.
- Click Launch to begin configuring the parameters for running the template.
- Fill out the required fields.
- Click Next.
- Review the entered information.
- Click Create to launch the template.
- The progress for the template execution is displayed.
Chapter 4. Working with custom self-service template permissions Copy linkLink copied to clipboard!
Custom self-service templates that you set up in self-service automation portal use a different set of RBAC rules than the RBAC rules for auto-generated self-service templates that are synchronized from Ansible Automation Platform.
- Auto-generated self-service templates: The RBAC settings for these templates are synchronized from Ansible Automation Platform.
- Custom self-service templates: You must set up RBAC for these templates in self-service automation portal.
4.1. Setting up RBAC for custom self-service templates Copy linkLink copied to clipboard!
By default, Ansible Automation Platform administrators can define self-service automation portal RBAC roles.
This procedure describes how to create a role in self-service automation portal that allows only a selected team to view and execute particular custom self-service templates.
Custom self-service templates in self-service automation portal are associated with job templates in Ansible Automation Platform. This association is set in the steps.actions section of the YAML file for the custom self-service template.
If you assign permissions to a particular team to launch a custom self-service template from self-service automation portal, then you must make sure that that team has permission to run the associated job templates in Ansible Automation Platform.
Prerequisites
-
You have created a user, for example
example-user. -
You have added this user as a member of a team, for example
example-team.
Procedure
- In a browser, log in to your self-service automation portal instance as an Ansible Automation Platform user with Ansible Automation Platform administrator privileges.
- In the navigation panel, select → .
In the RBAC view, click Create.
The Create Role view appears.
- Enter a name for the role.
In the Users and Groups section, select the Ansible Automation Platform teams and users to assign to this role.
NoteThe Members column displays the total count of users in each team, including both regular team members and administrators.
- In the Add Permission policies section, select the plug-ins that you want to enable for the role.
- Select Permission in the list of plug-ins to configure the fine-grained permission policies for the role.
- Click Next.
- Review the settings that you have selected for the role.
- Click Create to create the role.
Additional resources
4.2. Verifying RBAC Copy linkLink copied to clipboard!
This procedure describes how to verify that the role you set up is working correctly.
Procedure
Verify that users with permissions can use a template:
- Log in to self-service automation portal as a user who is a member of a team that has been enabled to use a role.
- Verify that RBAC is applied and that the user can use the templates that you enabled for the role.
- Log out of self-service automation portal.
Verify that users without permissions can not see or use a template:
- Log in to self-service automation portal as a user who is not a member of the new team that has been enabled to use the role.
- Verify that RBAC is applied and that the user cannot use the templates that you enabled for the role.
- Log out of self-service automation portal.
4.3. Deregistering custom self-service templates Copy linkLink copied to clipboard!
You can deregister custom self-service templates. Deregistering templates deletes them from the Templates view in the self-service automation portal console.
Procedure
- In a browser, log in to self-service automation portal as a user with administrative privileges.
- Select Templates to display the self-service templates.
For each custom self-service template that you want to delete, execute the following steps:
- Click a custom self-service template to open the Template detail view. The navigation bar contains the Unregister Template option.
Click Unregister Template.
- In the dialog, confirm that you want to deregister the template.
- Click Delete Entity to unregister the template.
Verification
In a browser, navigate to the Templates view for your self-service automation portal instance. Verify that the custom self-service templates that you deregistered have been deleted.
Chapter 5. Using custom actions and UI components in Backstage Software Templates Copy linkLink copied to clipboard!
The self-service automation portal is built on a Red Hat Developer Hub base image. It uses Backstage Software Templates, which are YAML-based workflow definitions that provide user forms to execute automation tasks in Ansible Automation Platform.
5.1. Overview Copy linkLink copied to clipboard!
Learn how to use the custom actions, filters, and UI components provided by the Ansible Backstage Plugins to create and manage custom software templates for the self-service automation portal.
Red Hat does not support the use of the Red Hat Developer Hub image for standalone purposes outside the scope of the Ansible Automation Platform self-service automation portal functionality. Refer to the official support policy for details.
5.2. Ansible backstage plugins Copy linkLink copied to clipboard!
The portal’s capabilities are delivered through Ansible Backstage Plugins that extend Red Hat Developer Hub functionality; the base Red Hat Developer Hub image is not customized. These plugins provide additional Backstage actions and filters that you use to create custom software templates.
| Plugin | Functionality |
|---|---|
| auth-backend-module-rhaap-provider | Provides OAuth 2.0 authentication with Ansible Automation Platform. |
| catalog-backend-module-rhaap | Synchronizes Ansible Automation Platform job templates as Backstage Software Templates. |
| scaffolder-backend-module-backstage-rhaap |
Provides the |
| backstage-rhaap-common | Contains shared libraries and utilities for Ansible Automation Platform integration. |
| self-service | Provides the user interface for all listed functionality. |
5.3. Custom backstage actions Copy linkLink copied to clipboard!
The following actions enable you to manage Ansible Automation Platform resources within a software template workflow.
5.3.1. rhaap:create-project Copy linkLink copied to clipboard!
Create an Ansible Automation Platform project that links to a source control repository containing Ansible content.
Input parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
|
| string | Yes | OAuth2 token for Ansible Automation Platform authentication. |
|
| boolean | No |
If |
|
| object | Yes | The project configuration object. See the "values" Object Structure table. |
“values” Object Structure
| Field | Type | Required | Description |
|---|---|---|---|
|
| string | Yes | Name of the project. |
|
| string | No | Description of the project. |
|
| object | Yes |
Organization object with |
|
| object | No |
Credential object with |
|
| string | Yes | Source control URL (for example, GitHub/GitLab repository URL). |
|
| string | No | Source control branch, tag, or commit. |
|
| boolean | No |
If |
Output parameters
| Parameter | Type | Description |
|---|---|---|
|
| object | Created project details. |
|
| number | Project ID in Ansible Automation Platform (AAP). |
|
| string | Project name. |
|
| string | Project description. |
|
| string | Ansible Automation Platform URL for the project. |
Example
steps:
- id: create-aap-project
name: Create AAP Project
action: rhaap:create-project
input:
token: ${{ parameters.AAP_TOKEN }}
deleteIfExist: true
values:
projectName: ${{ parameters.projectName }}
organization: ${{ parameters.organization }}
scmUrl: https://github.com/my-org/ansible-playbooks
scmBranch: main
scmUpdateOnLaunch: true
credentials: GitHub Token
5.3.2. rhaap:create-execution-environment Copy linkLink copied to clipboard!
Create an execution environment in Ansible Automation Platform that defines the container image used to run Ansible jobs.
Input parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
|
| string | Yes | OAuth2 token for Ansible Automation Platform authentication. |
|
| boolean | No |
If |
|
| object | Yes | The execution environment configuration object. |
“values” Object Structure
| Field | Type | Required | Description |
|---|---|---|---|
|
| string | Yes | Name of the execution environment. |
|
| string | No | Description of the execution environment. |
|
| object | Yes |
Organization object with required |
|
| string | Yes |
Full image location, including registry, image name, and tag (for example, |
|
| string | No |
Image pull policy: |
Output parameters
| Parameter | Type | Description |
|---|---|---|
|
| object | Created execution environment details. |
|
| number | Execution environment ID. |
|
| string | Execution environment name. |
|
| string | Execution environment description. |
|
| string | Ansible Automation Platform (AAP) URL for the execution environment. |
Example
steps:
- id: create-ee
name: Create Execution Environment
action: rhaap:create-execution-environment
input:
token: ${{ parameters.AAP_TOKEN }}
deleteIfExist: false
values:
environmentName: Custom EE
environmentDescription: Execution environment with custom collections
organization: ${{ parameters.organization }}
image: quay.io/ansible/creator-ee:v0.16.0
pull: missing
5.3.3. rhaap:create-job-template Copy linkLink copied to clipboard!
Create a job template in Ansible Automation Platform that defines a reusable configuration for running Ansible playbooks.
Input parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
|
| string | Yes | OAuth2 token for Ansible Automation Platform authentication. |
|
| boolean | No |
If |
|
| object | Yes | The job template configuration object. |
“values” Object Structure
| Field | Type | Required | Description |
|---|---|---|---|
|
| string | Yes | Name of the job template. |
|
| string | No | Description of the job template. |
|
| object | Yes |
Project object with required |
|
| object | No |
Organization object with |
|
| object | Yes |
Inventory object with required |
|
| string | Yes | Path to the playbook file to execute. |
|
| string | No | Description of the job template. |
|
| string | No |
Source control type (for example, |
|
| object | No |
Execution environment object with required |
|
| object | No | Extra variables to pass to the playbook (key-value pairs). |
Output parameters
| Parameter | Type | Description |
|---|---|---|
|
| object | Created job template details. |
|
| number | Job template ID. |
|
| string | Job template name. |
|
| string | Job template description. |
|
| string | Ansible Automation Platform (AAP) URL for the job template. |
Example
steps:
- id: create-job-template
name: Create Job Template
action: rhaap:create-job-template
input:
token: ${{ parameters.AAP_TOKEN }}
deleteIfExist: true
values:
templateName: Deploy Application
templateDescription: Deploys the application to production
project: ${{ steps['create-aap-project'].output.project }}
organization: ${{ parameters.organization }}
jobInventory: ${{ parameters.jobInventory }}
playbook: deploy.yml
executionEnvironment: ${{ steps['create-ee'].output.executionEnvironment }}
extraVariables:
app_version: 1.0.0
environment: production
5.3.4. rhaap:launch-job-template Copy linkLink copied to clipboard!
Launch an existing job template in Ansible Automation Platform.
Input parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
|
| string | Yes | OAuth2 token for Ansible Automation Platform authentication. |
|
| object | Yes | The job launch configuration object. |
“values” Object Structure
| Field | Type | Required | Description |
|---|---|---|---|
|
| string | Yes | Job template name to launch. |
|
| object | No |
Override inventory with |
|
| array | No | Array of credential objects to use. |
|
| object | No | Extra variables to pass to the job (key-value pairs). |
|
| string | No | Host pattern to constrain which hosts the job runs against. |
|
| string | No |
Job type: |
|
| object | No |
Override execution environment with |
|
| object | No |
Verbosity level object with |
|
| number | No |
Number of parallel processes (default: |
|
| number | No | Divide the job into N slices. |
|
| number | No |
Job timeout in seconds ( |
|
| boolean | No | Enable diff mode to show changes. |
|
| string | No | Comma-separated tags to run only specific tasks. |
|
| string | No | Comma-separated tags to skip specific tasks. |
Output parameters
| Parameter | Type | Description |
|---|---|---|
|
| object | Job execution details. |
|
| number | Job ID. |
|
| string | Job status. |
|
| string | Ansible Automation Platform (AAP) URL for the job. |
Example
steps:
- id: launch-job
name: Launch Job Template
action: rhaap:launch-job-template
input:
token: ${{ parameters.AAP_TOKEN }}
values:
template: Deploy Application
inventory: ${{ parameters.jobInventory }}
credentials: ${{ parameters.credentials }}
extraVariables:
app_version: v1.0.1
deploy_env: production
jobType: run
verbosity: Normal
diffMode: true
timeout: 3600
5.3.5. Example with all backstage actions present Copy linkLink copied to clipboard!
The following example displays how you can use multiple actions together.
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: ansible-complete-setup
title: Complete Ansible Setup
description: Creates an Ansible project, execution environment, job template, and launches it
spec:
owner: platform-team
type: service
parameters:
- title: Project Information
required:
- projectName
- repoUrl
properties:
projectName:
title: Project Name
type: string
description: Name of the Ansible project
repoUrl:
title: Repository URL
type: string
description: Git repository URL containing Ansible content
- title: AAP Configuration
required:
- organization
- jobInventory
- credentials
properties:
organization:
title: Organization
type: string
description: AAP Organization name
default: 1-org
ui:field: hidden # To hide this field in the UI
jobInventory:
title: Inventory name
type: string
description: AAP Inventory name
resource: inventories
ui:field: AAPResourcePicker
default: my-inventory
credentials:
title: Credentials
description: Select SCM credential for Private repositories
resource: credentials
ui:field: AAPResourcePicker
default: my-machine-credential
steps:
# Step 1: Create AAP Project
- id: create-project
name: Create AAP Project
action: rhaap:create-project
input:
token: ${{ parameters.AAP_TOKEN }}
deleteIfExist: true
values:
projectName: ${{ parameters.projectName }}
organization: ${{ parameters.organization }}
scmUrl: ${{ parameters.repoUrl }}
scmBranch: main
scmUpdateOnLaunch: true
# Step 2: Create Execution Environment
- id: create-ee
name: Create Execution Environment
action: rhaap:create-execution-environment
input:
token: ${{ parameters.AAP_TOKEN }}
values:
environmentName: ${{ parameters.projectName }}-ee
organization: ${{ parameters.organization }}
image: quay.io/ansible/creator-ee:latest
pull: missing
# Step 3: Create Job Template
- id: create-template
name: Create Job Template
action: rhaap:create-job-template
input:
token: ${{ parameters.AAP_TOKEN }}
values:
templateName: ${{ parameters.projectName }}-deploy
templateDescription: Deployment job template
project: ${{ steps['create-project'].output.project }}
organization: ${{ parameters.organization }}
jobInventory: ${{ parameters.jobInventory }}
playbook: site.yml
executionEnvironment: ${{ steps['create-ee'].output.executionEnvironment }}
# Step 4: Launch the Job
- id: launch-job
name: Launch Job
action: rhaap:launch-job-template
input:
token: ${{ parameters.AAP_TOKEN }}
values:
template: ${{ parameters.projectName }}-deploy
inventory: ${{ parameters.jobInventory }}
credentials: ${{ parameters.credentials }}
jobType: run
extraVariables:
created_by: backstage
timestamp: ${{ '' | now }}
output:
links:
- title: AAP Project
url: ${{ steps['create-project'].output.project.url }}
- title: Job Template
url: ${{ steps['create-template'].output.template.url }}
- title: Job Execution
url: ${{ steps['launch-job'].output.data.url }}
5.4. Custom UI components and filters Copy linkLink copied to clipboard!
The Ansible Backstage Plugins provide custom UI components that enhance the software template experience by integrating directly with Ansible Automation Platform resource selection and authentication.
5.4.1. AAPTokenField Copy linkLink copied to clipboard!
The AAPTokenField is a secure authentication field used in backstage scaffolder templates. It automatically fetches and stores an Ansible Automation Platform OAuth2 token, which is then available for all rhaap:* actions, enabling seamless authentication.
AAPTokenField Properties
The following table details the field’s properties for use in a template’s properties section.
| Property | Type | Description |
|---|---|---|
|
| string | The label displayed in the UI (for example, "AAP Token"). Defaults to "AAP Token". |
|
| string | A short help text displayed below the input field. |
|
| string |
Must be set to |
|
| boolean |
If |
Authentication flow and token management
All rhaap:* actions require an OAuth2 token for authenticating with Ansible Automation Platform. The field manages the token through the following process:
- Token Source: The token is automatically obtained from the Ansible Automation Platform OAuth2 authentication provider.
-
Storage: The token is stored securely in Backstage secrets or fetched through the
@ansible/backstage-plugin-auth-backend-module-rhaap-provider. -
Usage: The token is passed to each action using the
tokeninput parameter.
When the RHAAP auth provider is used, the token is injected automatically and can be referenced in the workflow steps as shown:
- id: create-project
action: rhaap:create-project
input:
token: ${{ parameters.AAP_TOKEN }}
# ... other inputs
Example
The following example shows how to declare and reference the AAPTokenField within a backstage template. Note that ui:widget: hidden and ui:backstage: review: show: false are used to ensure the token is not exposed in the UI.
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: my-AAP-template
title: Example AAP Template
spec:
parameters:
- title: Authentication
properties:
token:
title: AAP Authentication Token
type: string
description: Oauth2 token
ui:field: AAPTokenField
ui:widget: hidden
ui:backstage:
review:
show: false
steps:
- id: launch-job
name: Launch AAP Job Template
action: rhaap:launch-job-template
input:
token: ${{ parameters.token }}
...
Error and validation handling
All rhaap:* actions include built-in validation and user-friendly error reporting:
- Validation: If the token is missing or invalid, the action throws the error: "`Authorization token not provided`."
- Error Messages: Actions catch API client errors, extracting and surfacing meaningful messages without exposing stack traces.
- Workflow Safety: If a step fails due to authentication, subsequent steps are automatically skipped, ensuring a safe and predictable workflow.
5.4.2. AAPResourcePicker Copy linkLink copied to clipboard!
The AAPResourcePicker is a dynamic field for backstage scaffolder templates. It fetches and displays a list of Ansible Automation Platform resources (such as inventories, organizations, or credentials) directly from the Ansible Automation Platform API, allowing users to select a resource for their automation workflow.
AAPResourcePicker Properties
The following table details the essential properties for configuring the resource picker in a template’s properties section.
| Property | Type | Description |
|---|---|---|
|
| string | The label displayed in the UI (for example, "Inventory"). |
|
| string | A short help text shown below the field. |
|
| string |
Must be set to |
|
| string |
The specific Ansible Automation Platform (AAP) resource type to fetch and display (for example, |
|
| string | The property name used to retrieve the resource ID (default: “id”). |
|
| string | The property name used to display the resource name in the list (default: “name”). |
|
| string | Set to “array” for a multi-select field; omit this property for a single-select field. |
Example
The following example demonstrates how to use the AAPResourcePicker to create a single-select field for choosing an Inventory.
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: my-AAP-template
title: Example AAP Template
spec:
parameters:
- title: Authentication
properties:
jobInventory:
title: Inventory
description: Select inventory
resource: inventories
ui:field: AAPResourcePicker
default: DemoInventory
5.4.3. Custom filters Copy linkLink copied to clipboard!
The plugins provide custom filters to extract specific properties from resource objects, which is essential for passing data between backstage steps.
| Filter | Purpose | Example Usage |
|---|---|---|
|
| Extracts a single, specific property from a resource object. | `$!{{ parameters.organization |
| resourceFilter('name') }}` |
| Extracts a specific property from multiple resource objects (when the input is an array). |
5.5. Standard UI widgets Copy linkLink copied to clipboard!
Standard UI widgets provide enhanced components for user forms to capture various types of input.
5.5.1. Textarea widget Copy linkLink copied to clipboard!
The textarea widget renders a multi-line text input field for capturing long-form user input such as descriptions or configuration content.
properties:
description:
type: string
title: Description
ui:widget: textarea
ui:options:
rows: 5
placeholder: "Enter description..."
5.5.2. Select widget Copy linkLink copied to clipboard!
The select widget displays a dropdown menu that enables users to choose a single value from a predefined list of options.
properties:
environment:
type: string
title: Environment
enum: ['dev', 'staging', 'prod']
ui:widget: select
default: 'dev'
5.5.3. Checkboxes widgets Copy linkLink copied to clipboard!
The checkboxes widget renders a group of checkboxes, enabling the selection of multiple options from a list. The original plural "Checkboxes Widgets" is corrected to the singular form for style consistency.
properties:
features:
type: array
title: Base Images
items:
type: string
enum: ['baseImage1', 'baseImage2', 'baseImage3']
ui:widget: checkboxes
uniqueItems: true
5.6. Parameter types and field options Copy linkLink copied to clipboard!
The parameters section in a template defines the form fields that users complete before execution. Each property in parameters.properties renders as a form field. This section documents the available types, widgets, and validation options you can use when building custom templates.
5.6.1. Supported parameter types Copy linkLink copied to clipboard!
Templates support standard Backstage parameter types (string, number, integer, boolean, array) and widgets (textarea, select, checkboxes, hidden). For a complete reference of standard types and widgets, see the Backstage Software Templates documentation.
self-service automation portal adds the following Ansible Automation Platform-specific field types:
| Type | Widget | Description | Example use case |
|---|---|---|---|
|
| Hidden token field | OAuth2 authentication token, auto-populated and hidden from the user. | Always present in auto-generated templates. |
|
| Ansible Automation Platform resource picker (single-select) | Select one Ansible Automation Platform resource by name. | Inventory, organization. |
|
| Ansible Automation Platform resource picker (multi-select) | Select multiple Ansible Automation Platform resources by name. | Credentials. |
These Ansible Automation Platform-specific fields are documented in detail in AAP resource picker fields.
5.6.2. AAP resource picker fields Copy linkLink copied to clipboard!
Use ui:field: AAPResourcePicker to let users select Ansible Automation Platform resources by name. self-service automation portal queries the Ansible Automation Platform API and displays available resources in a picker. Set the resource property to specify the Ansible Automation Platform resource type.
The following table lists supported resource values:
resource value | Ansible Automation Platform resource type | Selection mode |
|---|---|---|
|
| Inventories | Single-select |
|
| Credentials |
Multi-select ( |
|
| Organizations | Single-select |
5.6.2.1. Single-select example (inventory) Copy linkLink copied to clipboard!
inventory:
title: Inventory
description: Select target inventory.
resource: inventories
ui:field: AAPResourcePicker
default: Production Servers
5.6.2.2. Multi-select example (credentials) Copy linkLink copied to clipboard!
credentials:
title: Credentials
description: Select credentials for accessing the target hosts.
type: array
resource: credentials
ui:field: AAPResourcePicker
default:
- SSH Key
- AWS Credentials
5.7. Dynamic fields Copy linkLink copied to clipboard!
Dynamic fields appear or disappear based on user selections. Use the dependencies keyword with allOf and if/then to define conditional field visibility. This lets you build forms where selecting a value in one field reveals additional fields relevant to that selection.
Dynamic fields are useful for:
- Showing advanced options only when the user enables them.
- Displaying different configuration fields based on a resource type or category selection.
- Requesting a reason or justification when the user selects a specific option.
5.7.1. Showing or hiding fields based on a toggle Copy linkLink copied to clipboard!
Use a boolean toggle field to show or hide a group of additional fields.
In this example, selecting "Show advanced options" reveals one additional field. When the toggle is off, the field is hidden and not submitted.
parameters:
- title: Time server settings
required:
- ntpServers
properties:
ntpServers:
title: NTP servers
type: string
default: 0.rhel.pool.ntp.org, 1.rhel.pool.ntp.org
showAdvanced:
title: Show advanced options?
type: boolean
default: false
dependencies:
showAdvanced:
allOf:
- if:
properties:
showAdvanced:
const: true
then:
properties:
maxSyncDelay:
type: number
title: Max sync delay (ms)
default: 500
When showAdvanced is true, the form displays maxSyncDelay. When showAdvanced is false, the field is hidden.
5.7.2. Showing different fields based on a selection Copy linkLink copied to clipboard!
Use an enum field with dependencies and allOf to display different configuration fields for each option.
In this example, selecting a database type reveals a version dropdown specific to that engine:
properties:
dbType:
title: Database type
type: string
enum:
- PostgreSQL
- MySQL
dependencies:
dbType:
allOf:
- if:
properties:
dbType:
const: PostgreSQL
then:
properties:
version:
type: number
enum: [13, 14, 15]
title: PostgreSQL version
default: 15
- if:
properties:
dbType:
const: MySQL
then:
properties:
version:
type: string
enum: ['5.7', '8.0']
title: MySQL version
default: '8.0'
Each if/then block in the allOf array matches one enum value. Selecting "PostgreSQL" shows the PostgreSQL version list; selecting "MySQL" replaces it with the MySQL version list.
5.7.3. Chaining multiple dynamic dependencies Copy linkLink copied to clipboard!
You can define multiple dependencies in the same parameter step. Each dependency operates independently.
In this example, selecting "Yes" for the restart confirmation reveals a reason field, while enabling advanced options reveals additional technical fields:
dependencies:
showAdvanced:
allOf:
- if:
properties:
showAdvanced:
const: true
then:
properties:
maxSyncDelay:
type: number
title: Max sync delay (ms)
default: 500
serviceRestart:
allOf:
- if:
properties:
serviceRestart:
const: 'Yes'
then:
properties:
restartReason:
type: string
title: Reason for restart
description: Provide a reason for restarting the service.
default: Applying new configuration.
minLength: 10
errorMessage:
minLength: 'Provide a more detailed reason (at least 10 characters).'
Each key under dependencies corresponds to a property name in the same parameter step. When the user changes a field value, only the matching if/then branch is displayed.
5.8. Configuring the output section Copy linkLink copied to clipboard!
The output section defines what users see after a template runs. You can display text messages, reference user input from parameters, show job execution data from steps, and provide external links.
The output section supports two types of content:
-
text: Displays text blocks with titles and markdown content. -
links: Displays clickable buttons that open external URLs.
5.8.1. Output text Copy linkLink copied to clipboard!
Use output.text to display information to the user after the template runs. Each text block has a title and content field. The content field supports markdown formatting.
output:
text:
- title: Request submitted
content: |
Your request has been submitted.
You can include multiple text blocks:
output:
text:
- title: Request submitted
content: |
Your deployment of **${{ parameters.app_name }}** has been submitted.
**Job ID:** ${{ steps['launch-job'].output.data.id }}
**Status:** ${{ steps['launch-job'].output.data.status }}
- title: Configuration summary
content: |
- Inventory: ${{ parameters.inventory }}
- Application: ${{ parameters.app_name }}
5.8.2. Output links Copy linkLink copied to clipboard!
Use output.links to display clickable buttons. Each link has a title and url field. You can optionally set an icon field.
output:
links:
- title: Check Request Status
url: https://portal.example.com/requests/status
icon: help
You can reference step output data in link URLs:
output:
links:
- title: View job in Ansible Automation Platform
url: ${{ steps['launch-job'].output.data.url }}
You can include multiple links:
output:
links:
- title: View job in Ansible Automation Platform
url: ${{ steps['launch-job'].output.data.url }}
- title: RHEL documentation
url: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/
icon: docs
5.8.3. Referencing parameters in output Copy linkLink copied to clipboard!
You can reference any value the user entered in the parameters section by using the ${{ parameters.<field_name> }} syntax.
The following table lists common parameter references:
| Reference | Description | Example output |
|---|---|---|
|
| User-entered text field value |
|
|
| User-selected Ansible Automation Platform resource name |
|
|
| User-selected credentials (array) |
|
|
| User-selected enum value |
|
5.8.3.1. Example: Displaying user selections in the output Copy linkLink copied to clipboard!
output:
text:
- title: Request submitted
content: |
Your request for **${{ parameters.app_name }}** has been submitted.
**Configuration:**
- Inventory: ${{ parameters.inventory }}
- Environment: ${{ parameters.environment }}
5.8.4. Referencing step output in output Copy linkLink copied to clipboard!
After the rhaap:launch-job-template action runs, the step output includes job execution data. Reference this data using the ${{ steps['<step-id>'].output.data.<field> }} syntax.
The rhaap:launch-job-template action returns the following output fields:
| Reference | Type | Description |
|---|---|---|
|
| number | Ansible Automation Platform Job ID. |
|
| string |
Ansible Automation Platform Job status (for example, |
|
| string | Direct URL to the job in Ansible Automation Platform. |
5.8.4.1. Example: Displaying job execution data in the output Copy linkLink copied to clipboard!
output:
text:
- title: Job launched
content: |
**Job ID:** ${{ steps['launch-job'].output.data.id }}
**Status:** ${{ steps['launch-job'].output.data.status }}
links:
- title: View job in Ansible Automation Platform
url: ${{ steps['launch-job'].output.data.url }}
Chapter 6. Creating execution environment definitions in self-service automation portal Copy linkLink copied to clipboard!
Create custom execution environment (EE) definitions through self-service automation portal using the EE Builder.
Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
6.1. The Execution Environment Builder Copy linkLink copied to clipboard!
The Execution Environment (EE) Builder in self-service automation portal enables you to create custom execution environment definitions through a guided UI wizard or backend configuration methods.
The EE Builder provides both a user-friendly web interface and flexibility for advanced users who prefer configuration-based approaches. When you use the UI wizard, the builder generates the necessary definition files and can publish them to your Git repository or provide them as a download.
The builder supports two primary workflows:
- UI wizard: A step-by-step interface that guides you through selecting base images, collections, Python and system requirements, MCP servers, and additional build steps
- Backend methods: Configuration through Helm charts and direct file management for users who require programmatic control
The generated execution environment definition includes:
-
execution-environment.yml: The main definition file specifying your environment configuration -
requirements.yml: Ansible collections required by your environment -
requirements.txt: Python dependencies -
bindep.txt: System-level package dependencies - Template file: A reusable software template for sharing your configuration
When you publish to a Git repository, the EE Builder creates or updates the repository with all generated files and can create a pull request if the repository already exists.
6.2. Enabling the Execution Environment Builder in self-service automation portal Copy linkLink copied to clipboard!
An administrator must enable the EE definition files feature in the configuration to display it in the left navigation panel.
To enable the EE definition files feature, you must modify the enabled key in your Helm chart configuration.
Procedure
- Open the configuration file for your Helm chart.
-
Navigate to the
default.main-menu-itemssection. Set the value of the
enabledkey under thedefault.eeconfiguration block totrue.NoteSetting
enabled: trueenables the EE definition files feature for all users.Example
The final configuration must look like the following example:
default.main-menu-items: menuItems: default.mycatalog: title: Templates icon: home to: /self-service/catalog priority: 120 default.myitem: title: History icon: category to: /self-service/create/tasks priority: 110 default.ee: enabled: false
6.3. Planning and reference for execution environment definitions Copy linkLink copied to clipboard!
Understand how to successfully plan and configure your custom execution environment (EE) definition. Review the available options for base images, automation presets, and dependency requirements before you start the creation process to ensure your EE supports your organization’s automation content.
6.3.1. Execution Environment (EE) definition Copy linkLink copied to clipboard!
The components and configurations for defining your EE are organized into two main categories: Pre-defined templates (presets) and custom components.
6.3.2. Predefined execution environment templates Copy linkLink copied to clipboard!
Predefined execution environment (EE) templates are preconfigured templates that accelerate environment setup for common use cases. These templates include specific base images, collections, and dependencies tailored for each domain.
| Preset | Description | Key considerations and use cases |
|---|---|---|
| Start from scratch | A blank-slate template for creating custom execution environments. | Use this preset when you require complete control over the base image and dependencies to build a highly customized or minimized execution environment. |
| Networking Automation | A template optimized for network device interaction and network-specific content. | Use this preset when your automation primarily interacts with switches, routers, firewalls, and other network infrastructure. |
| Cloud Automation | A template optimized for deploying and managing cloud resources (such as AWS or Microsoft). | Use this preset when your automation targets provisioning, configuration, and management of cloud services. |
6.3.3. Disabling pre-built templates Copy linkLink copied to clipboard!
For environments where these pre-built templates are not needed or conflict with organizational standards, they can be disabled in the Helm chart configuration.
Procedure
You can disable pre-built templates by commenting them out in the Helm chart configuration. The following is an example of all three pre-built templates commented out:
catalog: locations: # Local templates - type: file target: ../../examples/entities.yaml # The following Ansible pre-built templates are disabled: # - type: url # target: https://github.com/ansible/ansible-rhdh-templates/blob/main/templates/ee-start-from-scratch.yaml # - type: url # target: https://github.com/ansible/ansible-rhdh-templates/blob/main/templates/ee-network-automation.yaml # - type: url # target: https://github.com/ansible/ansible-rhdh-templates/blob/main/templates/ee-cloud-automation.yaml
6.3.4. Components for custom EE definitions Copy linkLink copied to clipboard!
When creating a custom EE, you define the core underlying elements that dictate the environment’s capabilities, security, and dependencies. These components are used to define the custom EE, and are also utilized internally by the pre-defined presets.
| Component or setting | Description | Key considerations and examples |
|---|---|---|
| Base images | The foundation layer of your EE, pre-configured with a specific operating system and toolset. By default, the following base images are available in all 3 pre-defined templates:
| Select a base image that aligns with your organization’s security and Python compatibility needs. Popular base images are optimized for minimal overhead or specific compliance requirements.
If you are providing a custom image, it must include |
| Collections | Specifies the Ansible Collections and Python libraries required by your automation content. |
Ensure all necessary content is included from the documentation’s list. You can add collections manually or upload a When collections overlap, the system merges the contents. If duplicates occur:
|
| Python requirements | Defines the minimum Python version and any extra Python packages required for this execution environment. | Must reflect the version compatibility used across your organization for running automation reliably.
Avoid repeating Python requirements already specified as a dependency by the selected collections (for example, in their respective |
| System packages | Operating system (OS) libraries and packages required by the Python packages or collections. | Defines the extra OS libraries and packages required by the Python packages or collections listed in the EE.
Examples: This list supplements, and must not repeat, any base OS dependencies already managed by your environment’s build system. |
| Additional build steps | Additional build steps are custom shell commands injected directly into the container runtime instruction file. | Use additional build steps to perform actions like installing private certificates or configuring environment variables not covered by standard package installation. |
6.4. Integrating Model Context Protocol (MCP) servers through the EE Builder Copy linkLink copied to clipboard!
The EE Builder supports the optional integration of a Model Context Protocol (MCP) server. MCP servers are an advanced feature used to expose automation actions to AI assistants or other cognitive services.
If you select an MCP server, the EE Builder automatically handles the necessary configuration files and dependencies. This portal feature generates execution environment definition files for building an execution environment with your selected MCP servers.
The EE Builder currently supports the following MCP servers:
- Git Hub
AWS
- AWS CCAPI
- AWS CDK
- AWS IAM
- AWS Core
- Azure
6.5. Creating EE definitions in Self-service automation portal using the EE Builder Copy linkLink copied to clipboard!
You can use the Execution Environment (EE) Builder in the self-service automation portal to create custom EE definitions through a guided workflow.
Prerequisites
- You have installed the self-service automation portal.
- You have the EE Builder feature enabled.
- You have reviewed the Planning and reference for EE definitions section.
Procedure
- Log into the self-service automation portal and select EE definition files from the lefthand navigation pane.
- If this is your first time creating an EE definition file, click Create Execution Environment definition file, otherwise select the Create tab.
- Click Start on your preferred template.
Select your preferred base image and click Next.
NoteRed Hat recommends using the Red Hat Minimal EE base. If selecting Custom Image, it is important you fully understand what the contents of your base image are. For example, a base image without Ansible core or Ansible runner will fail to build.
Select a collection from Add popular Collections or Add Collection Manually and click Next.
- Optional: To add additional Python or System requirements, select Specify additional python requirements and system packages, and then click Add packages manually or Choose File.
- Select your desired MCP servers and click Next.
Optional: In the Additional Build Steps section, you can specify custom build instructions that will be executed at specific steps during the build process:
- Select Add build Step.
- Select a step from the Step type drop-down list.
- Input a command you want to run at that step. You can provide a string of commands by giving each command a new line.
- Click Next.
In the Generate and publish section:
Fill in the following mandatory fields:
- EE File name
- Description
- Select source control provider
- SCM repository organization name or username
- Repository name
-
Ensure the
execution-environmenttag is applied. Click the plus (+) icon to add additional tags if required. - Ensure Publish to a Git repository is selected. If unselected, your EE will be provided as a download after the build process.
- If the Repository name you provided does not already exist, select Create new repository. If it does exist and you check the box, a pull request will be created instead.
- Click Next.
- Confirm your details are correct and click Create. This begins the scaffolding process.
- After the scaffolding is complete, click Getting started for next steps on how to build your EE definition.
Verification
Verify the creation and deployment of the EE definition file using one of the following methods:
In the self-service automation portal:
-
Click View details in catalog or Download EE files (downloads the generated files as a
.tarfile). - Alternatively, select EE definition files in the left-hand navigation pane. The new file appears in the Execution Environment definition files box.
-
Click View details in catalog or Download EE files (downloads the generated files as a
In the repository:
- Click GitHub repository or Gitlab repository to confirm the files were scaffolded into your repository.
6.6. Importing your custom EE definition Copy linkLink copied to clipboard!
The EE definition workflow generates a reusable software template, named <ee-name>-template.yaml. This template includes the specified default configurations when you select Publish to a Git repository during the creation of your custom EE definition.
The template is also generated for non-SCM based publishings.
You can import this template into the self-service automation portal to make the default configuration available to others.
Prerequisites
- You have installed the self-service automation portal.
- You have the EE Builder feature enabled.
- You have a custom EE definition hosted in a repository.
Procedure
-
Go to the repository where your
<ee-name>-template.yamlis stored and open it. - Copy the URL of the template.yaml page.
- Log into the self-service automation portal and select EE definition files from the lefthand navigation pane.
- Click Create > Add Template.
- Paste the template URL into the Select URL field and click Analyze.
- Click Import.
Verification
To verify your template was added successfully, go to EE definition files > Create. Here you should see your newly created custom template.
6.7. Managing your EE files Copy linkLink copied to clipboard!
Download your Execution Environment (EE) file to create a local backup. Copy an existing EE to use it as a template for a new, similar environment. Delete an EE to remove obsolete or unwanted definitions.
Prerequisites
- You have created an EE definition through the EE Builder.
Procedure
- Log into the self-service automation portal and select EE definition files from the lefthand navigation pane.
Under the Name column, select the EE you want to take action on:
- To download your EE definition, click Download EE files.
-
To delete your EE definition, click the
icon and then select Unregister entity.
To copy your EE definition:
-
Click the
icon and then select Copy entity URL.
- Select EE definition files from the lefthand navigation pane.
- Click Create and then Add template.
- Paste your entity URL into the Select URL field and click Analyze.
- Click Import. The new template now appears in the Execution Environment definition files page.
-
Click the
Chapter 7. Discover execution environments and collections Copy linkLink copied to clipboard!
Use the execution environment and collection catalogs in self-service automation portal to discover, browse, and access automation content.
execution environment definitions created through the EE Builder and Ansible collections discovered from synchronized Git repositories are available in dedicated catalog views.
7.1. Execution environment catalog Copy linkLink copied to clipboard!
7.1.1. The execution environment catalog Copy linkLink copied to clipboard!
The execution environment (EE) catalog in self-service automation portal provides a centralized view of all execution environment definitions created through the EE Builder. Use the catalog to browse, search, and access EE definitions for your automation workflows.
7.1.1.1. Catalog content Copy linkLink copied to clipboard!
The EE catalog displays execution environment definitions that have been created through the EE Builder.
7.1.1.2. Using the catalog Copy linkLink copied to clipboard!
The catalog allows you to:
- Browse available execution environment definitions
- View EE configurations and associated files
- Download EE definition files
7.1.2. Browse the execution environment catalog Copy linkLink copied to clipboard!
Browse the execution environment catalog to find and manage EE definitions in self-service automation portal. The catalog displays execution environment definitions discovered from your synchronized repositories, allowing you to view their configurations and access their files. Use search and filtering to locate specific execution environments.
Prerequisites
- You have logged in to self-service automation portal.
- Repositories containing execution environment definitions have been synced to the portal.
Procedure
Navigate to the execution environment catalog.
NoteNavigation path and catalog interface details will be documented here with screenshots.
Browse or search for execution environment definitions.
NoteSearch, filter, and sort options will be documented here with screenshots.
View detailed information about an execution environment definition.
NoteDetail view contents and available options will be documented here with screenshots.
To download an EE definition, click Download EE files.
The EE definition files download as a
.tararchive.
Verification
- Verify you can locate your expected execution environment definitions in the catalog.
- If expected EEs are missing, verify the source repository has been synced successfully and contains valid catalog entity files.
7.2. Collection catalog Copy linkLink copied to clipboard!
7.2.1. The collection catalog Copy linkLink copied to clipboard!
The collection catalog in self-service automation portal provides a centralized view of all Ansible collections discovered from your synchronized Git repositories and execution environment definitions. Use the catalog to browse, search, and learn about available collections for your automation content.
7.2.1.1. Catalog content Copy linkLink copied to clipboard!
The collection catalog displays Ansible collections that have been discovered from:
- execution environment definitions that specify collection requirements
- Synchronized repositories containing collection metadata
Collections are discovered during repository synchronization when self-service automation portal processes catalog entity files and execution environment definitions.
7.2.1.2. Catalog capabilities Copy linkLink copied to clipboard!
You can use the catalog to:
- Browse available Ansible collections
- View collection metadata and dependencies
7.2.2. Browse the collection catalog Copy linkLink copied to clipboard!
Browse the collection catalog to find and explore Ansible collections in self-service automation portal. The catalog displays collections discovered from your synchronized repositories and execution environment definitions, showing collection metadata, dependencies, and documentation links. Use search and filtering to locate specific collections.
Prerequisites
- You have logged in to self-service automation portal.
- Repositories or execution environment definitions containing collection metadata have been synced to the portal.
Procedure
Navigate to the collection catalog.
NoteNavigation path and catalog interface details will be documented here with screenshots.
Browse or search for Ansible collections.
NoteSearch, filter, and sort options will be documented here with screenshots.
View detailed information about a collection.
NoteDetail view contents, including metadata, dependencies, and related execution environments, will be documented here with screenshots.
Verification
- Verify you can locate expected collections in the catalog.
- If expected collections are missing, verify repositories or EE definitions containing the collection have been synced successfully.
Chapter 8. Providing feedback in self-service automation portal Copy linkLink copied to clipboard!
Self-service automation portal provides a feedback form where you can suggest new features and content, as well as provide general feedback.
The feedback form is disabled by default. If the Feedback button is not visible in the console, your administrator must enable it in the portal configuration.
Click Feedback in the self-service automation portal console to display the feedback form.
- Enter the feedback you want to provide.
- Tick the I understand that feedback is shared with Red Hat checkbox.
- Click Submit.
To ensure that Red Hat receives your feedback, exclude your self-service automation portal URL in any browser ad blockers or privacy tools.