Chapter 2. Types of container images
The container image is a binary that includes all of the requirements for running a single container, and metadata describing its needs and capabilities.
There are two types of container images:
- Red Hat Enterprise Linux Base Images (RHEL base images)
- Red Hat Universal Base Images (UBI images)
Both types of container images are built from portions of Red Hat Enterprise Linux. By using these containers, users can benefit from great reliability, security, performance and life cycles.
The main difference between the two types of container images is that the UBI images allow you to share container images with others. You can build a containerized application using UBI, push it to your choice of registry server, easily share it with others, and even deploy it on non-Red Hat platforms. The UBI images are designed to be a foundation for cloud-native and web applications use cases developed in containers.
2.1. General characteristics of RHEL container images
Following characteristics apply to both RHEL base images and UBI images.
In general, RHEL container images are:
- Supported: Supported by Red Hat for use with containerized applications. They contain the same secured, tested, and certified software packages found in Red Hat Enterprise Linux.
- Cataloged: Listed in the Red Hat Container Catalog, with descriptions, technical details, and a health index for each image.
- Updated: Offered with a well-defined update schedule, to get the latest software, see Red Hat Container Image Updates article.
- Tracked: Tracked by Red Hat Product Errata to help understand the changes that are added into each update.
- Reusable: The container images need to be downloaded and cached in your production environment once. Each container image can be reused by all containers that include it as their foundation.
2.2. Characteristics of UBI images
The UBI images allow you to share container images with others. Four UBI images are offered: micro, minimal, standard, and init. Pre-build language runtime images and YUM repositories are available to build your applications.
Following characteristics apply to UBI images:
- Built from a subset of RHEL content: Red Hat Universal Base images are built from a subset of normal Red Hat Enterprise Linux content.
- Redistributable: UBI images allow standardization for Red Hat customers, partners, ISVs, and others. With UBI images, you can build your container images on a foundation of official Red Hat software that can be freely shared and deployed.
- Provides a set of four base images: micro, minimal, standard, and init.
- Provides a set of pre-built language runtime container images: The runtime images based on Application Streams provide a foundation for applications that can benefit from standard, supported runtimes such as python, perl, php, dotnet, nodejs, and ruby.
Provides a set of associated YUM repositories: YUM repositories include RPM packages and updates that allow you to add application dependencies and rebuild UBI container images.
ubi-8-baseosrepository holds the redistributable subset of RHEL packages you can include in your container.
ubi-8-appstreamrepository holds Application streams packages that you can add to a UBI image to help you standardize the environments you use with applications that require particular runtimes.
- Adding UBI RPMs: You can add RPM packages to UBI images from preconfigured UBI repositories. If you happen to be in a disconnected environment, you must allowlist the UBI Content Delivery Network (https://cdn-ubi.redhat.com) to use that feature. See the Connect to https://cdn-ubi.redhat.com solution for details.
- Licensing: You are free to use and redistribute UBI images, provided you adhere to the Red Hat Universal Base Image End User Licensing Agreement.
2.3. Understanding the UBI standard images
The standard images (named
ubi) are designed for any application that runs on RHEL. The key features of UBI standard images include:
init system: All the features of the systemd initialization system you need to manage systemd services are available in the standard base images. These init systems let you install RPM packages that are pre-configured to start up services automatically, such as a Web server (
httpd) or FTP server (
yum: You have access to free yum repositories for adding and updating software. You can use the standard set of
yumdownloader, and so on).
utilities: Utilities include
getfacland further acl commands,
dmsetupand further device mapper commands, between other utilities not mentioned here.
2.4. Understanding the UBI init images
The UBI init images, named
ubi-init, contain the systemd initialization system, making them useful for building images in which you want to run systemd services, such as a web server or file server. The init image contents are less than what you get with the standard images, but more than what is in the minimal images.
ubi8-init image builds on top of the
ubi8 image, their contents are mostly the same. However, there are a few critical differences:
CMD is set to
/sbin/initto start the systemd Init service by default
psand process related commands (
StopSignal, as systemd in
ubi8-initignores normal signals to exit (
SIGKILL), but will terminate if it receives
- CMD is set to
CMD is set to
does not include
psand process related commands (
does not ignore normal signals to exit (
- CMD is set to
2.5. Understanding the UBI minimal images
The UBI minimal images, named
ubi-minimal offer a minimized pre-installed content set and a package manager (microdnf). As a result, you can use a Dockerfile or Containerfile while minimizing the dependencies included in the image.
The key features of UBI minimal images include:
- Small size: Minimal images are about 92M on disk and 32M, when compressed. This makes it less than half the size of the standard images.
Software installation (
microdnf): Instead of including the fully-developed
yumfacility for working with software repositories and RPM software packages, the minimal images includes the
microdnfis a scaled-down version of
dnfallowing you to enable and disable repositories, remove and update packages, and clean out cache after packages have been installed.
- Based on RHEL packaging: Minimal images incorporate regular RHEL software RPM packages, with a few features removed. Minimal images do not include initialization and service management system, such as systemd or System V init, Python run-time environment, and some shell utilities. You can rely on RHEL repositories for building your images, while carrying the smallest possible amount of overhead.
microdnfare supported: Modules used with
microdnfcommand let you install multiple versions of the same software, when available. You can use
microdnf module enable,
microdnf module disable, and
microdnf module resetto enable, disable, and reset a module stream, respectively.
For example, to enable the
nodejs:14module stream inside the UBI minimal container, enter:
# microdnf module enable nodejs:14 Downloading metadata... ... Enabling module streams: nodejs:14 Running transaction test...
Red Hat only supports the latest version of UBI and does not support parking on a dot release. If you need to park on a specific dot release, please take a look at Extended Update Support.
2.6. Understanding the UBI micro images
ubi-micro is the smallest possible UBI image, obtained by excluding a package manager and all of its dependencies which are normally included in a container image. This minimizes the attack surface of container images based on the
ubi-micro image and is suitable for minimal applications, even if you use UBI Standard, Minimal, or Init for other applications. The container image without the Linux distribution packaging is called a Distroless container image.
2.7. Using the UBI init images
This procedure shows how to build a container using a
Containerfile that installs and configures a Web server (
httpd) to start automatically by the systemd service (
/sbin/init) when the container is run on a host system. The
podman build command uses a
Containerfile if found in the context directory, if it is not found the
podman build command will use a
Dockerfile; otherwise any file can be specified with the
--file option. The available commands that are usable inside a
Containerfile and a
Dockerfile are equivalent.
Containerfilewith the following contents to a new directory:
FROM registry.access.redhat.com/ubi8/ubi-init RUN yum -y install httpd; yum clean all; systemctl enable httpd; RUN echo "Successful Web Server Test" > /var/www/html/index.html RUN mkdir /etc/systemd/system/httpd.service.d/; echo -e '[Service]\nRestart=always' > /etc/systemd/system/httpd.service.d/httpd.conf EXPOSE 80 CMD [ "/sbin/init" ]
httpdpackage, enables the
httpdservice to start at boot time, creates a test file (
index.html), exposes the Web server to the host (port 80), and starts the systemd init service (
/sbin/init) when the container starts.
Build the container:
# podman build --format=docker -t mysysd .
Optional. If you want to run containers with systemd and SELinux is enabled on your system, you must set the
# setsebool -P container_manage_cgroup 1
Run the container named
# podman run -d --name=mysysd_run -p 80:80 mysysd
mysysdimage runs as the
mysysd_runcontainer as a daemon process, with port 80 from the container exposed to port 80 on the host system.
In rootless mode, you have to choose host port number >= 1024. For example:
$ podman run -d --name=mysysd -p 8081:80 mysysd
To use port numbers < 1024, you have to modify the
$ sudo sysctl net.ipv4.ip_unprivileged_port_start=80
Check that the container is running:
# podman ps a282b0c2ad3d localhost/mysysd:latest /sbin/init 15 seconds ago Up 14 seconds ago 0.0.0.0:80->80/tcp mysysd_run
Test the web server:
# curl localhost/index.html Successful Web Server Test
2.8. Using the UBI micro images
This procedure shows how to build a
ubi-micro container image using the Buildah tool.
container-toolsmodule is installed.
# yum module install -y container-tools
Pull and build the
# microcontainer=$(buildah from registry.access.redhat.com/ubi8/ubi-micro)
Mount a working container root filesystem:
# micromount=$(buildah mount $microcontainer)
httpdservice to the
# yum install \ --installroot $micromount \ --releasever 8 \ --setopt install_weak_deps=false \ --nodocs -y \ httpd # yum clean all \ --installroot $micromount
Unmount the root file system on the working container:
# buildah umount $microcontainer
ubi-micro-httpdimage from a working container:
# buildah commit $microcontainer ubi-micro-httpd
Display details about the
# podman images ubi-micro-httpd localhost/ubi-micro-httpd latest 7c557e7fbe9f 22 minutes ago 151 MB