Questo contenuto non è disponibile nella lingua selezionata.
Chapter 10. Using images
10.1. Using images overview Copia collegamentoCollegamento copiato negli appunti!
You can use Source-to-Image (S2I), database, and other container images that are available for OpenShift Container Platform. You need these images to build and deploy containerized applications on your cluster.
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.
10.2. Source-to-image Copia collegamentoCollegamento copiato negli appunti!
Source-to-Image (S2I) images are special versions of runtime base images for languages like Node.js, Python, and Java. You can insert your code into S2I images to create containerized applications without configuring the runtime environment.
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 Introduction to source-to-image for OpenShift documentation as a reference for runtime environments that use Java.
S2I images are also available though the Cluster Samples Operator.
10.2.1. Accessing S2I builder images in the OpenShift Container Platform Developer Console Copia collegamentoCollegamento copiato negli appunti!
You can access S2I builder images through the Developer Console in the web console. You need these images to build containerized applications from your source code.
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.
10.2.2. Source-to-image build process overview Copia collegamentoCollegamento copiato negli appunti!
Source-to-image (S2I) is a build process that injects your source code into a container image. S2I automates the creation of ready-to-run container images from your application source code. 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.
10.3. Customizing source-to-image images Copia collegamentoCollegamento copiato negli appunti!
Customize source-to-image (S2I) builder images to modify the default assemble and run script behavior. You can adapt S2I builders to meet your specific application requirements when the default scripts are not suitable.
10.3.1. Invoking scripts embedded in an image Copia collegamentoCollegamento copiato negli appunti!
You invoke embedded S2I image scripts by creating wrapper scripts that run custom logic and default scripts. You must do this to extend builder image behavior while preserving supported script logic and upgrade compatibility.
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-centos7$ podman inspect --format='{{ index .Config.Labels "io.openshift.s2i.scripts-url" }}' wildfly/wildfly-centos7Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
image:///usr/libexec/s2i
image:///usr/libexec/s2iCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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/assemblescriptCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
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
#!/bin/bash echo "Before running application" exec /usr/libexec/s2i/runCopy to Clipboard Copied! Toggle word wrap Toggle overflow