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.

Note

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

  1. Open the configuration file for your Helm chart.
  2. Navigate to the default.main-menu-items section.
  3. Set the value of the enabled key under the default.ee configuration block to true.

    Note

    Setting enabled: true enables 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
    Copy to Clipboard Toggle word wrap

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.

Expand
PresetDescriptionKey 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:

    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
    Copy to Clipboard Toggle word wrap

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.

Expand
Component or settingDescriptionKey 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:

  • Red Hat Ansible Minimal EE - Ansible Core 2.18 (RHEL 8)
  • Red Hat Ansible Minimal EE - Ansible Core 2.18 (RHEL 9)
  • Red Hat Ansible Minimal EE - Ansible Core 2.16 (RHEL 8)
  • Red Hat Ansible Minimal EE - Ansible Core 2.16 (RHEL 9)

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 ansible-core and ansible-runner.

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 requirements.yml file.

When collections overlap, the system merges the contents. If duplicates occur:

  • If a version is not specified, the system prioritizes the collection using the most recent version available.
  • If versions are explicitly specified for both collections, the system defaults to using the most recent version.

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 requirements.txt files).

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: git, gcc, python3-devel. These are necessary for compiling Python packages during the build process.

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

Procedure

  1. Log into the self-service automation portal and select EE definition files from the lefthand navigation pane.
  2. If this is your first time creating an EE definition file, click Create Execution Environment definition file, otherwise select the Create tab.
  3. Click Start on your preferred template.
  4. Select your preferred base image and click Next.

    Note

    Red 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.

  5. Select a collection from Add popular Collections or Add Collection Manually and click Next.

    1. 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.
  6. Select your desired MCP servers and click Next.
  7. Optional: In the Additional Build Steps section, you can specify custom build instructions that will be executed at specific steps during the build process:

    1. Select Add build Step.
    2. Select a step from the Step type drop-down list.
    3. Input a command you want to run at that step. You can provide a string of commands by giving each command a new line.
    4. Click Next.
  8. In the Generate and publish section:

    1. Fill in the following mandatory fields:

      • EE File name
      • Description
      • Select source control provider
      • SCM repository organization name or username
      • Repository name
    2. Ensure the execution-environment tag is applied. Click the plus (+) icon to add additional tags if required.
    3. Ensure Publish to a Git repository is selected. If unselected, your EE will be provided as a download after the build process.
    4. 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.
    5. Click Next.
  9. Confirm your details are correct and click Create. This begins the scaffolding process.
  10. 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:

  1. In the self-service automation portal:

    1. Click View details in catalog or Download EE files (downloads the generated files as a .tar file).
    2. Alternatively, select EE definition files in the left-hand navigation pane. The new file appears in the Execution Environment definition files box.
  2. In the repository:

    1. 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

  1. Go to the repository where your <ee-name>-template.yaml is stored and open it.
  2. Copy the URL of the template.yaml page.
  3. Log into the self-service automation portal and select EE definition files from the lefthand navigation pane.
  4. Click Create > Add Template.
  5. Paste the template URL into the Select URL field and click Analyze.
  6. 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

  1. Log into the self-service automation portal and select EE definition files from the lefthand navigation pane.
  2. 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 vertical dots icon and then select Unregister entity.
    • To copy your EE definition:

      • Click the vertical dots 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.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동