Design, build, and deploy universal application images

Building high-quality container images and their corresponding pod specifications is the foundation for Kubernetes to effectively run and manage an application in production. There are numerous ways to build images, so knowing where to start can be confusing.

This learning path introduces you to the universal application image (UAI). A UAI is an image that uses Red Hat’s Universal Base Image (UBI) as its foundation, includes the application being deployed, and also adds extra elements that make it more secure and scalable in Kubernetes and Red Hat OpenShift.

Specifically, a universal application image:

  • Is built from a Red Hat UBI
  • Can run on Kubernetes and OpenShift
  • Does not require any Red Hat licensing, so it’s freely distributable
  • Includes qualities that make it run more efficiently
  • Is supported by Red Hat when run in OpenShift

The articles in this learning path describes best practices for packaging an application, highlighting elements that are critical to include in designing the image, performing the build, and deploying the application.

Skill level

Readers should have a general understanding of Kubernetes’ concepts.

Outcomes

After completing this learning path, you will understand best practices for how to:

  1. Write a Dockerfile with instructions for building the image. The article Best practices for designing a universal application image explains best practices for what kind of code to include in the Dockerfile so that it will build a UAI that runs well in both Kubernetes and OpenShift, is supported by Red Hat when run in OpenShift, and is ready for certification by Red Hat if desired.
  2. Build the image and store it, which means running the Dockerfile in a build tool. The article Build and distribute a universal application image offers best practices to help you avoid vendor lock-in, optimize the image to run in a container orchestrator, and identify the version of the image and the software within it.
  3. Make the running container and its application easier to manage, both by the cluster and by the operations staff. Use the article Implement and deploy a manageable application to learn best practices both in the deployment manifest and in the application’s implementation that make the application and its container run better and enable the operations staff to more easily monitor and manage them.

You can apply these best practices in any order, and some can be used even if others are not.

Each best practice includes the requirements to implement the best practice, manual steps to meet the requirements, and details related to Red Hat Certification requirements. Additionally, an example in each section shows how the open source Cloud-Native Toolkit uses the practice. The toolkit is an asset to help perform continuous delivery of cloud-native applications. As part of its functionality, it builds UAIs before deploying them.

Important: This article does not show the steps for producing an image, but it does describe the important attributes the image should have once it has been built.

Before you get started

Before proceeding to the rest of the series, let’s review some background information that helps explain the value of these best practices:

Image structure

A Linux container image consists of three main parts and runs on a container host consisting of two main parts. Here is the stack of all five parts:

  • Linux container:
    • Application — custom business functionality implemented in a programming language
    • Language runtime — executable environment for the programming language
    • Linux libraries — operating system modules in addition to the kernel required by the application language runtime
  • Container host:
    • Container engine (or container runtime) — executable for running and managing containers
    • Linux kernel — operating system foundation that’s shared by all containers running in the container engine

This diagram shows the stack:

You can use components from a variety of sources, but those components must be compatible. To maximize compatibility, you should use Linux libraries and a Linux kernel from the same Linux distribution. While the Docker Engine is perhaps the best known container engine, containerd and CRI-O are better standardized and optimized for container orchestrators such as Kubernetes and OpenShift.

Building a UAI with a Dockerfile

A Dockerfile (also known as a Containerfile) is a script of instructions for how to build an image. An image builder such as Docker or Buildah executes the instructions to build the image.

Like all images, a UAI is built using a Dockerfile. You can add instructions to the Dockerfile in order to build an image with the qualities of a UAI.

Container standards that are required for Red Hat support in OpenShift

OpenShift users want to use images that maximize the security and vendor support that Red Hat offers. UAIs use security features in OpenShift and Red Hat Enterprise Linux to protect the cluster from potentially rogue container processes. UAIs also preserve a stack of components that Red Hat supports and takes responsibility to fix as needed.

Images built for Kubernetes tend to have at least two significant drawbacks when deploying to OpenShift:

  • Linux distribution — Any Linux libraries that run in a Linux kernel will run in OpenShift, but Red Hat only offers support for libraries drawn from the Red Hat Enterprise Linux distribution.
  • Root user — By default, Linux containers are built by the root user to run as the root user. Containers running as root work perfectly well in Kubernetes, but OpenShift intentionally runs each container as an arbitrary non-root user. While most containers are able to run as non-root, the best approach is to build them as non-root to run as non-root.

Advantages of Red Hat Container Certification

The Red Hat Container Certification program confirms that an image is built with best practices that enable customers to use containers with confidence, knowing that:

  • All components come from a trusted source and the underlying packages are not altered.
  • The container image is free of known vulnerabilities in the platform components or layers.
  • New vulnerabilities are promptly addressed through the Red Hat Build Service.
  • The container is compatible across Red Hat footprints —- from bare metal to cloud.
  • The complete stack is commercially supported by Red Hat and Red Hat partners.

Red Hat’s Partner Guide for OpenShift Operator and Container Certification explains how to submit both images and operators for certification.

Summary

Now that you’ve learned about UAIs, you can explore best practices for how to design, build, and deploy UAIs:

This knowledge will help you successfully package your applications to run well in both Kubernetes and OpenShift.