Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
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.
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 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
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-urllabel to determine the location of the scripts inside of the builder image:$ podman inspect --format='{{ index .Config.Labels "io.openshift.s2i.scripts-url" }}' wildfly/wildfly-centos7Example output
image:///usr/libexec/s2i
You inspected the
wildfly/wildfly-centos7builder image and found out that the scripts are in the/usr/libexec/s2idirectory.Create a script that includes an invocation of one of the standard scripts wrapped in other commands:
.s2i/bin/assemblescript#!/bin/bash echo "Before assembling" /usr/libexec/s2i/assemble rc=$? if [ $rc -eq 0 ]; then echo "After successful assembling" else echo "After failed assembling" fi exit $rcThis 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.
ImportantWhen wrapping the run script, you must use
execfor invoking it to ensure signals are handled properly. The use ofexecalso precludes the ability to run additional commands after invoking the default image run script..s2i/bin/runscript#!/bin/bash echo "Before running application" exec /usr/libexec/s2i/run
