A brief introduction to Apps and Stacks Container Images

July 17, 2024
Petr Hracek
Related topics:
CI/CDContainersDatabasesProgramming languages & frameworks
Related products:
Red Hat Enterprise LinuxRed Hat OpenShiftRed Hat OpenShift Container Platform

This article aims to describe Apps and Stacks container images from two perspectives: user’s and developer's.

Apps and Stacks container images can be divided into two groups: 

  • Source-to-Image (S2I) images 
  • No Source-to-Image (NoS2I) images

Source-to-Image (S2I) is a toolkit and workflow for building reproducible container images from source code.

S2I images are:

NoS2I images are:

Apps and Stacks container images support several operating systems like Fedora, CentOS Stream 8 (C8S), CentOS Stream 9 (C9S), Red Hat Enterprise Linux (RHEL) 8, and RHEL 9, and soon also RHEL 10. CentOS7 and RHEL 7 are not supported at all.

All container sources are stored in the "sclorg" GitHub repository All supported versions per container are available in this GitHub repository.

Fedora, C9S, and soon C10S container images are automatically built and pushed either by merging a pull request or by scheduled updates each Wednesday.

RHEL container images are updated by each imported CVE, or by updated base image.

Some of the RHEL images have a Universal Base Image (UBI) version. The UBI is designed and engineered to be the base layer for all of your containerized applications, middleware, and utilities. This base image is freely redistributable, but Red Hat only supports Red Hat technologies through subscriptions for Red Hat products. This image is maintained by Red Hat and updated regularly.

User’s perspective

To get a container for a specific operating system, pull the required version of the container from the respective container registry:

C8S and C9S images use tags, latest, c8s, or c9s. All these images are present in this container repository until they reach end of life (EOL).

Each upstream repository contains instructions how to use the image either as a container-based image or in a Red Hat OpenShift 4 environment.

E.g. postgresql-container.

All supported versions are listed in the main README.md file, which is the same for all container versions.

For example, if you want to use the PostgreSQL 16 version, you can find all the information here. The container-base usage, as well as OpenShift-base usage, is described here.

To pull the PostgreSQL 16 C9S image from quay.io:

$ podman pull quay.io/sclorg/postgresql-16-c9s

Developer’s perspective

If you are a developer who wants to participate, read the contribution guide, where you can find information about how to add a new container version and how to test a container.

All containers use a test suite from the container-common-scripts repository. The test suite is written in bash and it is regularly distributed over a GitHub Action each week if there is any change.

We plan to add a test suite written in PyTest later.

Containers are tested every day with nightly builds or upon each pull request. The main testing platform is the Testing Farm.

Example: postgresql-container from a developer's perspective.

  1. Clone the respective container repository:

    $ git clone 
      Cloning into 'postgresql-container'...
      remote: Enumerating objects: 6645, done.
      remote: Counting objects: 100% (1548/1548), done.
      remote: Compressing objects: 100% (324/324), done.
      remote: Total 6645 (delta 1287), reused 1331 (delta 1169), pack-reused 5097
      Receiving objects: 100% (6645/6645), 1.06 MiB | 8.28 MiB/s, done.
      Resolving deltas: 100% (3791/3791), done.
    $ cd postgresql-container

  2. Update or init the test suite:

    $ git submodule update --init
      Submodule 'common' (https://github.com/sclorg/container-common-scripts.git) registered for path 'common'
      Cloning into '/home/phracek/testing-approach/postgresql-container/common'...
      Submodule path 'common': checked out 'a9578162cd92ed8047e1936130813ed907470546' https://github.com/sclorg/postgresql-container

  3. Build and tag the respective container, for example, to build a container based on the RHEL8 host for version 16:

    $ make build TARGET=rhel8 VERSIONS=16
    $ make tag TARGET=rhel8 VERSIONS=16
  4. Make sure that all tests from the provided test suite passed.

    1. To run container based tests, use: 

      $ make test TARGET=rhel8 VERSIONS=16

    2. To run OpenShift 4 based, use:

      $ make test-openshift-4 TARGET=rhel8 VERSIONS=16

      Note: A prerequisite for running the OpenShift 4 tests is to have a connection to the OpenShift 4 cluster.

  5. If all tests are passed, you can file a pull request to the respective upstream repository. 

Now you are a proud contributor to the Apps and Stack containers world. Congratulations!