In this section you will learn about important concepts and features to be aware of when building, deploying & supporting workloads on Red Hat Enterprise Linux 8

Life Cycle

Awareness of the Red Hat Enterprise Linux 8 life cycle is important when planning and releasing your own products. There are four life-cycle phases, from full support to extended life phase. For more details please review the Red Hat Enterprise Linux 8 Life Cycle documentation.

RHEL 8 Life Cycle Documentation

Minor Releases and Errata

When releasing and supporting workloads on RHEL 8 it’s important to understand the cadence of releases and the kernel versions that shipped with them, along with updates or errata.

RHEL has a predictable six month release cadence, and updates are done as needed.


An integral part of building and supporting products on Red Hat Enterprise Linux is understanding the packages available and supported in Red Hat repositories. The two main repositories are called BaseOS and Appstream, these are the only two fully supported repositories. Developers will be interested in using the CodeReady Linux Builder repo, which houses a number of common developer tools to assist in building applications on RHEL, but they are not to be carried over into production as they are not supported.

Application and Library Compatibility

Understanding the stability of applications and libraries written for RHEL is critical in making sure the dependencies required of workloads are in place.

The API and ABI compatibility guide provides software developers with Red Hat's guidelines regarding support of third-party applications across multiple releases of the Red Hat Enterprise Linux platform. Losing support for application dependencies means the partner has to ship and support these dependencies themselves or re-work the code base to use an alternative dependency that is supported. ISVs can reduce or avoid migration issues between major and minor Red Hat Enterprise Linux versions by following these guidelines during application development.

All components and packages are classified under 1 of 4 compatibility levels. For more the details reference the RHEL 8 Application Compatibility Guide below.

Value in Using RPM and YUM Repos

Touting the values of RPM may seem like an antiquated Red Hat narrative, but to this day RPM still provides many advantages over distribution of software with tarballs and other conventional archive files. In fact RPM, especially if constructed well with adherence to best practices, makes deployment and management of software products much easier.

Also, it should be noted a well organized RPM based application is better suited for the journey to containers and microservices as separation of configuration, code, and data with awareness of versioning, provenance and dependencies help with portability and lifecycle. One of the biggest advantages of containers are found with the portability they provide and the ease in which to manage the lifecycle of individual components.

You may use RPM to distribute, manage, and update software that you create for RHEL, CentOS Stream and Fedora. YUM/DNF commands provide the way to keep a system updated and provide dependency resolution. YUM repositories maintain a list of RPMs on the system and where to get updates. RPM and YUM work together.

Migrating From an Older Version

We commonly hear from customers that they are unable to upgrade to our latest major RHEL releases because ISV products they rely on do not support the latest version. Understanding how to migrate from an older version of Red Hat Enterprise Linux to the latest version is important for not only our customers, but our partners as well.

The LEAPP migration utility was designed to help identify application dependencies, find alternatives for deprecated packages and move to the latest version of RHEL.

Converting From Another RPM Distribution

Many software shops incubate a project with CentOS or another RPM based distribution, but once the product is released they find out the product is widely unusable by many enterprises who require support for Red Hat Enterprise Linux. Additionally, with the upstream shift in CentOS to CentOS Stream, it is more important than ever for our partner ISVs to build with and support Red Hat Enterprise Linux. If your product is packaged as RPM for CentOS or another distribution such as Oracle Linux ISVs should convert.

Core Technologies for Containers

RHEL 8 is both a development sandbox for containers and a fantastic single-node container deployment platform. Sometimes the need for a full blown kubernetes based orchestration platform is not needed or it’s deemed too difficult given the skill set available at the company. There is a reason why containers were born from Linux. Core technologies such as Control groups, namespaces and SELinux are used to implement containers, and they aren’t new concepts.

Control Groups or C-Groups is kernel feature that isolates and controls the resource usage of user processes. These processes can be grouped into Namespaces in order to share the same resource limitations. The isolation of processes, and resources are foundational to containers.

OCI Container Tools for RHEL 8

Along with the fundamental core technologies on which container principles are based, covered in the previous section, RHEL 8 is packed with container modernization tools.

There are command line tools that operate without a container engine such as podman, buildah, and skopeo. Again, when using RHEL as a sandbox for container development or using it as a single node deployment platform these tools provide developers and system administrators with out of the box functional capabilities.

Last updated