Chapter 7. JWS Operator CRD parameters

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.

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

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:
           webhookSecrets

A set of parameters that specify secret names for triggering a build through a webhook

This parameter contains generic, github, and gitlab fields.

webImageStream:
      webSources:
           webhookSecrets:
                generic

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 webhook.

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

For example:
generic: jws-secret

webImageStream:
      webSources:
           webhookSecrets:
                github

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 webhook.

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

For example:
github: jws-secret

webImageStream:
      webSources:
           webhookSecrets:
                gitlab

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

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

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

For example:
gitlab: jws-secret

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

A webhook secret string

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

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

For example:
genericWebhookSecret: qwerty

webImageStream:
      webSources:
           webSourcesParams:
                githubWebhookSecret

A webhook secret string specific to GitHub

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

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

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.

tlsConfig

A set of parameters that specify the TLS configuration for a web server

This parameter contains routeHostname, certificateVerification, tlsSecret, and tlsPassword fields.

tlsConfig:
      routeHostname

Indicates whether the Operator should create a route or whether the route uses TLS

Supported values are NONE and tls:

For example:
routeHostname: NONE

tlsConfig:
      certificateVerification

Indicates whether the Operator should use the TLS connector with a client certificate

Supported values are required, optional, or empty.

For more information, see the Apache Tomcat HTTP Connector documentation about the certificateVerification attribute.

For example:
certificateVerification: required

tlsConfig:
      tlsSecret

The secret to use for the server certificate (server.cert) and server key (server.key) and the optional CA certificate for the client certificates (ca.cert)

For example:
tlsSecret: tlssecret

tlsConfig:
      tlsPassword

The passphrase used to protect the server key (server.key)

For example:
tlsPassword: changeit

environmentVariables

Environment variables for deployment

persistentLogs

A set of parameters that specify persistent volume and logging configuration

This parameter contains catalinaLogs, enableAccessLogs, volumeName, and storageClass fields.

persistentLogs:
      catalinaLogs

Indicates whether the catalina.out log file for every pod is saved in a persistent volume, to remain available after a possible pod failure.

Supported values are true or false.

For example:
catalinaLogs: true

persistentLogs:
      enableAccessLogs

Indicates whether the access_log log file for every pod is saved in a persistent volume, to remain available after a possible pod failure.

Supported values are true or false.

For example:
enableAccessLogs: true

persistentLogs:
      volumeName

Name of the persistent volume that is used to store the log files

For example:
volumeName: pv0000

persistentLogs:
      storageClass

Name of the storage class of the persistent volume that is used to store the log files

For example:
storageClass: nfs-client

podResources

Specifies the configuration of the CPU and memory resources that the web server uses

These values must be categorized under limits and requests.

For example:

resources:
   limits:
      cpu: 500m
   requests:
      cpu: 200m

These values are used for autoscaling. For more information about autoscaling, see Automatically scaling pods with the horizontal pod autoscaler.

securityContext

Defines the security capabilities that are required to run the application

volumeSpec

A set of parameters that specify the volumes to be mounted

This parameter contains persistentVolumeClaims, secrets, configMaps, and volumeClaimTemplates fields.

volumeSpec:
      persistentVolumeClaims

A list of the names of persistent volume claims (PVCs) that are to be mounted to the /volumes directory

For example:
persistentVolumeClaims:
      - <pvc1>
      - <pvc2>

volumeSpec:
      secrets

A list of the names of secrets that are to be mounted to the /secrets directory

For example:
secrets:
      - <secret1>
      - <secret2>

volumeSpec:
      configMaps

A list of the names of config maps that are to be mounted to the /configmaps directory

For example:
configMaps:
      - <configmap1>
      - <configmap2>

volumeSpec:
      volumeClaimTemplates

A list of PersistentVolumeClaimSpec properties for stateful applications

For more information about PersistentVolumeClaimSpec, see Storage APIs: PersistentVolumeClaim [v1].

useInsightsClient

Indicates whether to create a connection with the runtimes inventory operator that Red Hat provides

Supported values are true or false.

For example:
useInsightsClient: true

You can enable debug logging for the Insights client by setting the INSIGHTS_DEBUG environment variable to true.