Chapter 7. JWS Operator CRD parameters
Chapter 7. JWS Operator CRD parameters 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: 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 name Description 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/USDuser/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/USDuser/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/USDuser/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/USDuser/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.
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>