AAP 2.6 Execution Environments: Build, Manage, and Deploy Custom EEs
By Luca Berton · Published 2024-01-01 · Category: installation
Complete guide to Execution Environments in AAP 2.6. Build custom EEs with ansible-builder, manage images in Private Automation Hub, troubleshoot dependency conflicts, and optimize container images for production.
What Are Execution Environments?
Execution Environments (EEs) are container images that package everything needed to run Ansible automation in a consistent, portable, and isolated way: • Ansible Core runtime • Python packages required by collections and custom modules • System packages (libraries, binaries) • Ansible Collections pre-installed • Custom plugins and filter plugins
EEs replace the legacy approach of managing Python virtual environments and system dependencies directly on control nodes. In AAP 2.6, all automation runs inside EEs — on both Automation Controller and locally with ansible-navigator.
Why EEs Solve Real Problems
Before EEs (The Pain)
With EEs (The Solution)
Each team gets their own container image with exactly the dependencies they need. No conflicts, no drift, completely reproducible.
Red Hat Provided EE Images
AAP 2.6 ships with base images from the Red Hat registry:
| Image | Contents | Use Case | |-------|----------|----------| | ee-minimal-rhel9 | Ansible Core + minimal Python deps | Lightweight tasks, custom base | | ee-supported-rhel9 | Core + Red Hat certified collections | General enterprise automation | | ee-29-rhel9 | Core 2.16 + latest supported collections | Latest features and modules |
Pull from the Red Hat registry:
Building Custom EEs with ansible-builder
Install ansible-builder
Execution Environment Definition (v3)
Create execution-environment.yml:
Build the Image
Build Output
EE Definition Deep Dive
Galaxy Dependencies (Collections)
Specify collections with version constraints:
Or reference a requirements.yml file:
Python Dependencies
Specify Python packages:
Or reference a requirements.txt file:
System Dependencies
Use Bindep format for system packages:
Additional Build Steps
Inject custom Containerfile instructions:
Publishing EEs to Private Automation Hub
Push your custom EE to Private Automation Hub for use across your organization:
Configure Controller to Use Custom EE
Testing EEs Locally with ansible-navigator
Before pushing to production, test your EE locally:
Multi-Stage Builds for Smaller Images
Optimize EE image size by separating build-time and runtime dependencies:
The [platform:rpm compile] tag tells ansible-builder to install these packages only during the build stage and remove them from the final image.
Versioning and CI/CD for EEs
Automated EE Build Pipeline
Semantic Versioning for EEs
Troubleshooting
Collection Dependency Conflicts
Fix: Pin compatible versions explicitly:
Python Package Build Failures
Fix: Add build-time system dependencies:
Image Too Large
Authentication to Red Hat Registry
Fix: Login to the Red Hat registry with your RHN credentials:
FAQ
Can I use community base images instead of Red Hat?
Yes, but only Red Hat base images are supported under your AAP subscription. Community images like quay.io/ansible/ansible-runner work for development but are not tested or supported by Red Hat for production AAP deployments.
How often should I rebuild EEs?
Rebuild when collection versions change, Python dependencies update, or security patches are released. A weekly automated build via CI/CD is a good baseline. Always rebuild after Ansible Core security advisories.
Can I run different EEs for different job templates?
Yes. Each job template in Automation Controller can specify its own Execution Environment. This is the recommended approach — build purpose-specific EEs (network, cloud, security, Windows) rather than one monolithic image.
What is the difference between ansible-builder v2 and v3?
Version 3 of the EE definition format (used in this guide) adds support for multi-stage builds via [compile] tags, multiple base image selection, and more flexible additional_build_steps hooks. Always use version: 3 for new EEs.
Can execution nodes pull EEs from external registries?
Execution nodes pull EE images from the registry configured in Automation Controller. For air-gapped environments, use Private Automation Hub as a local registry mirror. Execution nodes must have network access to the configured registry.
Conclusion
Execution Environments are foundational to AAP 2.6's architecture. They eliminate dependency conflicts, ensure reproducibility across environments, and enable teams to independently manage their automation toolchains. Invest in a proper EE build pipeline early — it pays dividends as your automation scales.
Related Articles • AAP 2.6 Architecture and Components: Complete Guide • AAP 2.6 RPM Deprecation and Containerized Migration • AAP 2.6 New Collections and Integrations • AAP 2.6 Configuration as Code with ansible.platform • AAP 2.6 Security Best Practices
Category: installation