As well as the four main UBI images, Red Hat provides specific UBI images for popular runtimes. These images are built on top of the main UBI images and provide the same benefits. They include the common components and tools of each runtime, and are ready for developers to add and run their code. Red Hat provides UBI images for the following runtime languages:

For each runtime, Red Hat provides images for each supported major version of the runtime. For example, for Node.js 18, Red Hat provides the ubi9/nodejs-18 image, which is indirectly based on the standard ubi9/ubi image, and ubi9/nodejs-18-minimal, which is based on the minimal ubi9/ubi-minimal application.

To create your own images from a runtime UBI image, follow the instructions of the specific UBI image. You can find the instructions of each UBI image in the Red Hat Ecosystem Catalog, by navigating to the image page and clicking the Overview tab.

Figure 3.1: The Overview tab of the Red Hat Ecosystem Catalog provides instructions to use an image

Most of the UBI runtime images support two Containerfile build approaches, which are typically documented in the instructions of each image.

Red Hat OpenShift, by default, does not use the USER instruction set by a container image. For security reasons, OpenShift uses a random user ID other than the root user ID (0) to run containers. Additionally, OpenShift makes this random user a member of the root group, which corresponds to the 0 group ID.

This approach mitigates the risk of processes running in the container getting escalated privileges on the cluster nodes due to security vulnerabilities in the container engine. When you create or update the Containerfile of an image that runs on OpenShift, address the following aspects:

Adding the following RUN instruction to your Containerfile recursively sets the permissions of a directory to allow users in the root group to access this directory and its contents in the container.

RUN chgrp -R 0 directory && \ 
    chmod -R g=u directory 

OpenShift expects application instances to shut down gracefully before the cluster removes the instances from the load balancer. Applications must ensure they gracefully terminate user connections before they exit.

OpenShift sends a SIGTERM signal to the processes in the container to terminate an application.

The application might require additional procedures during shutdown, for example to wait until all open connections are closed, release resources, or gracefully terminate individual connections at the next opportunity. In such cases, you might have to implement additional handling in your application.

If the application uses a complex procedure to start, then developers commonly encapsulate the logic in the entrypoint script. In such cases, the entrypoint script is responsible for passing the SIGTERM signal to the application, for example:

#!/bin/env bash

function graceful_shutdown() {
  kill -SIGTERM "$java_pid"
  wait "$java_pid"
  exit 0
}

# Trap the SIGTERM signal
trap graceful_shutdown SIGTERM

...script omitted...

# Start the application
java -jar example.jar &
java_pid=$!

...script omitted...

# Wait for the process to finish
wait "$java_pid"

Additionally, you can use the preStop pod lifecycle hook to initiate a graceful shutdown of your application, for example:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: my-container
      image: example.com/myimage
      lifecycle:
        preStop:
          httpGet:
            path: /shutdown
            port: 8080

This is useful when you cannot handle the SIGTERM signal in your application. See the references section for more information about lifecycle hooks.

If a process does not exit after receiving the SIGTERM signal, then OpenShift waits until the termination period expires, and sends a SIGKILL signal to the process. This signal immediately ends the process.

Reduce the size of your custom containers by using the following techniques:

Whenever possible, use a minimal UBI image to slim down the size of your containers. Note that the name of minimal images might differ, based on the runtime. For example, Node.js UBI images use names such as nodejs-18-minimal, but the OpenJDK UBI images call this concept runtime-only images, as in ubi9/opendjk-17-runtime.

If you use a multistage build, then use a standard UBI image as the initial, builder stage, such as ubi9/nodejs-18. Then, use a minimal image for the last stage, such as ubi9/nodejs-18-minimal to reduce the size of the resulting image.

Use the LABEL instruction to define information, warnings and suggestions that OpenShift can display to the users.

OpenShift supports a number of metadata labels. The label names are namespaced with the io.openshift or io.k8s prefixes. The OpenShift tooling parses these labels and provides them as additional information in the OpenShift UIs. For example, you can define the io.openshift.min-cpu label to make the OpenShift UI warn the users about the minimum number of CPUs that an image requires:

LABEL io.openshift.min-cpu 2

For a full list of all the image labels supported in OpenShift, refer to the references at the end of this section.

Red Hat recommends using absolute paths in WORKDIR instructions. Use WORKDIR instead of multiple RUN instructions where you change directories and then run some commands. This approach ensures better maintainability and is easier to troubleshoot.

Use ENV instructions to define file and directory paths instead of reusing fixed paths in Containerfile instructions. Environment variables are useful to define application configuration, store information such as software version numbers, and also to append directories to the PATH environment variable.

Using the ARG instruction to set environment variables at build time is also a supported way to create reusable container images that run on OpenShift.

Red Hat recommends the explicit definition of volumes in Containerfiles, by using the VOLUME instruction. Defining the VOLUME instruction makes it easy for image consumers to understand what volumes they can define when running your image.

OpenShift does not use the VOLUME instruction. When you deploy container images, the cluster does not attach any volumes to the application by default.

Expose non-privileged ports with the EXPOSE instruction. Defining the EXPOSE instruction makes it easy for image consumers to understand what ports your application exposes. Do not expose ports below 1024, which require privileged access.

On Red Hat OpenShift, the oc new-app command uses the EXPOSE value of the image. For example, if the EXPOSE value is 3001, then oc new-app sets the 3001 as the port used in the definition of the Deployment and Service resources. This mechanism also supports multiple ports in a single EXPOSE instruction.

In contrast, adding a new application from the OpenShift web console typically does not use the EXPOSE value. You must set the port explicitly by using web forms.