AnsibleByExample

Ansible Execution Environment Example: Final Review Before Building an EE

Advanced
2024-01-014By Luca Berton

Lesson 1 of 15 in Foundations

Ansible Foundations to Production — full curriculum
  1. 1. Introduction to Ansible and Automation
  2. 2. Installing and Configuring Ansible
  3. 3. Running Ad-Hoc Commands
  4. 4. Writing Your First Playbook
  5. 5. Understanding and Using Modules
  6. 6. Variables and Facts
  7. 7. Conditionals and Loops
  8. 8. Handlers and Idempotency
  9. 9. Structuring Projects with Roles
  10. 10. Inventory Management
  11. 11. Using Ansible Vault for Secrets
  12. 12. Debugging and Troubleshooting
  13. 13. Real-World Automation Examples
  14. 14. Final Project: Deploy a Web Server
  15. 15. Bonus - What's Next with Ansible?
View path overview →

AAP 2.7's Automation Portal ships a 4-step wizard for building Execution Environments (EEs) without writing YAML by hand. Step 4, Review, is your last checkpoint before the build actually runs — it lays out the base image, collections, and destination settings you chose in Steps 1-3 so you can catch mistakes before committing compute time to a build. Here's what that review maps to under the hood, and a matching execution-environment.yml you'd get if you built the same EE by hand.

---
# execution-environment.yml
# Equivalent definition for the EE reviewed in Step 4 of the wizard
version: 3

images:
  base_image:
    name: "registry.redhat.io/ansible-automation-platform-27/ee-minimal-rhel9:latest"

dependencies:
  galaxy:
    collections:
      - name: redhat.rhel_system_roles
        version: "1.20.5"
        source: https://console.redhat.com/api/automation-hub/

additional_build_steps:
  prepend_final: |
    RUN echo "Built via AAP 2.7 EE Builder - reviewed $(date -u +%Y-%m-%d)"

options:
  package_manager_path: /usr/bin/microdnf

What Step 4 actually shows you

When you reach Review, the wizard renders a read-only summary of the three prior steps so you can confirm everything before triggering the build:

  • Base image — from Step 1, e.g. Red Hat Ansible Minimal EE with Ansible Core 2.18 on RHEL 9 (the recommended default), its 2.18 stable-channel counterpart, the Ansible Core 2.16 on RHEL 9 image, its 2.16 stable-channel variant, or a fully custom base image you supplied.
  • Collections — from Step 2, each collection you added through the picker (which searches both Private Automation Hub for rh-certified content and GitHub), listed with its pinned version — in this example, redhat.rhel_system_roles at 1.20.5.
  • Advanced Configuration — any extra Python requirements, system packages, or custom build steps you attached in Step 2, shown so you notice a stray dependency before the build consumes registry pull time.
  • Destination — from Step 3, the EE definition's name, description, tags, the Git repository it will publish to (GitHub, authenticated), and whether "build automatically after publish" is toggled on.

Nothing in Step 4 is editable inline — if something's wrong, you go back a step, fix it, and return to Review. Confirming here publishes the EE definition to the configured Git repository and, if you enabled automatic build, immediately queues the build job.

Why review before build

An EE build pulls a base image, resolves Galaxy collection dependencies, and layers Python/system packages — that's registry bandwidth and compute time on every run. Catching a wrong base image (2.16 instead of 2.18) or an unpinned collection version at Review is free; catching it after a failed build is not. The version: 3 schema mirrors this exactly: images.base_image locks the base, dependencies.galaxy.collections pins each collection version, and additional_build_steps captures anything from Advanced Configuration.

Notes

  • Once a definition is created, the portal's EE catalog lists it alongside every other definition with owner, tags, and star/edit/delete actions — Review is your last chance to fix tags or naming before it shows up there for the whole team.
  • Pin collection versions explicitly (1.20.5, not a floating range) so a rebuild months later doesn't silently pull a newer, untested release.
  • If "build automatically after publish" is off, confirming Review only publishes the definition to Git — you (or a pipeline) still have to trigger the build separately.

Step 4: Review exists so a bad base image or a typo'd collection version never reaches an actual build queue — treat it as a diff, not a formality, and read every line before you confirm.

References

All Tutorials