Congratulations! You have reached the end of the RHEL In-place Upgrade Automation Workshop. You are now armed with the knowledge needed to start developing an automation solution to help your organization manage RHEL upgrades at scale.
Let’s review what we learned and think about what’s next.
With this workshop, you gained hands-on experience while learning about a prescriptive approach to automating RHEL in-place upgrades.
You upgraded only a handful of RHEL cloud instances while progressing through the workshop exercises, but with the power of an enterprise deployment of AAP, this approach can be rolled out at scale across a large fleet of RHEL hosts.
You learned why automated snapshot/rollback is one of the most important capabilities required to successfully deliver RHEL in-place upgrade automation. Snapshots not only eliminate the risk and anxiety experienced by an app team facing a RHEL upgrade, but they also help accelerate the development of robust upgrade automation playbooks.
You also learned about the custom automation that must be developed to deal with the complex requirements of a large enterprise environment. We demonstrated a few examples of this including using Leapp custom actors for reporting special pre-upgrade checks as well as running Ansible playbooks to handle common remediations and third-party tools and agents.
But the most important lesson we learned is “You can do this!”
Hopefully, this workshop has opened your eyes to what is possible, but we have just scratched the surface.
Is it possible to upgrade from RHEL7 to RHEL9? While the Leapp framework doesn’t support a “double upgrade” directly, it is possible to take a host that was upgraded from RHEL7 to RHEL8 and then upgrade it from there to RHEL9. You can try this with one of the pet app instances in the workshop lab.
There are a couple things to be aware of if you want to try it. You will first need to run the “AUTO / 04 Commit” playbook job template. This job will delete the snapshot created for your RHEL7 to RHEL8 upgrade, so be sure you are happy with everything before you do this. While rolling back to RHEL7 will then be impossible, you will be able to roll back to RHEL8 if needed after upgrading to RHEL9.
Another consideration with going from RHEL7 to RHEL9 is the increased risk of application impacts. While RHEL system library forward binary compatibility is really solid between each RHEL major version, “N+2” compatibility is not guaranteed. Of course, the only way to know for sure is try it!
All of the Ansible roles and playbooks used in this workshop are maintained in upstream repositories that can be found on GitHub. Take some time to review the code and get engaged with the communities supporting these resources.
infra.leapp
collection provides the Ansible role that generates the pre-upgrade reports and another that is used to perform the RHEL upgrades. This collection uses the Leapp framework for upgrades from RHEL7 and later, but also supports upgrading from RHEL6 using the older Red Hat Upgrade Tool. The collection is published on Ansible Galaxy here and also available from Ansible Automation Hub validated content here. If you are planning to do RHEL in-place upgrades for your organization, these roles will help you quickly roll out proof-of-concept automation and start upgrading.If you enjoyed this workshop, please take a moment to give it a 5-star rating or write a review. If you have any ideas for improvements or new features, don’t hesitate to raise an issue here tagging @swapdisk and @heatmiser. All ideas and feedback are welcome!
Navigation