Chapter 6. Creating execution environment definitions in self-service automation portal
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. Enabling the Execution Environment Builder in self-service automation portal 링크 복사링크가 클립보드에 복사되었습니다!
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2. Planning and reference for execution environment definitions 링크 복사링크가 클립보드에 복사되었습니다!
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.2.1. Execution Environment (EE) definition 링크 복사링크가 클립보드에 복사되었습니다!
The components and configurations for defining your EE are organized into two main categories: Pre-defined templates (presets) and custom components.
6.2.2. Pre-defined EE templates 링크 복사링크가 클립보드에 복사되었습니다!
Pre-defined EE templates are pre-configured templates designed to accelerate environment setup for common use cases. They already include specific base images, collections, and dependencies tailored for their respective domain.
| Preset | Description | Key considerations and use cases |
|---|---|---|
| Start from scratch | A template which acts as a generic blank slate to start creating custom EEs from. | Use this preset when you require complete control over the base image and dependencies to build a highly customized or minimized EE. |
| Networking Automation | A template optimized for environments focused on 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 environments focused on 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.2.3. Disabling pre-built templates 링크 복사링크가 클립보드에 복사되었습니다!
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.4. Components for custom EE definitions 링크 복사링크가 클립보드에 복사되었습니다!
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 Select a base image that aligns with your organization’s security and Python compatibility needs. |
| 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.3. Integrating Model Context Protocol (MCP) servers through the EE Builder 링크 복사링크가 클립보드에 복사되었습니다!
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.4. Creating EE definitions in Self-service automation portal using the EE Builder 링크 복사링크가 클립보드에 복사되었습니다!
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.5. Importing your custom EE definition 링크 복사링크가 클립보드에 복사되었습니다!
The EE definition workflow generates a reusable Backstage 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.6. Managing your EE files 링크 복사링크가 클립보드에 복사되었습니다!
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