Automating your CentOS Linux to RHEL migration

The end of life (EOL) for CentOS Linux 7 is approaching, with updates ending on June 30, 2024. This impending deadline signifies the end of security updates and maintenance, posing significant risks for organizations that continue to rely on the outdated operating system. Upgrading to a more current and supported platform, such as Red Hat Enterprise Linux (RHEL), is needed to maintain an up-to-date security posture and  continued functionality.

Migrating these systems, which may play a critical role in your organization’s IT infrastructure, is not trivial. Red Hat Ansible Automation Platform can help streamline and automate this process, however, reducing the complexity, while enabling scalability and the ability to orchestrate changes to the surrounding infrastructure to support the migration.

In this article I explore what is possible when using Ansible Automation Platform to drive this migration at scale across your organization and the steps needed to achieve this.

Migrating from CentOS Linux to RHEL

Sure, logging into a CentOS Linux system and starting the Convert2RHEL command line process is pretty easy. But what about doing this with multiple systems? What about all the infrastructure dependencies that might be in place?

Using Ansible Automation Platform for this process helps you address scale and dependencies while allowing you to build a logical workflow for your migration. What's more powerful than converting at scale? Remediations at scale! We can automate the remediation of all those blockers.

We often refer to Ansible Automation Platform as simple and powerful, but its true superpower is covering multiple domains and use cases. We can automate the migration process, but we can also use the multidomain aspect to address infrastructure and platform dependencies.

Let's look at a typical example of a system in use that we now want to migrate to RHEL. I have a set of application servers hosting my streaming application. These systems do not operate in isolation — there could be firewalls, load balancing and even connectivity to databases involved. There could also be other pre-work needed. I might need to:

• Update dependent systems
• Back up the data or snapshot the system
• Remove systems from notifications in our monitoring solution
• Open a service ticket in our ITSM before we even get started

With operational knowledge of everything we need to do, we can build our Ansible Playbooks and standardize the process for consistency. Using Ansible Automation Platform gives us the ultimate “ops-life” hack by providing Red Hat Ansible Lightspeed, our generative AI for playbook creation. We can take our knowledge and let Ansible Lightspeed help us build our playbooks faster while following best practices.

Once we have our content created, we can then use the automation controller to build out an automation workflow and map out the process logically before we proceed with automating the actual Convert2RHEL process.

Before we move on, I want to point out a crucial component of this workflow: The ability to automate snapshots of the systems. This is important for both the CentOS Linux migration to RHEL and the automated upgrade of RHEL. I will show you an example from our Ansible validated content for infra.lvm_snapshots when we discuss the RHEL upgrade.

Now, what about the actual process of converting our systems? With our Ansible Automation Platform subscription, we have access to Ansible validated content which provides expert, opinionated automation content all sitting in Ansible automation hub on console.redhat.com.

We will use the infra.convert2rhel collection to get started. This collection provides roles that we can use to perform the conversion using the Convert2RHEL framework. Using the sample playbook provided in the Ansible validated content, I can simply add this to my workflow and have it start the migration once the pre-work tasks have been completed.

---
- name: Convert CentOS Linux to RHEL
hosts: centos
strategy: free
become: true
force_handlers: true
vars:
  rhsm_username: "{{ rhsm_username }}"
  rhsm_password: "{{ rhsm_password }}"
  rhsm_org: "{{ rhsm_org }}"
  rhsm_activation_key: "{{ rhsm_activation_key }}"
tasks:
  - name: Perform OS conversion
    ansible.builtin.import_role:
      name: infra.convert2rhel.convert

If you look at the sample playbook, it's important to note the use of a strategy. If you are not familiar with this, this enables us to control how tasks are executed across the hosts. In our example, we use strategy: free -  which allows tasks to be executed as soon as possible without waiting for other hosts, and it runs each host independently. This is ideal for upgrading multiple machines at scale.

As soon as we migrate our systems, we can utilize Ansible Automation Platform to automate testing and check ports and configurations as the last step in your migration to RHEL workflow.

“RHEL-come” to Enterprise Linux!

