Rechercher

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 7. JWS Operator CRD parameters

download PDF

The JWS Operator provides a set of custom resource definition (CRD) parameters. When you create a custom resource WebServer file for a web application, you can specify parameter values in a <key>: <value> format. The JWS Operator uses the information that you specify in the custom resource WebServer file to deploy the web application.

7.1. CRD parameter hierarchy

The JWS Operator provides CRD parameters in the following hierarchical format:

applicationName: <value>
replicas: <value>
useSessionClustering: <value>
webImage:
   applicationImage: <value>
   imagePullSecret: <value>
   webApp:
      name: <value>
      sourceRepositoryURL: <value>
      sourceRepositoryRef: <value>
      contextDir: <value>
      webAppWarImage: <value>
      webAppWarImagePushSecret: <value>
      builder:
        image: <value>
        imagePullSecret: <value>
        applicationBuildScript: <value>
   webServerHealthCheck:
      serverReadinessScript: <value>
      serverLivenessScript: <value>
webImageStream:
   imageStreamName: <value>
   imageStreamNamespace: <value>
   webSources:
      sourceRepositoryUrl: <value>
      sourceRepositoryRef: <value>
      contextDir: <value>
      webSourcesParams:
         mavenMirrorUrl: <value>
         artifactDir: <value>
         genericWebHookSecret: <value>
         githubWebHookSecret: <value>
   webServerHealthCheck:
      serverReadinessScript: <value>
      serverLivenessScript: <value>
Note

When you create a custom resource WebServer file, specify parameter names and values in the same hierarchical format that the preceding example outlines. For more information about creating a custom resource WebServer file, see Deploying an existing JWS image.

7.2. CRD parameter details

The following table describes the CRD parameters that the JWS Operator provides. This table shows each parameter name in the context of any higher-level parameters that are above it in the hierarchy.

Parameter nameDescription

replicas

The number of pods of the JBoss Web Server image that you want to run

For example:
replicas: 2

applicationName

The name of the web application that you want the JWS Operator to deploy

The application name must be a unique value in the OpenShift namespace or project. The JWS Operator uses the application name that you specify to create the route to access the web application.

For example:
applicationName: my-app

useSessionClustering

Enables DNSping session clustering

This is set to false by default. If you set this parameter to true, the image must be based on JBoss Web Server images, because session clustering uses the ENV_FILES environment variable and a shell script to add the clustering in the server.xml file.

Note

In this release, the session clustering functionality is available as a Technology Preview feature only. The current Operator version uses the DNS Membership Provider, which is limited because of DNS limitations. InetAddress.getAllByName() results are cached, which means session replications might not work while scaling up.

For example:
useSessionClustering: true

webImage

A set of parameters that controls how the JWS Operator deploys pods from existing images

This parameter contains applicationImage, imagePullSecret, webApp, and webServerHealthCheck fields.

webImage:
      applicationImage

The full path to the name of the application image that you want to deploy

For example:
applicationImage: quay.io/$user/my-image-name

webImage:
      imagePullSecret

The name of the secret that the JWS Operator uses to pull images from the repository

The secret must contain the key .dockerconfigjson. The JWS Operator mounts the secret and uses it similar to --authfile /mount_point/.dockerconfigjson to pull the images from the repository.

The Secret object definition file might contain several 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.

For example:
imagePullSecret: mysecret

webImage:
      webApp

A set of parameters that describe how the JWS Operator builds the web application that you want to add to the application image

If you do not specify the webApp parameter, the JWS Operator deploys the web application without building the application.

This parameter contains name, sourceRepositoryURL, sourceRepositoryRef, contextDir, webAppWarImage, webAppWarImagePushSecret, and builder fields.

webImage:
      webApp:
           name

The name of the web application file

The default name is ROOT.war.

For example:
name: my-app.war

webImage:
      webApp:
           sourceRepositoryURL

The URL where the application source files are located

The source should contain a Maven pom.xml file to support a Maven build. When Maven generates a .war file for the application, the .war file is copied to the webapps directory of the image that the JWS Operator uses to deploy the application (for example, /opt/jws-5.x/tomcat/webapps).

For example:
sourceRepositoryUrl: 'https://github.com/$user/demo-webapp.git'

webImage:
      webApp:
           sourceRepositoryRef

The branch of the source repository that the JWS Operator uses

For example:
sourceRepositoryRef: main

webImage:
      webApp:
           contextDir

The subdirectory in the source repository where the pom.xml file is located and the mvn install command is run

For example:
contextDir: /

webImage:
      webApp:
           webAppWarImage

The URL of the images where the JWS Operator pushes the built image

webImage:
      webApp:
           webAppWarImagePushSecret

The name of the secret that the JWS Operator uses to push images to the repository

The secret must contain the key .dockerconfigjson. The JWS Operator mounts the secret and uses it similar to --authfile /mount_point/.dockerconfigjson to push the image to the repository.

If the JWS Operator uses a pull secret to pull images from the repository, you must specify the name of the pull secret as the value for the webAppWarImagePushSecret parameter. See imagePullSecret for more information.

For example:
imagePullSecret: mysecret

webImage:
      webApp:
           builder

A set of parameters that describe how the JWS Operator builds the web application and creates and pushes the image to the image repository

Note

To ensure that the builder can operate successfully and run commands with different user IDs, the builder must have access to the anyuid SCC (security context constraint). To grant the builder access to the anyuid SCC, enter the following command:

