Skip to content
DevOps AI ToolKit
Newsletter
All prompts
AI for Ansible Difficulty: Advanced ClaudeChatGPTCursor

Ansible Execution Environment Build Prompt

Design a reproducible ansible-builder execution environment with pinned collections, Python deps, and system packages that runs identically in dev, CI, and AWX/AAP.

Target user
Ansible engineers packaging playbooks into container-based execution environments
Difficulty
Advanced
Tools
Claude, ChatGPT, Cursor

The prompt

You are a senior automation platform engineer who builds Ansible execution environments (EEs) that behave the same on a laptop, in CI, and inside AWX/AAP. You know that "works on my control node" fails the moment a job runs in a container that is missing a collection dependency, a Python library, or a system package — and you pin everything so a rebuild six months from now produces the same image.

Help me design an execution environment with ansible-builder. I want a definition that is reproducible, minimal, and debuggable.

Steps:

1. **Inventory the real dependencies**: from my playbooks/roles, list the collections actually used, their Galaxy requirements, the Python libraries the modules import (e.g. `kubernetes`, `boto3`, `pywinrm`, `netaddr`), and any system packages (`git`, `openssh-clients`, `sshpass`, compilers for C extensions).
2. **Pick a base image and version**: recommend a base EE image (e.g. a supported `ansible-runner`/community EE) pinned by digest or tag, and pin `ansible-core` explicitly so the runtime version is deterministic.
3. **Author the build files** for the current ansible-builder schema:
   - `execution-environment.yml` (version 3) with `images.base_image`, `dependencies.ansible_core`, `dependencies.ansible_runner`, `galaxy`, `python`, and `system` sections.
   - `requirements.yml` with collections pinned to exact versions.
   - `requirements.txt` with Python deps pinned (and a note on why unpinned transitive deps are a reproducibility risk).
   - `bindep.txt` for system packages, using the correct profiles.
4. **Keep it lean**: use `additional_build_steps` (prepend/append) only where needed, avoid baking secrets or SSH keys into layers, and drop build-only toolchains from the final image.
5. **Verify the image**: give commands to build with ansible-builder, then prove the EE actually works — `ansible-navigator` / `ansible-runner` run of a smoke playbook, plus `ansible-galaxy collection list` and a Python import check inside the container.
6. **Wire reproducibility**: show how to tag/push the image, record the resolved versions, and rebuild deterministically in CI.

Fill in:
- Collections and modules I use: [LIST]
- Cloud/OS targets (AWS, Azure, k8s, Windows): [DESCRIBE]
- Registry + ansible-core version target: [SPECIFY]
- Where it runs (AWX / AAP / plain ansible-navigator): [SPECIFY]

Output format: the four build files, the ansible-builder build command, a verification checklist that proves the EE runs the smoke playbook, and a list of every version I still need to pin. Never bake credentials, vault passwords, or private keys into the image — flag anywhere my inputs imply that and propose runtime injection instead.

Run this prompt with AI

Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.

Why this prompt works

Execution environments fail in a specific, maddening way: the playbook is fine, but the container the job runs in is missing one collection, one Python library, or sshpass, and the failure only shows up in AWX at 2am. This prompt front-loads a real dependency inventory — collections, the Python libs the modules import, and system packages — so the EE definition is built from what the code actually needs rather than from guesses.

Pinning is the whole point of a reproducible EE, so the prompt insists on exact versions across all four build files and calls out unpinned transitive Python deps as the reproducibility hole they are. The base image pinned by digest and an explicit ansible-core version mean a rebuild months later yields the same runtime, not a surprise from an upstream release.

The verification step is what separates a definition that compiles from an EE that works: building the image proves nothing until a smoke playbook runs inside it and ansible-galaxy collection list plus a Python import check confirm the pieces are present. And the credential guardrail matters because it is easy to COPY a key or vault password into a layer — where it lives forever in image history — so the prompt forces runtime injection instead.

Related prompts

More Ansible prompts & error guides

Browse every Ansible prompt and troubleshooting guide in one place.

Free download · 368-page PDF

Reading prompts? Get all 500 in one free PDF

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.