Ansible Automation Platform 2.7 ships a visual Execution Environment (EE) Builder in Automation Portal — a four-step wizard that builds container-based EEs without hand-writing YAML. Step 1, Base Image, is where every EE starts: pick the Red Hat-provided image your automation content will run on. Here's what that choice produces under the hood.
# execution-environment.yml
# Generated definition after completing Step 1: Base Image
# in the AAP 2.7 Automation Portal EE Builder wizard.
---
version: 3
images:
base_image:
name: "registry.redhat.io/ansible-automation-platform-27/ee-minimal-rhel9:latest"
# Recommended option selected in the wizard:
# "Red Hat Ansible Minimal EE - Ansible Core 2.18 on RHEL 9"
dependencies:
python: requirements.txt
system: bindep.txt
additional_build_steps:
append_final: []
What this does
The wizard's Step 1 screen lists five base image choices, each mapping to a Red Hat container image reference:
- Red Hat Ansible Minimal EE — Ansible Core 2.18 on RHEL 9 (recommended, shown pre-selected)
- A stable-channel variant of the Ansible Core 2.18 image
- Red Hat Ansible Minimal EE — Ansible Core 2.16 on RHEL 9
- A stable-channel variant of the Ansible Core 2.16 image
- A fully custom base image, where you supply your own registry reference
Selecting one of the Red Hat-provided options simply pins images.base_image.name in the EE definition that the portal maintains for you — nothing else in the definition changes yet. The empty dependencies and additional_build_steps blocks are placeholders the wizard fills in during Step 2 (Configuration), when you search Private Automation Hub or GitHub for collections to add — for example redhat.rhel_system_roles at version 1.20.5 — and optionally add extra Python packages, system packages, or custom build steps via Advanced Configuration.
Choosing the minimal RHEL 9 / Ansible Core 2.18 image over the 2.16 line matters because content that depends on newer ansible-core features (module options, filter plugins, collection requirements) will only run correctly on the image version that ships that behavior. The "stable channel" variants track a slower-moving stream of the same base, useful when you want fewer unplanned image updates between builds.
Notes / Gotchas
- Base image selection happens once per EE definition, in Step 1 — going back to change it later re-runs validation in Step 4 (Review) before any build kicks off.
- If your playbooks or roles pin
ansible-coreversion requirements, match the base image accordingly: Core 2.18 on RHEL 9 is the current recommended default, Core 2.16 on RHEL 9 remains available for existing content that hasn't been validated against 2.18 yet. - The "fully custom base image" option bypasses the Red Hat-maintained image catalog entirely — you own patching and Ansible Core version compatibility for that image.
- Every EE definition, regardless of base image, shows up afterward in Automation Portal's searchable EE catalog with owner, tags, and star/edit/delete actions — useful for auditing which teams are still building against the 2.16 line.
- Step 3 (Destination and Build) is where the definition actually gets published to a Git repository and, optionally, built immediately — the base image choice from Step 1 has no effect until that build runs.
Picking the right base image in Step 1 is a one-time decision with lasting consequences for compatibility, so default to the recommended Ansible Core 2.18 on RHEL 9 image unless existing content ties you to 2.16.
Related Articles
- Ansible Execution Environment Example: Adding a Collection via the EE Builder
- Ansible Execution Environment Example: Final Review Before Building an EE
- Ansible Execution Environment Example: Publishing an EE Definition to GitHub