UBI: Using RHEL-based Image for Kubernetes Workload

Introduction

A Universal Base Image (UBI) is a type of container base image that Red Hat created and maintains. The idea behind UBIs is to allow developers to build, share, and collaborate on containerized applications that can run anywhere while still being fully supported. With UBI, you can use the trusted and standardized images from Red Hat to build your containers and still be able to redistribute those containers freely.

UBIs are part of Red Hat’s container offerings, based on the same codebase used for Red Hat Enterprise Linux (RHEL). What makes them particularly appealing is that they are freely redistributable without a Red Hat subscription, providing a secure and stable starting point for building containerized applications.

Using UBIs can give organizations the confidence that they are compliant with licenses and that the base images are receiving regular updates and security patches from Red Hat. When these containers are run on RHEL or with Red Hat OpenShift, they can benefit from Red Hat support, but they can also be run on non-Red Hat platforms without the support benefits.

History

The creation of Universal Base Images (UBI) by Red Hat addresses a couple of key concerns in the container ecosystem.

Licensing and Redistribution

Traditionally, base images derived from enterprise Linux distributions could be subject to licensing restrictions, making it challenging for developers to share their containerized applications without violating terms. UBIs remove this barrier by allowing developers to freely share their UBI-based containers, even if they are not Red Hat customers.

Security and Reliability

UBIs are maintained by Red Hat, which means they benefit from Red Hat’s focus on security and stability. These images are regularly updated with security patches, bug fixes, and enhancements.

Standardization

Using UBI helps maintain consistency across different environments. As UBIs are based on RHEL, developers can expect a consistent experience and compatibility when building and deploying applications on various platforms.

Support

While UBIs can be run anywhere, when they are used on Red Hat platforms like RHEL or OpenShift, users can benefit from Red Hat’s support if they have a subscription. This support can be crucial for enterprises that need assurance of timely help with any issues.

Enterprise Adoption

It encourages enterprise adoption of container technology by offering a pathway to an enterprise-grade Linux container base image that is freely available but can be fully supported under a Red Hat support agreement.

UBI vs Debian vs Alpine

Choosing Universal Base Images (UBI) over other distributions like Debian Slim or Alpine often depends on several factors tailored to organizational needs, preferences, and existing infrastructure. Here are some reasons why one might prefer UBI:

Compatibility with Red Hat Enterprise Linux

UBI is based on RHEL, which is widely used in enterprise environments. If your production environment uses RHEL, using UBI ensures that your containers are compatible with your production environment, reducing the chances of encountering unexpected behaviors due to differences between the development and production environments.

Support

Red Hat offers support for containers built with UBI when they are run on a supported Red Hat platform. This can be a significant advantage for businesses that already rely on Red Hat’s support services and want the same level of support for their containerized applications.

Security and Compliance

Red Hat has a strong reputation for providing timely security updates and for focusing on security and compliance, which is critical for enterprise environments. Companies with stringent security requirements might opt for UBI to leverage Red Hat’s security practices.

Enterprise-Grade Stability

Red Hat curates UBI images for stability, which is a priority for enterprise operations. Organizations that need a guarantee of long-term support and a stable upgrade path might find UBI a more suitable choice.

Ecosystem

For organizations deeply invested in the Red Hat ecosystem, including OpenShift for container orchestration, UBI is a natural fit. It ensures smooth operation and integration with their Red Hat products.

On the other hand, someone might choose Debian Slim or Alpine for:

• Size: Alpine is known for its minimal size, which makes it an excellent choice for minimalistic container environments. Smaller images result in faster pull times and reduced surface area for potential security vulnerabilities.
• Simplicity: Debian Slim offers a pared-down version of Debian that is still comprehensive enough to include many necessary tools and libraries, providing a balance between functionality and size.
• Portability and Flexibility: Both Alpine and Debian are not tied to a specific enterprise vendor, which might be preferable for those looking for vendor-neutrality.

Use Case

The best case for using Universal Base Images (UBI) typically involves scenarios where enterprises require a robust, secure, and well-supported container ecosystem that aligns with their existing infrastructure and workflows, especially those centered around Red Hat products. Here are some specific use cases where UBI would be an optimal choice:

