mirror of
https://github.com/ansible/awx.git
synced 2026-01-10 15:32:07 -03:30
1bcd71a8ac
Update execution enviorment documentation link (fixes #14690) Signed-off-by: Cameron McLaughlin <auatr7@protonmail.com>
65 lines
2.9 KiB
Markdown
65 lines
2.9 KiB
Markdown
# Execution Environments
|
|
|
|
All jobs use container isolation for environment consistency and security.
|
|
Compliant images are referred to as Execution Environments (EE)s.
|
|
|
|
For more information about the EE technology as well as how to build and test EEs, see:
|
|
- [Getting started with Execution Environments guide](https://ansible.readthedocs.io/en/latest/getting_started_ee/index.html)
|
|
- [Ansible Builder documentation](https://ansible.readthedocs.io/projects/builder/en/latest/)
|
|
|
|
The Execution Environment model has an `image` field for the image identifier which will be used by jobs.
|
|
The job details view will link to the execution environment that the job uses.
|
|
|
|
## Creating and using EEs
|
|
|
|
Users with an organization's `execution_environment_admin_role` can create new EEs in that organization.
|
|
The RBAC rules follow standard rules for org-scoped resources.
|
|
|
|
EEs without an organization (value is null in the API) are global EEs.
|
|
Only superusers can create global EEs.
|
|
These can become the global job default in certain circumstances.
|
|
|
|
### Pre-created EEs
|
|
|
|
Installers should run the `awx-manage register_default_execution_environments` command to pre-populate
|
|
the system with some EEs defined in settings. This will create:
|
|
|
|
- the control plane EE - corresponding to the `CONTROL_PLANE_EXECUTION_ENVIRONMENT` setting
|
|
- global job EEs - all images enumerated in the `GLOBAL_JOB_EXECUTION_ENVIRONMENTS` setting
|
|
|
|
These EEs are critical for system function, so this command must be ran for AWX to be functional.
|
|
All EEs created by this command are global EEs.
|
|
|
|
### Project Update EE Precedence
|
|
|
|
Project updates will always use the control plane EE.
|
|
|
|
### Job, Ad Hoc Commands, and inventory update EE Precedence
|
|
|
|
Jobs will use the first available execution environment in this list:
|
|
|
|
1. the `execution_environment` defined on the template (job template or inventory source) that spawned the job
|
|
2. the `default_environment` defined on the project that the job uses
|
|
3. the `default_environment` defined on the organization of the job
|
|
4. the `default_environment` defined on the organization of the inventory the job uses
|
|
5. the current `DEFAULT_EXECUTION_ENVIRONMENT` setting (configurable at `/api/v2/settings/jobs/`)
|
|
6. Any image from the `GLOBAL_JOB_EXECUTION_ENVIRONMENTS` setting
|
|
7. Any other global EE
|
|
|
|
If more than one EE fits a criteria (applies for 6 and 7), then the most recently created one will be used.
|
|
|
|
## Migrating from Custom Virtual Environments
|
|
|
|
If you have installed dependencies inside of custom virtual environments in
|
|
a prior release, then have a look at this series of commands for help migrating
|
|
dependencies out of the venvs and into EEs.
|
|
|
|
- `awx-manage list_custom_venvs`
|
|
- `awx-manage custom_venv_associations`
|
|
- `awx-manage export_custom_venv`
|
|
|
|
Follow those in order, and read the help text to see what arguments are necessary.
|
|
|
|
Output from the `awx-manage export_custom_venv -q ..` command can
|
|
be a starting point for writing an `ansible-builder` definition file.
|