Automated Satellite Workshop: CentOS/RHEL migration and upgrade

Read this in other languages:
uk English, france Français.

Introduction
This use-case will focus on conversion from CentOS (though this could be another RHEL derivitive) to RHEL while maintaining a 3 tier application stack (do no harm). While we only show this process for a few systems, it can be scaled to a larger number of physical, virtual or cloud hosts using content repos provided by Red Hat Satellite (included in Red Hat Satellite). The conversion process will be driven with automation built and run using Ansible Automation Platform.

Environment

Exercise Scenario

Overview

Summary

Things to consider if doing this in dev/test/stage-beta/prod:

A Note about using Satellite vs. Ansible Automation Platform for this…
Out of the box, Satellite 6 supports RHEL systems roles (a collection of Ansible Roles) for a limited set of administration tasks. Satellite can be used to do OS conversions and upgrades, however an Ansible Automation Platform Subscription is required to execute complicated OS conversions and upgrades that require logic to meet up-time requirements. Using these two solutions together ensures you have the best tool for the job for:
- Content Management (Satellite)
- OS Patching & Standardized Operating Environments (Satellite)
- Provisioning: OS, Infra Services and Applications/Other (Satellite and/or Ansible Automation Platform)
- Configuration of Infra and Apps (Ansible Automation Platform)

Reference: Converting CentOS to RHEL with Red Hat Satellite 6 and Leapp Upgrade with Satellite 6

Ok, let’s get started…

Pre-requisites

Exercise:

Login to your Satellite & AAP UI’s

NOTE The following are example URLs. Your student lab URLs will be different.

  • Ansible Automation Platform URL
    Example: https://student1.{random}.example.opentlc.com*
  • Satellite URL
    Example: https://student1-sat.{random}.example.opentlc.com (Note the -sat added to the URL)*

Note that in the following steps that are being performed on AAP, at any time, over on the Satellite console, review the registered hosts via clicking Hosts => All Hosts. Refresh the Hosts page to see changes as they occur a result from the automation being performed via AAP.

Steps:

1. Logging into the Ansible Automation Platform (AAP)

login screen

2. Install Three Tier Application Stack

3tier-install

template-copy

template-edit

centos-snapshot

4. Verify three tier application functionality on CentOS nodes - pre Centos update

3tier-smoketest

5. Upgrade CentOS nodes to latest version

centos-update

6. Verify three tier application functionality on CentOS nodes - post Centos update, pre Convert2RHEL

3tier-smoketest-2

7. Convert2RHEL - CentOS7 Development nodes to RHEL7 Development nodes

NOTE with some pre-configuration, any combination is possible conversion-select

  • click Next to continue conversion-confirm
  • confirm CentOS and RHEL LE variables set via survey selections and click Launch conversion-complete

If you look in Satellite now (Hosts > All Hosts), you will see that all CentOS notes have been converted to RHEL 7.9 nodes.

3tier-smoketest-2

8. Query Satellite to get post conversion node-related details, set EC2 instance tags based on these details

9. Update inventories via dynamic sources

10. Create a converted RHEL credential

credential-copy

converted-RHEL-credential

11. Copy template CONVERT2RHEL / 97 - Three Tier App smoke test to template CONVERT2RHEL / 97 - Three Tier App smoke test / RHEL7 Development

template-copy

3tier-smoketest-3

The Three Tier App smoke test template should have completed successfully, which shows that we were able to complete the migration from CentOS 7 to RHEL 7, and when that process finished, our 3 tier application still functioned.

EXTRA CREDIT - Convert2RHEL workflow template Create a workflow template incorporating the above standalone templates into a complete CentOS to RHEL conversion workflow!

EXTRA CREDIT - Infrastructure-as-Code “Choose Your Own Adventure”

  • Fork Automated Satellite repo to individual GitHub account Before we begin, you’ll need to fork the Automated Satellite repo into your personal GitHub account. If you do not have an individual GitHub account, you will need to create one to proceed. Utilization of a source code management (SCM) system is central to the “infrastructure as code” concepts put forth in this lab exercise, and in this case, GitHub is our SCM.

Once logged into GitHub navigate to the Red Hat Partner Tech repo for Automated Satellite repo. Next, on the Automated Satellite repo page, in the top, upper right of the page, click “Fork”. This will create a “forked” Automated Satellite repo in your personal GitHub account.

Switch the “Automated Management” project in AAP to utilize your newly cloned repo. The following files are some good places to start looking to see where you can adjust the Extra Vars instance tags to select/filter what particular instances that a job template/playbook gets run against:

group_vars/control/inventories.yml

group_vars/control/job_templates.yml

Once the updates are made, commit and push these changes to the cloned repo, followed by running the “SETUP / Controller” job template, which will propogate the changes to AAP itself. …