Once our CentOS Linux systems have been migrated, we will now be on RHEL 7.  It is recommended to then upgrade to RHEL 8 with a similar process—we use the LEAPP upgrading tool framework to assist us. Red Hat also offers an Extended Life Cycle Support (ELS) add-on subscription for RHEL 7 systems, for more information, refer to Announcing up to 4 years of Extended Life Cycle Support (ELS) for Red Hat Enterprise Linux 7. 

Just like Convert2RHEL, Red Hat provides the Ansible validated content for infra.leapp. The infra.leapp content contains roles that assist our pre-upgrade steps, like generating the pre-upgrade report, remediating roles for common issues/inhibitors and upgrading our systems.

When we upgrade between major versions of RHEL, we typically use LEAPP to assess the systems and create a pre-upgrade report. LEAPP will collect data and provide a report on potential issues/inhibitors with possible suggestions to resolve them.  While we can use the Ansible Role to remediate common issues found by LEAPP, however, third party dependencies or perhaps some configuration changes might need to be resolved separately. 

Step 1: Assessing your systems

We can turn to Ansible Automation Platform again to streamline the remediation process of our systems by taking the issues in the report, building a remediation playbook and applying the changes at scale to the systems we want to upgrade. Furthermore, we can utilize Ansible  Lightspeed to generate some of the remediation if we are unsure about the tasks needed.

Example: Our systems had an inhibitor for root remote login and we used Ansible Lightspeed to build the remediation for that:

Step 2: Trigger the upgrade:

We can deploy our playbooks with a workflow at scale, even around the globe, with the use of technologies like automation mesh, which is part of the Ansible Automation Platform. 

Using our Ansible validated content, we can create snapshots of our LVM’s so we can revert back should something fail during the next upgrade step.

---
- name: Create/revert/remove/check LVM snapshots of node
hosts: "{{ rhel_inventory_group | default(omit) }}"
become: yes
environment:
  LANG: en_US.UTF-8
  LC_ALL: en_US.UTF-8
  TERM: linux
tasks:
  - ansible.builtin.set_fact:
      snapshot_create_set_name: "{{ snapshot_set_name }}"
      snapshot_remove_set_name: "{{ snapshot_set_name }}"
      snapshot_revert_set_name: "{{ snapshot_set_name }}"
  - name: "Execute snapshot check"
    ansible.builtin.include_role:
      name: "infra.lvm_snapshots.snapshot_create"
    vars:
      snapshot_create_check_only: true
      # Additional snapshot_* vars provided via AAP2 job template and associated surveys
    when: lvm_snapshots_action == "check"
  - name: "Execute snapshot {{ lvm_snapshots_action }}"
    ansible.builtin.include_role:
      name: "infra.lvm_snapshots.snapshot_{{ lvm_snapshots_action }}"
      # Additional snapshot_* vars provided via AAP2 job template and associated surveys
    when: (lvm_snapshots_action == "create") or (lvm_snapshots_action == "remove") or (lvm_snapshots_action == "revert")

Once we have our snapshots, we can upgrade our RHEL system using content from our Ansible collections.

---
- name: Upgrade
hosts: "{{ rhel_inventory_group | default(omit) }}"
strategy: free
become: true
force_handlers: true
# vars:
#   ansible_python_interpreter: /usr/libexec/platform-python
tasks:
  - name: Perform OS upgrade
    ansible.builtin.import_role:
      name: infra.leapp.upgrade
...

As soon as a system has been upgraded, we can use Ansible Automation Platform to check the state of the system. If everything is good, we can also use automation to bring the systems back into production.

Step 3: Post-upgrade add-ons

Our upgrades are done, but we can still do more with Ansible Automation Platform. Post-upgrade configuration and integration can take place as part of our automation workflows, streamlining all the additional tasks we often forget about when upgrading systems. Ansible Automation Platform allows you to integrate your new RHEL system into Red Hat Insights, simplifying compliance checks and enforcement. We can also configure Performance Co-Pilot to report system metrics to Event-Driven Ansible and just about every other Day 2 task you could think of!

Automation analytics can help provide clarity on the automated process or help us identify possible anomalies in the hosts during the process, which we can then address later.

Learn more

• This exercise is from a workshop provided by Red Hat - Check out the code
• Try Ansible Automation Platform free for 60 days
• Learn how to automate on the platform with our self-paced labs
• Check out the action on our YouTube Channel