Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 2. What is new in the JWS Operator 2.0 release?
The JWS Operator 2.0 release provides level-2 Operator capabilities such as seamless integration. JWS Operator 2.0 also supports Red Hat JBoss Web Server metering labels and includes some enhanced Custom Resource Definition (CRD) parameters.
Level-2 Operator capabilities
JWS Operator 2.0 provides the following level-2 Operator capability features:
- Enables seamless upgrades
- Supports patch and minor version upgrades
- Manages web servers deployed by the JWS Operator 1.1.x.
Enabling level-2 seamless integration for new images
The DeploymentConfig object definition includes a trigger that OpenShift uses to deploy new pods when a new image is pushed to the image stream. The image stream can monitor the repository for new images or you can instruct the image stream that a new image is available for use.
Procedure
In your project namespace, create an image stream by using the
oc import-imagecommand to import the tag and other information for an image.For example:
oc import-image <my-image>-imagestream:latest \ --from=quay.io/$user/<my-image>:latest \ --confirmIn the preceding example, replace each occurrence of
<my-image>with the name of the image that you want to import.The preceding command creates an image stream named
<my-image>-imagestreamby importing information for thequay.io/$user/<my-image>image. For more information about the format and management of image streams, see Managing image streams.Create a custom resource of the
WebServerkind for the web application that you want the JWS Operator to deploy whenever the image stream is updated. You can define the custom resource in YAML file format.For example:
apiVersion: web.servers.org/v1alpha1 kind: WebServer metadata: name: <my-image> spec: # Add fields here applicationName: my-app useSessionClustering: true replicas: 2 webImageStream: imageStreamNamespace: <project-name> imageStreamName: <my-image>-imagestreamTrigger an update to the image stream by using the
oc tagcommand.For example:
oc tag quay.io/$user/<my-image> <my-image>-imagestream:latest --scheduledThe preceding command causes OpenShift Container Platform to update the specified image stream tag periodically. This period is a cluster-wide setting that is set to 15 minutes by default.
Level-2 seamless integration for rebuilding existing images
The BuildConfig object definition includes a trigger for image stream updates and a webhook, which is either a GitHub or Generic webhook, that enables the rebuilding of images when the webhook is triggered by Git or GitHub.
For more information about creating a secret for a webhook, see Creating a secret for a generic or GitHub webhook.
For more information about configuring a generic or GitHub webhook in a custom resource WebServer file, see JWS Operator CRD parameters.
Support for Red Hat JBoss Web Server metering labels
JWS Operator 2.0 supports the ability to add metering labels to the Red Hat JBoss Web Server pods that the JWS Operator creates.
Red Hat JBoss Web Server can use the following metering labels:
-
com.company: Red_Hat -
rht.prod_name: Red_Hat_Runtimes -
rht.prod_ver: 2022-Q4 -
rht.comp: JBoss_Web_Server -
rht.comp_ver: 5.7.0 -
rht.subcomp: Tomcat 9 -
rht.subcomp_t: application
You can add labels under the metadata section in the custom resource WebServer file for a web application that you want to deploy. For example:
---
apiVersion: web.servers.org/v1alpha1
kind: WebServer
metadata:
name: <my-image>
labels:
com.company: Red_Hat
rht.prod_name: Red_Hat_Runtimes
rht.prod_ver: 2022-Q4
rht.comp: JBoss_Web_Server
rht.comp_ver: 5.7.0
rht.subcomp: Tomcat 9
rht.subcomp_t: application
spec:
----
If you change any label key or label value for a deployed web server, the JWS Operator redeploys the web server application. If the deployed web server was built from source code, the JWS Operator also rebuilds the web server application.
Enhanced webImage parameter
In the JWS Operator 2.0 release, the webImage parameter in the CRD contains the following additional fields:
imagePullSecretThe secret that the JWS Operator uses to pull images from the repository
NoteThe secret must contain the key
.dockerconfigjson. The JWS Operator mounts and uses the secret (for example,--authfile /mount_point/.dockerconfigjson) to pull the images from the repository. TheSecretobject definition file might contain server username and password values or tokens to allow access to images in the image stream, the builder image, and images built by the JWS Operator.webAppA set of parameters that describe how the JWS Operator builds the web server application
Enhanced webApp parameter
In the JWS Operator 2.0 release, the webApp parameter in the CRD contains the following additional fields:
nameThe name of the web server application
sourceRepositoryURLThe URL where the application source files are located
sourceRepositoryRefThe branch of the source repository that the Operator uses
sourceRepositoryContextDirThe subdirectory where the
pom.xmlfile is located and where themvn installcommand must be runwebAppWarImageThe URL of the images where the JWS Operator pushes the built image
webAppWarImagePushSecretThe secret that the JWS Operator uses to push images to the repository
builderA set of parameters that contain all the information required to build the web application and create and push the image to the image repository
NoteTo ensure that the builder can operate successfully and run commands with different user IDs, the builder must have access to the
anyuidsecurity context constraint (SCC).To grant the builder access to the
anyuidSCC, enter the following command:oc adm policy add-scc-to-user anyuid -z builderThe
builderparameter contains the following fields:imageThe image of the container where the web application is built (for example,
quay.io/$user/tomcat10-buildah)imagePullSecretThe secret (if specified) that the JWS Operator uses to pull the builder image from the repository
applicationBuildScriptThe script that the builder image uses to build the application
.warfile and move it to the/mntdirectoryNoteIf you do not specify a value for this parameter, the builder image uses a default script that uses Maven and Buildah.