Este conteúdo não está disponível no idioma selecionado.
Chapter 21. Execution Environment Setup Reference
This section contains reference information associated with the definition of an execution environment. You define the content of your execution environment in a YAML file. By default, this file is called execution_environment.yml
. This file tells Ansible Builder how to create the build instruction file (Containerfile for Podman, Dockerfile for Docker) and build context for your container image.
The definition schema for Ansible Builder 3.x is documented here. If you are running an older version of Ansible Builder, you need an older schema version. For more information, see older versions of this documentation. We recommend using version 3, which offers substantially more configurable options and functionality than previous versions.
21.1. Execution environment definition example
You must create a definition file to build an image for an execution environment. The file is in YAML format.
You must specify the version of Ansible Builder in the definition file. The default version is 1.
The following definition file is using Ansible Builder version 3:
version: 3 build_arg_defaults: ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: '--pre' dependencies: galaxy: requirements.yml python: - six - psutil system: bindep.txt images: base_image: name: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel8:latest additional_build_files: - src: files/ansible.cfg dest: configs additional_build_steps: prepend_galaxy: - ADD _build/configs/ansible.cfg /home/runner/.ansible.cfg prepend_final: | RUN whoami RUN cat /etc/os-release append_final: - RUN echo This is a post-install command! - RUN ls -la /etc
21.2. Configuration options
Use the following configuration YAML keys in your definition file.
The Ansible Builder 3.x execution environment definition file accepts seven top-level sections:
21.2.1. additional_build_files
The build files specify what are to be added to the build context directory. These can then be referenced or copied by additional_build_steps
during any build stage.
The format is a list of dictionary values, each with a src
and dest
key and value.
Each list item must be a dictionary containing the following required keys:
src | Specifies the source files to copy into the build context directory.
This can be an absolute path, for example, |
dest |
Specifies a subdirectory path underneath the
This cannot be an absolute path or contain Note
When using an |
21.2.2. additional_build_steps
The build steps specify custom build commands for any build phase. These commands are inserted directly into the build instruction file for the container runtime, for example, Containerfile or Dockerfile. The commands must conform to any rules required by the containerization tool.
You can add build steps before or after any stage of the image creation process. For example, if you need git
to be installed before you install your dependencies, you can add a build step at the end of the base build stage.
The following are the valid keys. Each supports either a multi-line string, or a list of strings.
append_base | Commands to insert after building of the base image. |
append_builder | Commands to insert after building of the builder image. |
append_final | Commands to insert after building of the final image. |
append_galaxy | Commands to insert after building of the galaxy image. |
prepend_base | Commands to insert before building of the base image. |
prepend_builder | Commands to insert before building of the builder image. |
prepend_final | Commands to insert before building of the final image. |
prepend_galaxy | Commands to insert before building of the galaxy image. |
21.2.3. build_arg_defaults
This specifies the default values for build arguments as a dictionary.
This is an alternative to using the --build-arg
CLI flag.
Ansible Builder uses the following build arguments:
ANSIBLE_GALAXY_CLI_COLLECTION_OPTS |
Enables the user to pass the |
ANSIBLE_GALAXY_CLI_ROLE_OPTS |
This enables the user to pass any flags, such as |
PKGMGR_PRESERVE_CACHE | This controls how often the package manager cache is cleared during the image build process.
If this value is not set, which is the default, the cache is cleared frequently. If the value is |
Ansible Builder hard-codes values given inside of build_arg_defaults
into the build instruction file, so they persist if you run your container build manually.
If you specify the same variable in the definition and at the command line with the CLI build-arg
flag, the CLI value overrides the value in the definition.
21.2.4. Dependencies
Specifies dependencies to install into the final image, including ansible-core
, ansible-runner
, Python packages, system packages, and collections. Ansible Builder automatically installs dependencies for any Ansible collections you install.
In general, you can use standard syntax to constrain package versions. Use the same syntax you would pass to dnf
, pip
, ansible-galaxy
, or any other package management utility. You can also define your packages or collections in separate files and reference those files in the dependencies
section of your definition file.
The following keys are valid:
ansible_core |
The version of the
This value is a dictionary with a single key, ansible_core: package_pip: ansible-core ansible_core: package_pip: ansible-core==2.14.3 ansible_core: package_pip: https://github.com/example_user/ansible/archive/refs/heads/ansible.tar.gz |
ansible_runner | The version of the Ansible Runner Python package to be installed.
This value is a dictionary with a single key, ansible_runner: package_pip: ansible-runner ansible_runner: package_pip: ansible-runner==2.3.2 ansible_runner: package_pip: https://github.com/example_user/ansible-runner/archive/refs/heads/ansible-runner.tar.gz |
galaxy | Collections to be installed from Ansible Galaxy.
This can be a filename, a dictionary, or a multi-line string representation of an Ansible Galaxy |
python | The Python installation requirements.
This can be a filename, or a list of requirements. Ansible Builder combines all the Python requirements files from all collections into a single file using the This library supports complex syntax, including references to other files. If many collections require the same package name, Ansible Builder combines them into a single entry and combines the constraints.
Ansible Builder excludes some packages in the combined file of Python dependencies even if a collection lists them as dependencies. These include test packages and packages that provide Ansible itself. The full list can is available under
If you need to include one of these excluded package names, use the Packages supplied this way are not processed against the list of excluded Python packages. |
python_interpreter |
A dictionary that defines the Python system package name to be installed by dnf ( |
system | The system packages to be installed, in bindep format. This can be a filename or a list of requirements. For more information about bindep, see the OpenDev documentation.
For system packages, use the |
The following example uses filenames that contain the various dependencies:
dependencies: python: requirements.txt system: bindep.txt galaxy: requirements.yml ansible_core: package_pip: ansible-core==2.14.2 ansible_runner: package_pip: ansible-runner==2.3.1 python_interpreter: package_system: "python310" python_path: "/usr/bin/python3.10"
This example uses inline values:
dependencies: python: - pywinrm system: - iputils [platform:rpm] galaxy: collections: - name: community.windows - name: ansible.utils version: 2.10.1 ansible_core: package_pip: ansible-core==2.14.2 ansible_runner: package_pip: ansible-runner==2.3.1 python_interpreter: package_system: "python310" python_path: "/usr/bin/python3.10"
If any of these dependency files (requirements.txt, bindep.txt, and requirements.yml
) are in the build_ignore
of the collection, the build fails.
Collection maintainers can verify that ansible-builder recognizes the requirements they expect by using the introspect
command:
ansible-builder introspect --sanitize ~/.ansible/collections/
The --sanitize
option reviews all of the collection requirements and removes duplicates. It also removes any Python requirements that are normally excluded (see python dependencies).
Use the -v3
option to introspect
to see logging messages about requirements that are being excluded.
21.2.5. images
Specifies the base image to be used. At a minimum you must specify a source, image, and tag for the base image. The base image provides the operating system and can also provide some packages. Use the standard host/namespace/container:tag
syntax to specify images. You can use Podman or Docker shortcut syntax instead, but the full definition is more reliable and portable.
Valid keys for this section are:
base_image | A dictionary defining the parent image for the execution environment.
A |
21.2.6. Image verification
You can verify signed container images if you are using the podman
container runtime.
Set the container-policy
CLI option to control how this data is used in relation to a Podman policy.json
file for container image signature validation.
-
ignore_all
policy: Generate apolicy.json
file in the buildcontext directory <context>
where no signature validation is performed. -
system
policy: Signature validation is performed using pre-existingpolicy.json
files in standard system locations.ansible-builder
assumes no responsibility for the content within these files, and the user has complete control over the content. -
signature_required
policy:ansible-builder
uses the container image definitions to generate apolicy.json
file in the buildcontext directory <context>
that is used during the build to validate the images.
21.2.7. options
A dictionary of keywords or options that can affect the runtime functionality Ansible Builder.
Valid keys for this section are:
container_init: A dictionary with keys that allow for customization of the container
ENTRYPOINT
andCMD
directives (and related behaviors). Customizing these behaviors is an advanced task, and can result failures that are difficult to debug. Because the provided defaults control several intertwined behaviors, overriding any value skips all remaining defaults in this dictionary.Valid keys are:
-
cmd: Literal value for the
CMD
Containerfile directive. The default value is["bash"]
. entrypoint: Literal value for the
ENTRYPOINT
Containerfile directive. The default entrypoint behavior handles signal propagation to subprocesses, as well as attempting to ensure at runtime that the container user has a proper environment with a valid writeable home directory, represented in/etc/passwd
, with theHOME
environment variable set to match. The default entrypoint script can emit warnings tostderr
in cases where it is unable to suitably adjust the user runtime environment. This behavior can be ignored or elevated to a fatal error; consult the source for theentrypoint
target script for more details.The default value is
["/opt/builder/bin/entrypoint", "dumb-init"]
.package_pip: Package to install with pip for entrypoint support. This package is installed in the final build image.
The default value is
dumb-init==1.2.5
.
-
cmd: Literal value for the
-
package_manager_path: string with the path to the package manager (dnf or microdnf) to use. The default is
/usr/bin/dnf
. This value is used to install a Python interpreter, if specified independencies
, and during the build phase by theassemble
script. skip_ansible_check: This boolean value controls whether or not the check for an installation of Ansible and Ansible Runner is performed on the final image.
Set this value to
True
to not perform this check.The default is
False
.relax_passwd_permissions: This boolean value controls whether the
root
group (GID 0) is explicitly granted write permission to/etc/passwd
in the final container image. The default entrypoint script can attempt to update/etc/passwd
under some container runtimes with dynamically created users to ensure a fully-functional POSIX user environment and home directory. Disabling this capability can cause failures of software features that require users to be listed in/etc/passwd
with a valid and writeable home directory, for example,async
in ansible-core, and the~username
shell expansion.The default is
True
.workdir: Default current working directory for new processes started under the final container image. Some container runtimes also use this value as
HOME
for dynamically-created users in theroot
(GID 0) group. When this value is specified, if the directory does not already exist, it is created, set toroot
group ownership, andrwx
group permissions are recursively applied to it.The default value is
/runner
.user: This sets the username or UID to use as the default user for the final container image.
The default value is
1000
.
Example options:
options: container_init: package_pip: dumb-init>=1.2.5 entrypoint: '["dumb-init"]' cmd: '["csh"]' package_manager_path: /usr/bin/microdnf relax_password_permissions: false skip_ansible_check: true workdir: /myworkdir user: bob
21.2.8. version
An integer value that sets the schema version of the execution environment definition file.
Defaults to 1
.
The value must be 3
if you are using Ansible Builder 3.x.
21.3. Default execution environment for AWX
The example in test/data/pytz
requires the awx.awx
collection in the definition. The lookup plugin awx.awx.tower_schedule_rrule
requires the PyPI pytz
and another library to work. If the test/data/pytz/execution-environment.yml
file is provided to the ansible-builder build
command, it installs the collection inside the image, reads the requirements.txt
file inside of the collection, and then installs pytz
into the image.
The image produced can be used inside of an ansible-runner
project by placing these variables inside the env/settings
file, inside the private data directory.
--- container_image: image-name process_isolation_executable: podman # or docker process_isolation: true
The awx.awx
collection is a subset of content included in the default AWX .
For further information, see the awx-ee repository.