AAP 2 Migration Considerations Checklist

The following document helps provide context into the relative degree of difficulty for upgrading/migrating from Red Hat Ansible Automation Platform 1.x to 2. This will provide insight into meaningful eligibility questions and considerations for customers to determine what work would be required if applicable. If you are unsure what a term or acronym means please refer to the Content from docs.ansible.com is not included.Ansible Glossary.

Customers or Red Hat sales (on behalf of customers) may ask the following questions:

• “When should we upgrade to Ansible Automation Platform 2?”
• “What specific dependencies need to be resolved prior to upgrading?”
• “What is the relative degree of difficulty in upgrading based on my current installation?”

NOTES

• Performance: Initial playbook job runs can experience performance overhead if the execution environment image is not already present on the host. This is due to the image needing to be pulled from the relevant registry. Once the image is present on the host, the performance will improve. This is expected as the EEs are spun up on demand in Ansible Automation Platform 2, the benefit is in management of the ansible instance and its portability for both scale and development efforts but we will be looking at improvements as more usage patterns are reported. Please go through Content from www.ansible.com is not included.this blog which talks about performance improvements with Ansible Automation Platform 2.
• Automation execution environments can be large
  • One of the motivations behind collections was that Ansible increasingly was becoming larger and larger as a project. Many customers have reported that they do not want to install a full Ansible build all the time. EEs and collections, plus ansible-builder allow more accurate lifecycle management of Ansible environments based on use cases and customer upgrade cycles.
  • An accompanying challenge with using containers when including a base OS image plus all possibly required python dependencies is that execution environments can get increasingly large if care is not taken. This is a common problem that OpenShift and RHEL are also experiencing and while it can be alarming to some users it is expected and we will continue working on ways to minimize container sizes going forward. A general migration consideration for customers would be to build an EE with ee-minimal as base and to use separate EEs per organization and build them based on each organization's Ansible content needs.
  • Example:
    • ee-minimal: 292MB
    • ee-supported: 907MB (Includes ee-controller and inventory plugins)
    • An ee that included all ansible 2.9 community content and all dependencies could be very large.
• Using Private automation hub
  • While not 100% mandatory, without Private automation Hub customers will struggle to reap the benefits of Ansible Automation Platform 2.
  • Whether for storing/distributing synced collections from cloud.redhat.com, in house developed collections, community collections, or for storing/distributing Execution Environments, Hub is an important part of the story for Ansible users within an organization.
• Using ansible-navigator
  • Another benefit of Automation execution environments is the playbook development use case. Now that production virtual envs run in a container, you can use that same container to craft a playbook. Automation content navigator is the tool for this that replaces the need to install ansible on a laptop or server for playbook development.
  • While ansible can still be installed from an RPM and built up using tools (as ansible-builder would do), Automation content navigator plus execution environments allow for that in a much simpler deployment model.
  • Automation content navigator does change existing developer workflows and customers with a large number of users will need to consider how they enable their internal customers to use this new method, plus how to distribute the navigator tool before they upgrade, or understand how to recreate a ansible 2.11 build via their existing processes.
• Migrating playbooks to run in execution environments
  • Referencing localhost in playbooks
    • References to ‘localhost’ in Ansible Automation Platform 2.0 using an execution environment refers to the pod itself where previously, it would refer to the host. As an example, executing a playbook on the Automation controller itself will need to be done via an SSH connection to complete successfully.
    • Examples of references to ‘localhost’ that need to be considered include:
      • delegate_to: localhost
      • ansible_connection: local
    • Why does this matter? Containers are ephemeral and any file or manipulation that happens locally will only exist for the duration of the play. Use-cases like backing up files, fetching files, saving ssh keys on tower(AAP 1.2) node, installing SDKs on tower(AAP 1.2) node etc. will not work like they did before execution environments.
  • Job Isolation
    • Job isolation will no longer be supported due to execution occurring within isolated pods.
• API Considerations
  • The top-level /api/v2/job_events endpoints have been removed
  • The job_events API endpoint will only be present for individual jobs

Sources:
Migration Scenarios doc