Chapter 3. Migrating to automation execution environments 3.1. Why upgrade to automation execution environments? Red Hat Ansible Automation Platform 2.3 introduces automation execution environments. Automation execution environments are container images that allow for easier administration of Ansible by including everything needed to run Ansible automation within a single container. Automation execution environments include: RHEL UBI 8 Ansible 2.9 or Ansible Core 2.13 Python 3.9 or later. Any Ansible Content Collections Collection python or binary dependencies By including these elements, Ansible provides platform administrators a standardized way to define, build, and distribute the environments the automation runs in. Due to the new automation execution environment, it is no longer necessary for administrators to create custom plugins and automation content. Administrators can now spin up smaller automation execution environments in less time to create their content. All custom dependencies are now defined in the development phase instead of the administration and deployment phase. Decoupling from the control plane enables faster development cycles, scalability, reliability, and portability across environments. Automation execution environments enables the Ansible Automation Platform to move to a distributed architecture allowing administrators to scale automation across their organization. 3.2. About migrating legacy venvs to automation execution environments When upgrading from older versions of automation controller to version 4.0 or later, the controller can detect versions of virtual environments associated with Organizations, Inventory and Job Templates and informs you to migrate to the new automation execution environments model. A new installation of automation controller creates two virtualenvs during the installation; one runs the controller and the other runs Ansible. Like legacy virtual environments, automation execution environments allow the controller to run in a stable environment, while allowing you to add or update modules to your automation execution environments as necessary to run your playbooks. You can duplicate your setup in an automation execution environment from a custom virtual environment by migrating them to the new automation execution environment. Use the awx-manage commands in this section to: list of all the current custom virtual environments and their paths ( list_custom_venvs ) view the resources that rely a particular custom virtual environment ( custom_venv_associations ) export a particular custom virtual environment to a format that can be used to migrate to an automation execution environment ( export_custom_venv ) The below workflow describes how to migrate from legacy venvs to automation execution environments using the awx-manage command. 3.3. Migrating virtual envs to automation execution environments Use the following sections to assist with additional steps in the migration process once you have upgraded to Red Hat Ansible Automation Platform 2.0 and automation controller 4.0. 3.3.1. Listing custom virtual environments You can list the virtual environments on your automation controller instance using the awx-manage command. Procedure SSH into your automation controller instance and run: USD awx-manage list_custom_venvs A list of discovered virtual environments will appear. # Discovered virtual environments: /var/lib/awx/venv/testing /var/lib/venv/new_env To export the contents of a virtual environment, re-run while supplying the path as an argument: awx-manage export_custom_venv /path/to/venv 3.3.2. Viewing objects associated with a custom virtual environment View the organizations, jobs, and inventory sources associated with a custom virtual environment using the awx-manage command. Procedure SSH into your automation controller instance and run: USD awx-manage custom_venv_associations /path/to/venv A list of associated objects will appear. inventory_sources: - id: 15 name: celery job_templates: - id: 9 name: Demo Job Template @ 2:40:47 PM - id: 13 name: elephant organizations - id: 3 name: alternating_bongo_meow - id: 1 name: Default projects: [] 3.3.3. Selecting the custom virtual environment to export Select the custom virtual environment you wish to export using awx-manage export_custom_venv command. Procedure SSH into your automation controller instance and run: USD awx-manage export_custom_venv /path/to/venv The output from this command will show a pip freeze of what is in the specified virtual environment. This information can be copied into a requirements.txt file for Ansible Builder to use for creating a new automation execution environments image numpy==1.20.2 pandas==1.2.4 python-dateutil==2.8.1 pytz==2021.1 six==1.16.0 To list all available custom virtual environments run: awx-manage list_custom_venvs Note Pass the -q flag when running awx-manage list_custom_venvs to reduce output. Additional resources For more information on migrating to automation execution environments, refer to the Ansible Navigator Creator Guide .

Commands:
awx-manage list_custom_venvs
Discovered virtual environments: /var/lib/awx/venv/testing /var/lib/venv/new_env To export the contents of a virtual environment, re-run while supplying the path as an argument: awx-manage export_custom_venv /path/to/venv
awx-manage custom_venv_associations /path/to/venv
inventory_sources: - id: 15 name: celery job_templates: - id: 9 name: Demo Job Template @ 2:40:47 PM - id: 13 name: elephant organizations - id: 3 name: alternating_bongo_meow - id: 1 name: Default projects: []
awx-manage export_custom_venv /path/to/venv
numpy==1.20.2 pandas==1.2.4 python-dateutil==2.8.1 pytz==2021.1 six==1.16.0 To list all available custom virtual environments run: awx-manage list_custom_venvs