Many roads lead to RHEL 8 – Part 2

Photo by NASA on Unsplash

In the first part of the article “Many roads lead to RHEL” we were discussing the possibility of doing an in-place Upgrade instead of redeploying a new RHEL machine when switching to a new major version of RHEL. We also touched on the reasons why it does make sense to sometimes consider doing an in-place Upgrade. Especially if you have snowflake Systems with unique configurations it is worthwhile to consider doing the switch to a new major version in-place.

The intention of this post is merely to talk about the technical possibilities to do so and is not touching on the thought process whether to upgrade in-place or redeploy. This is a topic for another conversation. 

As we are already aware of the required tooling for upgrading to RHEL 8 and also know about the phased approach behind the tooling (if not consider reading Part 1) we will focus on the tools that make this whole process even simpler by providing the possibility to visualize the necessary steps better, or even scale the whole process for a couple of systems and not just one. 

Best case you can cluster servers and treat their migration as one. 

With that being said I will start by exploring the possibilities to visualize the upgrade process and the second way of doing the upgrade on one machine. Let’s start with Cockpit.

What is Cockpit?

You might wonder what Cockpit has to do with upgrading to a new major version. Well, let’s briefly discuss what Cockpit is in general.

Cockpit is a graphical user interface for administrating your Linux Server. The UI is web based, so you do not need any client or graphical terminal to your Server, just a Web Connection through your Browser. Its intent is to be an administrative touchpoint for every user, from beginner to expert. Therefore it uses system APIs that are already there and does not reinvent the wheel. It runs as a systemd socket connection and is available for access on https://localhost:9090. After logging in you can administrate your system from your Browser. There is lots of functionality already available and so are multiple Add-Ons you can activate on demand. One of those Add-ons for instance is Leapp, which allows you to do the in-place upgrade from your server just like we discussed in Part 1. Let’s dive in and see this in action.

Preparing and doing the upgrade in Cockpit

Assuming you have not installed Cockpit on your server let’s start from scratch and install our Cockpit Web Service. 

# yum install cockpit cockpit-dashboardCode language: PHP (php)

After installing our Web UI we go ahead and enable it and just take a look. 

# systemctl enable cockpit.socket
# systemctl start cockpit.socket
Code language: CSS (css)

Now this looks good 🙂

After logging in you see on the left side lots of options to manage your system from Networking, to Storage up to SELinux and a terminal if you want to use the CLI to do some advanced configurations. As we are still missing the Leapp add-on we go ahead and install the add-on. I just assume you have Leapp itself already installed, which we obviously need. All the necessary steps are covered here.

# yum install cockpit-leappCode language: PHP (php)

After refreshing the Browser you can see that we have another Item in the left navigation Bar called “Upgrade Report”

If you click on a remediation Hint in the description Column you will get a small description of the issue as well as a possible hint on how to remediate this before or after the upgrade.

We also see that we have one Inhibitor, which is actually blocking the upgrade from happening. So this needs to get resolved in order to proceed. We have the possibility to apply a filter to what we see. Let’s focus only on the inhibitors for demonstration purposes. 

One Inhibitor is showing up and if you filter for “Has a remediation command” you get the issues for which you can implement an automatic remediation plan that you can run from the web console.

What are the benefits of using Cockpit for the upgrade?

So that was just a small Walkthrough on enabling cockpit and the leapp add on and on running the upgrade report through the web console terminal plus reviewing the generated upgrade report. If you execute the upgrade you will run the upgrade either from the command line or the terminal in the web console. 

What value does Cockpit bring me here. Obviously it brings the possibility to review the upgrade report in a human readable format and additionally the possibility to generate a remediation plan and execute it on the machine where possible. 

So this is nice for one system, but what do I do if I have 10s or hundreds of systems with the same special configuration and I need to scale the upgrade process?

This can be done through automation and also using Satellite, which also has a leapp upgrade plugin that enables the administrator to do the things just seen but on a bigger scale. 

What is Satellite?

If you are in need of a Tool that can help you with provisioning, subscription management, patching and lifecycle management, then Red Hat Satellite is the way to go.

It is part of Red Hat’s Smart Management Solution and delivers an infrastructure management tooling that does all of the above and more at scale. 

And in our case we want to run leapp at scale and bring more than just one virtual server to a new up to date version of RHEL. Same as with cockpit you are able to install a plugin in Satellite that will allow you to just do that.

Preparing and doing an Upgrade in Satellite?

It takes only one command to enable the Leapp Plugin in Satellite. So let’s do this:

# satellite-installer --enable-foreman-plugin-leappCode language: PHP (php)

After that you will be able to see the added functionality in the web-console of Satellite.

You can see the newly available actions in the following screenshot. I selected two RHEL Systems with Version 7.9 and could select in Satellite for them to run the pre upgrade checks.

Running the pre upgrade check will result in the green circle you can see on the next screenshot. That means, that the checks completed on both systems remotely and you are now able to review the reports for both systems in the web console.

We are able to take a look at our reports now. Let’s go for it. You can see the outcome of the reports we actually already know from the other ways to upgrade our RHEL System. As well as in Cockpit we see a nice human readable report with many descriptions and lots of detail, explanations and hints on what we have to do to prepare our systems for the upcoming upgrade procedure. The difference is that we see reports for more than one system. 

But let’s just focus on one system for a moment. In the next screenshot you will see a small description of an inhibitor and actually the possibility to let Leapp take care of the inhibitor for you. We are going to select it and let the remediation plan run. 

Next you see a screenshot of the plan running on the virtual machine we selected before.

After having taken care of the remediations on all the systems involved we can go ahead and start the Upgrade of our systems. The beauty of the Satellite plugin is that you can let the remediations run on all the systems in parallel, which is more efficient than having it run on one system at a time. If you have done a good job in grouping your systems and have lots of similar systems you can use the findings as a blueprint for automating all the shown tasks even more. Fast forward to the end of the upgrade we will take a look at one of the machines and we can see in the overview page of the system that although we had a 7.9 system image and also a 7.9 RHEL machine it is showing us now the new release Version 8.4 we upgraded to.

Conclusion

What are the benefits of doing the upgrade with Satellite or Cockpit instead of doing it directly on the machine? Well one big advantage is the visualisation of inhibitors, risks and the easy view on some remediations, that can help me prepare everything for the in-place upgrade to go smoothly. Focusing on the advantages of Red Hat Satellite in specific, we can summarise that it is an enabler for scaling our efforts. That is especially useful if you have more than one machine with similar configurations and also similar remediations that have to be done beforehand. Lots of the manual work gets automated and you can trigger the processes in parallel. The human readable reports that offer a base for automating remediation plans are another huge plus and help us achieve our goals faster and more conveniently. You can have one touchpoint for your efforts and do not have to change to a different machine. 

When you think about the huge task that lies ahead, when doing a whole project where a huge amount of systems needs to be transformed to a new version, you really need to find a way to split up this big challenge into smaller chunks that are easier to handle. You can then approach the project one step at a time and learn in each step what did go well and what did not. After that you can adapt the approach and reiterate the cycle. The software functionalities and features described in both articles are just the tools you can use to accomplish your goal faster and more conveniently.