This article aims to introduce community containers, where users can pull them from, and use them. The three groups of containers available for use by community users are discussed. These are: Fedora, CentOS, and CentOS Stream.
What are the differences between the containers?
Fedora containers are based on the latest stable Fedora content, and CentOS-7 containers are based on components from the CentOS-7 and related SCLo SIG components. And finally, CentOS Stream containers are based on either CentOS Stream 8 or CentOS Stream 9.
Each container, e.g. s2i-php-container or s2i-perl-container, contain the same packages which are available for a given operating system. It means, that from a functionality point of view these example containers provides the PHP interpreter or Perl interpreter,respectively.
Differences can be only in versions, which are available for each distribution. For example:
Fedora PHP containers are available in these versions:
CentOS-7 PHP containers are available in these versions:
CentOS Stream 9 PHP containers are available in these versions:
CentOS Stream 8 is not mentioned here for the PHP use case since users can pull it directly from the Red Hat Container Catalog registry as a UBI image. Containers that are not UBI based have CentOS Stream 8 repositories in the quay.io/sclorg namespace with repository suffix “-c8s”.
Fedora container images moved recently
The Fedora container images have recently moved to the quay.io/fedora registry organization. All of them use Fedora:35, and later Fedora:36 ,as a base image. The CentOS-7 containers are stored in the quay.io/centos7 registry organization. All of them use CentOS-7 as a base image.
CentOS Stream container images
The CentOS Stream containers are stored in the quay.io/sclorg registry organization.
The base image used for our CentOS Stream 8 containers is CentOS Stream 8 with the tag “stream8”.
The base image used for our CentOS Stream 9 containers is CentOS Stream 9 with the tag “stream9”.
In this registry organization, each container contains a “suffix”, either “c8s” for CentOS Stream 8 or “c9s” for CentOS Stream 9, respectively.
See container PHP-74 for CentOS Stream 9.
Frequency of container image updates and testing
The community-based containers are updated in two ways.
First, when a pull request in the container sources that live under github.com/sclorg organization is merged, the corresponding versions in the GitHub repository are built and pushed into the proper repository.
Second, an update process is also implemented by GitHub Actions set up in each of our GitHub repositories. The base images, like “s2i-core” and “s2i-base”, are built each Tuesday at 1:00 pm. The rest of the containers are built each Wednesday at 1:00 pm.
This means every package update or change is updated in the container image within a few days, not later than after a week.
Each container that is not beyond its end of life is tested by our nightly builds. If we discover or detect an error on some of our containers, we attempt to fix it, but there are no guarantees provided.
What container shall I use?
In the end, what containers are we providing? That’s a great question. All containers live in the GitHub organization https://github.com/sclorg
The list of containers with their upstreams is summarized here:
How to use the container image I picked?
All container images are tuned up to be fully functional in the OpenShift (or OKD and even Kubernetes itself) without any trouble. Some containers support the source-to-image build strategy while some are expected to be used as daemons (like databases, for instance). For specific steps, please, navigate to the GitHub page for the respective container image by following one of the links above.
Finally, Some Real examples
Let’s show how to use PHP container images across all platforms that we support.
First of all, clone the container GitHub repository using this command:
$ git clone https://github.com/sclorg/s2i-php-container
Switch to the following directory created by the cloning step:
$ cd s2i-php-container/examples/from-dockerfile
Fedora example
Start by pulling the Fedora PHP-80 image with this command:
$ podman pull quay.io/fedora/php-80
Modify “Dockerfile” so it refers to Fedora php-80 image. “Dockerfile” then looks like:
FROM quay.io/fedora/php-80 USER 0
# Add application sources
ADD app-src .
RUN chown -R 1001:0 .
USER 1001 # Install the dependencies
RUN TEMPFILE=$(mktemp) && \ curl -o "$TEMPFILE" "https://getcomposer.org/installer" && \ php <"$TEMPFILE" && \ ./composer.phar install --no-interaction --no-ansi --optimize-autoloader # Run script uses standard ways to configure the PHP application
# and execs httpd -D FOREGROUND at the end
# See more in <version>/s2i/bin/run in this repository.
# Shortly what the run script does: The httpd daemon and php need to be
# configured, so this script prepares the configuration based on the container
# parameters (e.g. available memory) and puts the configuration files into
# the appropriate places.
# This can obviously be done differently, and in that case, the final CMD
# should be set to "CMD httpd -D FOREGROUND" instead.
CMD /usr/libexec/s2i/run
Check if the application works properly
Build it by using this command:
$ podman build -f Dockerfile -t cakephp-app-80
Now run the application using this command:
$ podman run -ti --rm -p 8080:8080 cakephp-app-80
To check the PHP version use these commands:
$ podman run -it –rm cakephp-app-80 bash
$ php –version
To check if everything works properly use this command:
$ curl -s -w ‘%{http_code}’ localhost:8080
This should return HTTP code 200. If you would like to see a web page enter “localhost:8080” in your browser.
CentOS 7 example
Start by pulling the CentOS-7 PHP-73 image using this command:
$ podman pull quay.io/centos7/php-73-centos7
Modify “Dockerfile” so it refers to CentOS php-73 image.
“Dockerfile” then looks like this:
FROM quay.io/centos7/php-73-centos7 USER 0
# Add application sources
ADD app-src .
RUN chown -R 1001:0 .
USER 1001 # Install the dependencies
RUN TEMPFILE=$(mktemp) && \ curl -o "$TEMPFILE" "https://getcomposer.org/installer" && \ php <"$TEMPFILE" && \ ./composer.phar install --no-interaction --no-ansi --optimize-autoloader # Run script uses standard ways to configure the PHP application
# and execs httpd -D FOREGROUND at the end
# See more in <version>/s2i/bin/run in this repository.
# Shortly what the run script does: The httpd daemon and php needs to be
# configured, so this script prepares the configuration based on the container
# parameters (e.g. available memory) and puts the configuration files into
# the appropriate places.
# This can obviously be done differently, and in that case, the final CMD
# should be set to "CMD httpd -D FOREGROUND" instead.
CMD /usr/libexec/s2i/run
Check if the application works properly
Build it using this command:
$ podman build -f Dockerfile -t cakephp-app-73
Now run the application using this command:
$ podman run -ti --rm -p 8080:8080 cakephp-app-73
To check the PHP version us these commands:
$ podman run -it –rm cakephp-app-73 bash
$ php –version
To check if everything works properly use this command:
curl -s -w ‘%{http_code}’ localhost:8080
which should return HTTP code 200. If you would like to see a web page enter localhost:8080 in your browser.
RHEL 9 UBI 9 real example
Start by pulling the RHEL9 UBI-based PHP-80 image using the command:
$ podman pull registry.access.redhat.com/ubi9/php-80
Modify “Dockerfile” so it refers to the RHEL9 ubi9 php-80 image.
“Dockerfile” then looks like:
FROM registry.access.redhat.com/ubi9/php-80 USER 0
# Add application sources
ADD app-src .
RUN chown -R 1001:0 .
USER 1001 # Install the dependencies
RUN TEMPFILE=$(mktemp) && \ curl -o "$TEMPFILE" "https://getcomposer.org/installer" && \ php <"$TEMPFILE" && \ ./composer.phar install --no-interaction --no-ansi --optimize-autoloader # Run script uses standard ways to configure the PHP application
# and execs httpd -D FOREGROUND at the end
# See more in <version>/s2i/bin/run in this repository.
# Shortly what the run script does: The httpd daemon and php needs to be
# configured, so this script prepares the configuration based on the container
# parameters (e.g. available memory) and puts the configuration files into
# the appropriate places.
# This can obviously be done differently, and in that case, the final CMD
# should be set to "CMD httpd -D FOREGROUND" instead.
CMD /usr/libexec/s2i/run
Check if the application works properly
Build it using this command:
$ podman build -f Dockerfile -t cakephp-app-80-ubi9
Now run the application using this command:
$ podman run -ti --rm -p 8080:8080 cakephp-app-80-ubi9
To check the PHP version use these commands:
$ podman run -it –rm cakephp-app-80-ubi9 bash
$ php –version
To check if everything works properly use this command:
curl -s -w ‘%{http_code}’ localhost:8080
which should return HTTP code 200. If you would like to see a web page enter localhost:8080 in your browser.
What to do in the case of a bug or enhancement
Just file a bug (known as an “issue” in GitHub) or even a pull request with a fix, to one of the GitHub repositories mentioned in the previous section.
