Chapter 12. Using images 12.1. Using images overview Use the following topics to discover the different Source-to-Image (S2I), database, and other container images that are available for OpenShift Container Platform users. Red Hat official container images are provided in the Red Hat Registry at registry.redhat.io . OpenShift Container Platform's supported S2I, database, and Jenkins images are provided in the openshift4 repository in the Red Hat Quay Registry. For example, quay.io/openshift-release-dev/ocp-v4.0-<address> is the name of the OpenShift Application Platform image. The xPaaS middleware images are provided in their respective product repositories on the Red Hat Registry but suffixed with a -openshift . For example, registry.redhat.io/jboss-eap-6/eap64-openshift is the name of the JBoss EAP image. All Red Hat supported images covered in this section are described in the Container images section of the Red Hat Ecosystem Catalog . For every version of each image, you can find details on its contents and usage. Browse or search for the image that interests you. Important The newer versions of container images are not compatible with earlier versions of OpenShift Container Platform. Verify and use the correct version of container images, based on your version of OpenShift Container Platform. 12.2. Source-to-image You can use the Red Hat Software Collections images as a foundation for applications that rely on specific runtime environments such as Node.js, Perl, or Python. You can use the Red Hat Java Source-to-Image for OpenShift documentation as a reference for runtime environments that use Java. Special versions of some of these runtime base images are referred to as Source-to-Image (S2I) images. With S2I images, you can insert your code into a base image environment that is ready to run that code. S2I images include: .NET Java Go Node.js Perl PHP Python Ruby S2I images are available for you to use directly from the OpenShift Container Platform web console by following procedure: Log in to the OpenShift Container Platform web console using your login credentials. The default view for the OpenShift Container Platform web console is the Administrator perspective. Use the perspective switcher to switch to the Developer perspective. In the +Add view, use the Project drop-down list to select an existing project or create a new project. Click All services in the Developer Catalog tile. Click Builder Images under Type to see the available S2I images. S2I images are also available though the Configuring the Cluster Samples Operator . 12.2.1. Source-to-image build process overview Source-to-image (S2I) produces ready-to-run images by injecting source code into a container that prepares that source code to be run. It performs the following steps: Runs the FROM <builder image> command Copies the source code to a defined location in the builder image Runs the assemble script in the builder image Sets the run script in the builder image as the default command Buildah then creates the container image. 12.2.2. Additional resources Configuring the Cluster Samples Operator Using build strategies Troubleshooting the Source-to-Image process Creating images from source code with source-to-image About testing source-to-image images Creating images from source code with source-to-image 12.3. Customizing source-to-image images Source-to-image (S2I) builder images include assemble and run scripts, but the default behavior of those scripts is not suitable for all users. You can customize the behavior of an S2I builder that includes default scripts. 12.3.1. Invoking scripts embedded in an image Builder images provide their own version of the source-to-image (S2I) scripts that cover the most common use-cases. If these scripts do not fulfill your needs, S2I provides a way of overriding them by adding custom ones in the .s2i/bin directory. However, by doing this, you are completely replacing the standard scripts. In some cases, replacing the scripts is acceptable, but, in other scenarios, you can run a few commands before or after the scripts while retaining the logic of the script provided in the image. To reuse the standard scripts, you can create a wrapper script that runs custom logic and delegates further work to the default scripts in the image. Procedure Look at the value of the io.openshift.s2i.scripts-url label to determine the location of the scripts inside of the builder image: USD podman inspect --format='{{ index .Config.Labels "io.openshift.s2i.scripts-url" }}' wildfly/wildfly-centos7 Example output image:///usr/libexec/s2i You inspected the wildfly/wildfly-centos7 builder image and found out that the scripts are in the /usr/libexec/s2i directory. Create a script that includes an invocation of one of the standard scripts wrapped in other commands: .s2i/bin/assemble script #!/bin/bash echo "Before assembling" /usr/libexec/s2i/assemble rc=USD? if [ USDrc -eq 0 ]; then echo "After successful assembling" else echo "After failed assembling" fi exit USDrc This example shows a custom assemble script that prints the message, runs the standard assemble script from the image, and prints another message depending on the exit code of the assemble script. Important When wrapping the run script, you must use exec for invoking it to ensure signals are handled properly. The use of exec also precludes the ability to run additional commands after invoking the default image run script. .s2i/bin/run script #!/bin/bash echo "Before running application" exec /usr/libexec/s2i/run

Commands:
podman inspect --format='{{ index .Config.Labels "io.openshift.s2i.scripts-url" }}' wildfly/wildfly-centos7
image:///usr/libexec/s2i
#!/bin/bash echo "Before assembling" /usr/libexec/s2i/assemble rc=USD? if [ USDrc -eq 0 ]; then echo "After successful assembling" else echo "After failed assembling" fi exit USDrc
#!/bin/bash echo "Before running application" exec /usr/libexec/s2i/run