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.
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.
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.
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.
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.
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.
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.
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.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 (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:
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 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 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
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
- Feature Set:
microdnfoffers 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,
microdnfmay not be as adept as
dnfat resolving complex dependency trees or conflicts that can arise during package management.
- Querying and Management Tools:
dnfprovides a comprehensive set of commands for querying the package database and managing packages, which are not all available with
- User Interaction: The user experience with
dnfis more interactive, with features like search autocompletion and a more verbose output, whereas
microdnfhas a more simplistic interaction model.
- Performance Optimizations:
dnfbenefits from performance improvements such as parallel downloads which
microdnfdoes 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
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
# Set the working directory in the container
# 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
# Define environment variable
ENV NAME World
# Run app.py when the container launches
CMD ["python", "app.py"]