1. Enterprise Environments: Organizations already running Red Hat Enterprise Linux (RHEL) will find UBI to be a seamless fit for developing applications that will be deployed on RHEL or OpenShift, ensuring compatibility and support.
2. ISV (Independent Software Vendor) Applications: Vendors who distribute their applications as containers and want to ensure that these containers are compatible with enterprise environments may use UBI as their base image. This compatibility can make it easier to sell their software to enterprises that use RHEL.
3. Multi-Cloud Deployments: For businesses that aim for consistency across various cloud providers while maintaining the option of enterprise support, UBI provides a common ground. It facilitates a uniform deployment experience whether the containers are running on-premises, in a public cloud, or in a hybrid cloud setting.
4. CI/CD Pipelines: In continuous integration and continuous delivery (CI/CD) pipelines, using UBI as a base image can ensure that the testing and deployment environments are as close to the production environment as possible, which is particularly important if the production environment is based on RHEL.
5. Regulated Industries: In sectors like finance, healthcare, or government where regulatory compliance and security are paramount, UBI’s alignment with Red Hat’s security and certification processes can help in meeting those compliance requirements.
6. Developer Onboarding and Mobility: For organizations that wish to standardize the development environment across multiple teams or geographies, UBI provides a standardized platform that any developer can use as a starting point, knowing that they will have the backing of Red Hat’s support and compatibility.

UBI Minimal

UBI (Universal Base Image) and UBI Minimal are both Red Hat container base images, but they serve different purposes and are designed for different use cases:

UBI (Standard)

Includes a full set of Red Hat base packages similar to what you’d find in a minimal installation of Red Hat Enterprise Linux. It Provides common utilities and dependencies that developers expect to be present, also it is larger in size compared to UBI Minimal.

Ubi Standard is Ideal for applications that have dependencies on a wider array of system libraries and utilities.

When to Choose UBI:

• When you need a broader range of packages and utilities that are not included in the UBI Minimal image.
• When your application or users expect a fuller Linux environment.

UBI Minimal

UBI minimal is a pared-down version of the UBI image that includes only the bare essentials. It comes with microdnf instead of the full dnf package manager, which is sufficient for basic package management but has fewer capabilities. It does not include many of the usual Linux utilities and libraries that come with the standard UBI. Also, it's significantly smaller in size, which makes it a better choice for containers where space efficiency is important.

UBI Minimal is better for environments where security is a high priority, as it reduces the attack surface due to fewer installed packages.

When to Choose UBI Minimal:

• When you are optimizing for image size to reduce storage and network transfer costs or when operating in an environment where space is at a premium.
• When you have a straightforward application that doesn’t require the full suite of tools and libraries included in the standard UBI image.
• When you are aiming for a reduced security risk profile with fewer packages to manage and update.

MicroDNF

microdnf is essentially a scaled-down version of the dnf package manager, created to handle RPM package management for smaller environments like containers. While dnf is a feature-rich package manager for RPM-based Linux distributions, offering a wide array of functionalities for package installation, removal, and management, microdnf strips down these capabilities to the bare minimum necessary for managing packages in a more confined space.

The primary differences between microdnf and dnf are their size and functionality. microdnf is designed to occupy less space, making it ideal for containerized applications where efficiency is key. This minimalism, however, comes with certain limitations when compared to dnf. Here's a condensed look at what microdnf lacks in contrast to dnf:

• Feature Set: microdnf offers only the essential functions like install, update, and remove. It doesn't support the advanced features of dnf, such as plugin support, robust transaction history, and rollback features.
• Dependency Resolution: While it can handle basic dependencies, microdnf may not be as adept as dnf at resolving complex dependency trees or conflicts that can arise during package management.
• Querying and Management Tools: dnf provides a comprehensive set of commands for querying the package database and managing packages, which are not all available with microdnf.
• User Interaction: The user experience with dnf is more interactive, with features like search autocompletion and a more verbose output, whereas microdnf has a more simplistic interaction model.
• Performance Optimizations: dnf benefits from performance improvements such as parallel downloads which microdnf does not have.

While these limitations might suggest that microdnf is significantly less powerful, in the context of container environments, it usually has all the functionality that's required. Containers often rely on immutable images where packages aren't changed frequently after the image is built. In such cases, the reduced footprint and simpler operation of microdnf can be more beneficial than the full-fledged capabilities of dnf.

Example

Below is an example Dockerfile that uses a UBI (Universal Base Image) as a base to create a simple containerized application. This example assumes you are creating an image for a simple web server using Python:

# Use the official UBI Python image
FROM registry.access.redhat.com/ubi8/python-38
# Set the working directory in the container
WORKDIR /app
# Copy the current directory contents into the container at /app
COPY . /app
# Install any needed packages specified in requirements.txt
RUN pip install --no-cache-dir -r requirements.txt
# Make port 8000 available to the world outside this container
EXPOSE 8000
# Define environment variable
ENV NAME World
# Run app.py when the container launches
CMD ["python", "app.py"]