oc adm policy add-scc-to-user anyuid -z builder

This parameter contains image, imagePullSecret, and applicationBuildScript fields.

webImage:
      webApp:
           builder:
                image

The image of the container where the JWS Operator builds the web application

For example:
image: quay.io/$user/tomcat10-buildah

webImage:
      webApp:
           builder:
                imagePullSecret

The name of the secret (if specified) that the JWS Operator uses to pull the builder image from the repository

The secret must contain the key .dockerconfigjson. The JWS Operator mounts the secret and uses it similar to --authfile /mount_point/.dockerconfigjson to pull the images from the repository.

The Secret object definition file might contain several 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.

For example:
imagePullSecret: mysecret

webImage:
      webApp:
           builder:
                applicationBuildScript

The script that the builder image uses to build the application .war file and move it to the /mnt directory

If you do not specify a value for this parameter, the builder image uses a default script that uses Maven and Buildah.

webImage:
      webServerHealthCheck

The health check that the JWS Operator uses

The default behavior is to use the health valve, which does not require any parameters.

This parameter contains serverReadinessScript and serverLivenessScript fields.

webImage:
      webServerHealthCheck:
           serverReadinessScript

A string that specifies the logic for the pod readiness health check

If this parameter is not specified, the JWS Operator uses the default health check by using the OpenShift internal registry to check http://localhost:8080/health.

For example:
serverReadinessScript: /bin/bash -c " /usr/bin/curl --noproxy '*' -s 'http://localhost:8080/health' | /usr/bin/grep -i 'status.*UP'"

webImage:
      webServerHealthCheck:
           serverLivenessScript

A string that specifies the logic for the pod liveness health check

This parameter is optional.

webImageStream

A set of parameters that control how the JWS Operator uses an image stream that provides images to run or to build upon

The JWS Operator uses the latest image in the image stream.

This parameter contains applicationImage, imagePullSecret, webApp, and webServerHealthCheck fields.

webImageStream:
      imageStreamName

The name of the image stream that you have created to allow the JWS Operator to find the base images

For example:
imageStreamName: my-image-name-imagestream:latest

webImageStream:
      imageStreamNamespace

The namespace or project where you have created the image stream

For example:
imageStreamNamespace: my-namespace

webImageStream:
      webSources

A set of parameters that describe where the application source files are located and how to build them

If you do not specify the webSources parameter, the JWS Operator deploys the latest image in the image stream.

This parameter contains sourceRepositoryUrl, sourceRepositoryRef, contextDir, and webSourcesParams fields.

webImageStream:
      webSources:
           sourceRepositoryUrl

The URL where the application source files are located

The source should contain a Maven pom.xml file to support a Maven build. When Maven generates a .war file for the application, the .war file is copied to the webapps directory of the image that the JWS Operator uses to deploy the application (for example, /opt/jws-5.x/tomcat/webapps).

For example:
sourceRepositoryUrl: 'https://github.com/$user/demo-webapp.git'

webImageStream:
      webSources:
           sourceRepositoryRef

The branch of the source repository that the JWS Operator uses

For example:
sourceRepositoryRef: main

webImageStream:
      webSources:
           contextDir

The subdirectory in the source repository where the pom.xml file is located and the mvn install command is run

For example:
contextDir: /

webImageStream:
      webSources:
           webSourcesParams

A set of parameters that describe how to build the application images

This parameter is optional.

This parameter contains mavenMirrorUrl, artifactDir, genericWebHookSecret, and githubWebHookSecret fields.

webImageStream:
      webSources:
           webSourcesParams:
                mavenMirrorUrl

The Maven proxy URL that Maven uses to build the web application

This parameter is required if the cluster does not have internet access.

webImageStream:
      webSources:
           webSourcesParams:
                artifactDir

The directory where Maven stores the .war file that Maven generates for the web application

The contents of this directory are copied to the webapps directory of the image that the JWS Operator uses to deploy the application (for example, /opt/jws-5.x/tomcat/webapps).

The default value is target.

webImageStream:
      webSources:
           webSourcesParams:
                genericWebHookSecret

The name of a secret for a generic webhook that can trigger a build

For more information about creating a secret, see Creating a secret for a generic or GitHub webhook.

For more information about using generic webhooks, see Webhook Triggers.

For example:
genericWebHookSecret: my-secret

webImageStream:
      webSources:
           webSourcesParams:
                githubWebHookSecret

The name of a secret for a GitHub webhook that can trigger a build

For more information about creating a secret, see Creating a secret for a generic or GitHub webhook.

For more information about using GitHub webhooks, see Webhook Triggers.

Note

You cannot perform manual tests of a GitHub webhook. GitHub generates the payload and it is not empty.

webImageStream:
      webServerHealthCheck

The health check that the JWS Operator uses

The default behavior is to use the health valve, which does not require any parameters.

This parameter contains serverReadinessScript and serverLivenessScript fields.

webImageStream:
      webServerHealthCheck:
           serverReadinessScript

A string that specifies the logic for the pod readiness health check

If this parameter is not specified, the JWS Operator uses the default health check by using the OpenShift internal registry to check http://localhost:8080/health.

For example:
serverReadinessScript: /bin/bash -c " /usr/bin/curl --noproxy '*' -s 'http://localhost:8080/health' | /usr/bin/grep -i 'status.*UP'"

webImageStream:
      webServerHealthCheck:
           serverLivenessScript

A string that specifies the logic for the pod liveness health check

This parameter is optional.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.