Month: October 2021

Clear your schedule: @Steve_Will_IBMi will be speaking about #IBMi next generation applications at this year’s RPG & DB2 Summit. Click here to register. @SiDforIBMi ow.ly/cFcu50GoCmU

– Skytap (@Skytap)08:55 – Oct 11, 2021

Since the earliest days of OS/400, job scheduling has been practiced in IBM i environments, its functionality improving in recent releases. And while you have a great collection of built-in job scheduling features at your disposal, you can do even more if you license the IBM i Advanced Job Scheduler or a third-party utility.

Red Hat Ansible Automation Platform 2 introduces an updated architecture, new tools and an improved but familiar experience to automation teams. However, there are multiple considerations for your planning and strategy to migrate your current deployment to Ansible Automation Platform 2.

This document provides guidance to all of the stakeholders responsible for planning and executing an Ansible Automation Platform migration guidance with factors to address in your migration strategy.

This document does not provide a one-size-fits-all approach for migration. Various factors unique to 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 Ansible Automation Platform installation, including current deployment patterns, integrations and any complexities relevant to the migration.

Determine changes needed in your environment to meet the Ansible Automation Platform 2 technical requirements.

Assess stakeholders’ readiness to plan and execute the migration.

Check for compliance, security policy enforcement and auditing.

If you would like to dig into this deeper, you can check out some further reading:

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

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 2 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 Ansible Automation Platform 2 deployment.

       Lower Risk Activities

    Medium Risk Activities

            Higher Risk Activities

Develop and test playbooks with the 2.9-based execution environment.

Create custom automation execution environments from current Python virtual environments.

Leverage ansible-navigator and ansible-builder in workflows.

Integrate Red Hat Insights for Ansible to identify & prioritize high-value automation. 

Create Ansible Automation Platform 2 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 Ansible Automation Platform 1.2. The risk varies based on the AAP 1.x version targeted for upgrade

Update AnsibleTower nodes to RHEL 8

Replace isolated nodes with container groups. If migrating from Ansible Automation Platform 1.2 directly to Ansible Automation Platform 2.1, this step is not necessary.

If you would like to dig into this deeper, you can check out some further reading:

Red Hat Ansible Platform Creator Guide
Ansible Builder Guide
Ansible Navigator Creator Guide

Migration strategy considerations

You’ve completed your assessments and determined that it’s feasible to migrate to Ansible Automation Platform 2. 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 2. 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 Ansible Content Collections is not necessary with Ansible Engine 2.9. The recommendation, however, is to migrate to Ansible 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. Ansible Automation Platform 2 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 Ansible 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 Common Vulnerabilities and Exposure (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, disaster recovery (DR), and high availability (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:

Ansible Core Documentation
Blog: What’s new in Ansible Automation Platform 2: automation content navigator
Blog: What’s new in Ansible Automation Platform 2:  private automation hub

Next steps

Please review the official Ansible Automation Platform 2.0 documentation

We also encourage you to register for our free upcoming webinar “Red Hat Ansible Automation Platform brings you a new way to automate,” which will be live on November 4 and available afterwards on demand.
Red Hat offers expert guidance and services to help you on this journey. Please reach out to your local Red Hat representative for more information.

Post Content