Ansible Automation Platform 2 Migration Strategy Considerations

Updated

Overview

Ansible Automation Platform 2 (AAP 2.1) introduces an updated architecture, new tools, and an improved but familiar experience to automation teams. Multiple considerations, however, need to form part of your planning and strategy to migrate your current AAP deployment to AAP 2.1.

This document provides all stakeholders responsible for planning and executing the AAP migration guidance by highlighting factors to include in your migration strategy.

This document does not provide a one-size-fits-all approach for migration. Various factors unique in your organization will impact the effort required, stakeholders involved, and delivery plan.

What to consider before migrating

We understand that many factors specific to your needs affect your migration assessment and planning. This section highlights critical factors to determine your migration readiness and what approach will best suit your organization.

Assess your current environment

There will be configurations unique to your environment, and it’s crucial to perform a thorough technical assessment. We recommend including the following:

  • Analyze your current AAP installation, including current deployment patterns, integrations, and any complexities relevant to the migration.
  • Determine changes needed in your environment to meet the AAP 2.1 technical requirements.
  • Assess stakeholder readiness to plan and execute the migration.
  • Ensure compliance, security policy enforcement, and auditin

Further reading:
Ansible Automation Platform installation guide
Ansible Automation upgrade and migration guide
Migration Technical Considerations Checklist

Potential technical barriers

Ansible Automation Platform (AAP) 2.1 introduces new requirements that will influence your migration strategy. If meeting these requirements needs significant effort, we recommend a phased migration approach.

  • AAP 2 doesn’t support isolated nodes. Automation mesh released with AAP 2.1, replaces this functionality.
  • Controller 4.1 exclusively supports PostgreSQL 12. PostgreSQL 10 is not supported.
  • AAP 2 requires Red Hat Enterprise Linux 8.3 (x86_64) or later for physical and virtual environment installations.
  • Automation execution environments replace Python virtual environments.
  • AAP 2 migration tools support the latest AAP 1.x version
  • AAP 2 requires Ansible version 2.9 as a minimum.

People, process, and technology

Your migration planning must consider the effects on the organization as a whole. We recommend the following:

  • Perform a cost-benefit analysis that outlines initial migration costs, ongoing savings, and increased revenue.
  • Identify external and internal stakeholders and establish their availability.
  • Perform a risk analysis to understand the effects on business processes and service delivery.
  • Decide on project time frames, milestones, and deliverables.
  • Assess the change management and training needed for stakeholders.
  • Establish migration success criteria and what metrics are needed to measure this.

Further reading:
Ansible Automation Platform installation guide
Ansible Automation upgrade and migration guide
Migration Technical Considerations Checklist
Content from www.ansible.com is not included.Introducing Red Hat Ansible Automation Platform 2.1 blog

What if I can’t do a complete migration right now?

There may be scenarios where a complete migration isn’t currently feasible. Ansible Automation Platform (AAP) 2.1 can be adopted in a phased approach. The method allows teams to become familiar with the new tools and reduce the number of tasks needed at migration time.

We recommend assessing the below tasks and, if it is feasible, implement them in preparation for the complete AAP 2.1 deployment.

Lower Risk Activities Medium Risk Activities Higher Risk Activities
  • Develop and test playbooks with the 2.9-based execution environment
  • Create custom execution environments from current Python virtual environments.
  • Leverage ansible-navigator and ansible-builder in workflows.
  • Integrate Red Hat Insights for Ansible: identify & prioritize high-value automation, find outliers if you think you’ve fully migrated everything to use collections
  • Create AAP 2.1 test environments for developers and operators
  • Update content to utilize Collections (FQCN)
  • Install and configure private automation hub, and use content from there
  • Update to latest AAP 1.2. The risk varies based on the AAP 1.x version targeted for upgrade
  • Update Tower nodes to RHEL 8
  • Replace isolated nodes with automation mesh execution nodes. AAP installer will make suggestions if it finds isolated nodes in the Ansible Automation Platform 1.x installer inventory file and will change them as automation mesh execution nodes in the new installer inventory. **NOTE:** Human intervention is required to take advantage of automation mesh features and to use automation mesh execution nodes as a direct replacement to isolated nodes.

Further reading:
Red Hat Ansible Platform Creator Guide
Ansible Builder Guide
Ansible Navigator Creator Guide
Migration Technical Considerations Checklist

Migration strategy considerations

You’ve completed your assessments and determined that it’s feasible to migrate to Ansible Automation Platform (AAP) 2.1. The next phase is to develop an architecture, low-level design, and delivery plan. We recommend including the following considerations during this phase.

Migrating your Ansible content

Your migration plan should assess your current Ansible automation content, such as roles, collections, playbooks, and modules, and test their compatibility with Ansible Automation Platform (AAP) 2.1. This assessment, at a minimum, should include:

  • Test and update automation content to support Ansible 2.9 or higher.
  • Technical considerations for running automation using Ansible Engine 2.9 with bundled content vs. Ansible core and certified/supported collections in execution environments.
    • Migrating to content collections is not necessary with Ansible Engine 2.9. The recommendation, however, is to migrate to content collections as soon as possible.
  • Plan, test, and port Python virtual environments (venvs) to execution environments.
    • Determine if custom execution environments are required based on the dependencies needed to execute your Ansible content successfully.
    • AAP 2.1 provides tools to assist in the migration.
  • Retain, refactor or retire existing automation content such as moving to a collection-only model or retiring content that is no longer used.

Integration into your environment and operating model

Your migration plan should include integration into existing systems. It should also assess the effects, if any, on your current operating model. Here are recommendations to include in your planning.

Content promotion workflows
  • What execution environment container versioning fits my model? Such as test, stage., latest, and release number.
  • Decide on automation hub (container registry) repository structure, such as separate repositories for testing, development, and production for content collections.
  • Should I use the hosted or a private automation hub instance?
Platform adoption
  • What support do stakeholders need to adopt and use the platform and what is the onboarding process?
  • What training and enablement is needed?
  • Who will be responsible for managing execution environments and content collections? Will this be managed centrally, per business unit or per team?
Execution environment lifecycle management
  • How should I manage and distribute ansible-builder definition files?
  • How will I update and secure my execution environments? What is the security response plan to patch CVEs and remain compliant?
Platform life-cycle management
  • How will I deploy new clusters and provide the minimum requirements?
  • How will I upgrade my clusters, and at what cadence can I do so?
  • What are the non-functional requirements, and how will this affect my design? Examples include backups, configuration management, DR, and HA.
Content distribution model
  • What automation controller design is suitable, such as deciding on multiple or single cluster deployments
  • How will I distribute content in multi-geo scenarios?
Observability, logging, and metrics
  • What metrics should be measured to determine the platform’s success?
  • What changes, if any, need to be made to ensure the platform can be audited?
  • How will the platform integrate into my existing logging and reporting systems?

Further reading:
Content from docs.ansible.com is not included.Ansible Core Documentation
Red Hat Ansible Automation Platform upgrade and migration guide
Content from www.ansible.com is not included.Developing with ansible-builder and Automation execution environments.
Migration Technical Considerations Checklist
Managing Containers in Private Automation Hub

Next steps

This document provides recommendations to inform your migration strategy. Your strategy, however, will be unique to your organization.

Acronyms used in this document

AAP Ansible Automation Platform
SLA Service level agreement
EE Execution environment
venv Python virtual environment
IaC Infrastructure-as-Code
CVE Common Vulnerabilities and Exposure
DR Disaster Recovery
HA High Availability
Product(s)
Tags
Article Type