In this exercise, we will demonstrate rolling back one of our pet app servers, just as we would if the RHEL upgrade had failed or if we had found the upgrade caused unexpected impact to the application.
We are now here in our exploration of the RHEL in-place automation workflow:
After rolling back, the pet app server will be restored to as it was just before entering the upgrade phase of the workflow.
In this step, we will be rolling back the RHEL in-place upgrade on one of our pet application servers.
Return to the AAP Web UI tab in your web browser. Navigate to Resources > Templates and then open the “AUTO / 03 Rollback” job template. Here is what it looks like:
Click the “Launch” button which will bring up the prompts for submitting the job starting with the limit and variables prompts. We only want to do a rollback of one server. To do this, enter the hostname of your chosen pet app server under the “Limit” prompt. For example:
Click the “Next” button to proceed.
Next we see the job template survey prompt asking us to select an inventory group. We already limited the job to one server, so just choose the “ALL_rhel” option and click the “Next” button. This will bring you to the preview of the selected job options and variable settings, for example:
If everything looks good, use the “Launch” button to start the playbook job.
After launching the rollback playbook job, the AAP Web UI will navigate automatically to the job output page.
The automated rollback takes only a few minutes to run. You can monitor the log output as the playbook run progresses.
When the job has finished running, scroll to the bottom of the job output. If it finished successfully, you should see “failed=0” status in the job summary like this example:
Notice in the example above, we see the job completed in just under 3 minutes. However, most of that time was spent in the final “Wait for the snapshot to drain” task which holds the job until the snapshot merges finish in the background. The instance was actually rolled back and service ready in just under a minute. Impressive, right?
Repeat the steps you followed with Exercise 2.3: Step 2, this time to verify that the RHEL version is reverted back.
For example, if the pet app host you rolled back had been upgraded from RHEL7 to RHEL8, you should now see it is back to RHEL7:
In this exercise, we used automation to quickly reverse the RHEL in-place upgrade and restore the app server back to its original state.
In the next exercise, we’ll dig deeper to validate that all changes and impacts caused by the upgrade are now undone.
Navigation