Introduction to Application Streams in Red Hat Enterprise Linux

Red Hat Enterprise Linux 8 comes with a new feature called Application Streams (AppStreams), in which multiple versions of packages are provided, with a known period of support. These modules can be thought of as package groups that represent an application, a set of tools, or runtime languages.  Each of these modules can have different streams, which represent different versions of software, giving the user the option to use whichever version best suits their needs. Each module will also have installation profiles, which help to define a specific use case, and will determine which packages are installed on the system.
Estimated timeline of support
Modularity and AppStreams provide users access to newer versions of software while being supported longer. In the past users would typically have one or two versions to work with throughout the lifecycle of the operating system. Now users will have more choices when it comes to versions of popular languages and tools.
RHEL 8 and RHEL 7 appstreams illustration
Starting with RHEL 8, Red Hat Software Collections along with Extras, Dotnet, and Devtools will be moved into and replaced by the Appstream repository. 

Installing Applications via Modules

First things first, let’s take a look at which modules are currently available after a fresh installation of RHEL 8. We can display modules using yum and see what modules and AppStreams are available to us.
# yum module list                                    # lists all modules
yum module list results
As we can see there are quite a few already provided in the base installation. For our demonstration, we are going to use one of the PostgreSQL modules. Let’s take a look at which versions or AppStreams are available for PostgreSQL.
# yum module info postgresql          # lists all modules for postgresql
From this output, we can see there are several AppStreams of PostgreSQL to work with. For now, we are going to use stream 10, or version 10 of PostgreSQL, as it’s the default.
# yum module info postgresql
Each module will display pertinent information including stream version, profiles, reports, summary, description, and artifacts. We’ll delve a little deeper into some of these later, but for now, we can see the stream version as 10, which also has a [d] and [a] next to it. These mean that this module version is the [d]efault and [a]ctive version that will be installed should a user attempt to install PostgreSQL via yum. If no stream is specified, the default and enabled one will always be installed. Here is an example that we can break down to show all the options.
# yum install @module:version/profile
  • @module defines which module we are going to use.
  • :version specifies which stream we are going to use for the specified module. 
  • /profile tells us which profile to use. If no profile is specified, the default one is used. If no default is defined, then the module is only enabled but no packages are installed.
Let’s go ahead and install the PostgreSQL module using just the defaults.
# yum install @postgresql   # installs the default, PostgreSQL 10 module
# yum install @postgresql   # installs the default, PostgreSQL 10 module
Since we did not specify a stream or a profile, we can see that the defaults were used for both AppStream and profile. What if we don’t want to use the defaults then? Let’s continue to see how we switch between different AppStreams and profiles.

Switching between different AppStreams in a module

A common challenge that Red Hat system administrators face are requests to install newer versions of applications then are included in the base RHEL repositories. With modules, we can seamlessly change between available versions of a particular RPM. How is that different from Red Hat Software Collections you might ask? Software Collections keeps multiple versions on one system, putting each package into separate namespaced paths. Modularity uses the standard RPM packaging, so paths are where you expect them to be. Keep in mind, unlike Software Collections, modules do not allow running multiple versions at the same time. Only one stream can be installed and used at a time.   We’re going to continue to use PostgreSQL, but for this example, our application team is requesting we move to a newer version. Let’s see which AppStreams of PostgreSQL are available to us.
# yum module info postgresql              # Lists all AppStreams available 
# yum module info postgresql              # Lists all AppStreams available
Here we can see there is a newer version of PostgreSQL available to us through modules. Before we can go ahead and install a newer version of PostgreSQL, we will need to reset the current module used and then install the newer version, specifying the stream.
# yum module reset PostgreSQL                    #Resets postgresql module
# yum module reset PostgreSQL                    #Resets postgresql module
As you can see when we reset the module, the streams of that module are set to their initial state, neither enabled nor disabled. If a module has a default stream, in this case stream 10 for PostgreSQL, then it becomes active after the reset. Now we can specify a newer stream and in this case, since there are no default profiles, we are going to select the server one. In the event, a stream does not have a default profile specified with a [d] next to it, if we do not specify a profile, the stream will be enabled but no packages will be installed.
# yum module install postgresql:12/server            #Installs stream 12 
# yum module install postgresql:12/server            #Installs stream 12
We can see that stream 12 has been enabled, the server profile will be used, and the PostgreSQL version 12 packages will be installed. If you wish to revert back to a previous stream, you just reset the profile as before and specify an earlier stream during install.

Related Posts

Comments are closed.