Chapter 3. JWS Operator for OpenShift


The Operator Framework is a toolkit to manage Kubernetes-native applications, which are called Operators, in an effective, automated, and scalable way. Operators make it easy to manage complex stateful applications that are running on top of Kubernetes. All Operators are based around three key components, which are the Operator SDK, the Operator Lifecycle Manager, and OperatorHub.io. These tools allow you to develop your own Operators, manage any Operators that you are using on your Kubernetes cluster, and discover or share any Operators that the community creates.

3.1. JBoss Web Server operator

Red Hat JBoss Web Server (JWS) provides an Operator that you can use to manage JWS for OpenShift images. You can build, test, and package the JWS Operator for OpenShift.

The JWS Operator uses different environment variables than a standard JWS for OpenShift setup. For more information about the environment variables that the JWS Operator uses, see Parameters to use in CRD.

Important

In this release, the Use Session Clustering functionality is available as a Technology Preview feature only. The session clustering is set to Off by default. 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.

You can follow the instructions in this document to install the JWS Operator, deploy an existing JWS image, and delete Operators from a cluster. For a faster but less detailed guide to deploying a prepared image or building an image from an existing image stream, see the QuickStart guide.

Important

Red Hat supports images for JWS 5.4 or later versions. Support is not available for images earlier than JWS 5.4.

3.2. Operator groups

An Operator group is an Operator Lifecycle Manger (OLM) resource that provides multitenant configuration to OLM-installed Operators. An Operator group selects target namespaces in which to generate role-based access control (RBAC) for all Operators that are deployed in the same namespace as the OperatorGroup object.

When you subscribe the Operator to a namespace, you must ensure that the namespace has an OperatorGroup object that uses the same InstallModeType setting as the Operator. The InstallModeType settings are AllNamespaces and SingleNamespace.

Consider the following guidelines:

  • If the Operator you want to install uses AllNamespaces mode, the openshift-operators namespace already provides an appropriate Operator group.
  • If the Operator you want to install uses SingleNamespace mode, you must create only one Operator group in that namespace.

Additional resources

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

  1. In your project namespace, create an image stream by using the oc import-image command 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 \
    --confirm

    In 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>-imagestream by importing information for the quay.io/$user/<my-image> image. For more information about the format and management of image streams, see Managing image streams.

  2. Create a custom resource of the WebServer kind 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>-imagestream
  3. Trigger an update to the image stream by using the oc tag command.

    For example:

    oc tag quay.io/$user/<my-image> <my-image>-imagestream:latest --scheduled

    The 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 and configuring a generic or GitHub webhook in a custom resource WebServer file, see Parameters to use in CRD.

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-Q2
  • rht.comp: JBoss_Web_Server
  • rht.comp_ver: 5.6.2
  • 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-Q2
    rht.comp: JBoss_Web_Server
    rht.comp_ver: 5.6.2
    rht.subcomp: Tomcat 9
    rht.subcomp_t: application
spec:
----
Note

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:

  • imagePullSecret

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

    Note

    The 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. The Secret object 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.

  • webApp

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

  • name

    The name of the web server application

  • sourceRepositoryURL

    The URL where the application source files are located

  • sourceRepositoryRef

    The branch of the source repository that the Operator uses

  • sourceRepositoryContextDir

    The subdirectory where the pom.xml file is located and where the mvn install command must be run

  • webAppWarImage

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

  • webAppWarImagePushSecret

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

  • builder

    A set of parameters that contain all the information required to build the web application and create and push 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 security context constraint (SCC).

    To grant the builder access to the anyuid SCC, enter the following command:

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

    The builder parameter contains the following fields:

    • image

      The image of the container where the web application is built (for example, quay.io/$user/tomcat10-buildah)

    • imagePullSecret

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

    • applicationBuildScript

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

      Note

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

Additional resources

3.4. JWS Operator installation

You can install the JBoss Web Server (JWS) Operator for OpenShift by using either of the following methods:

3.4.1. Installing the JWS Operator by using the web console

You can install the JWS Operator by using the OpenShift web console.

Prerequisites

  • You have deployed an OpenShift Container Platform cluster using an account with cluster admin and Operator installation permissions.

Procedure

  1. Open the web console and navigate to the Operators tab.

    The OpenShift OperatorHub opens.

  2. Search for JWS and select the JWS Operator.

    A new menu displays.

  3. Select the Capacity Level that you want to use.
  4. To install the Operator, at the start of the console, click Install.
  5. To set up the Operator installation, perform the following steps:

    1. Specify the installation mode by specifying the namespace on your cluster where you want to install the Operator.

      Note

      If you do not specify a namespace, the Operator is installed to all namespaces on your cluster by default.

    2. Specify the update channel where the JWS Operator is available.

      Note

      The JWS Operator is currently available only through one channel.

    3. Specify the approval strategy by selecting Automatic or Manual updates.

      Note

      If you select Automatic updates, when a new version of the Operator is available, the Operator Lifecycle Manager (OLM) upgrades the running instance of your Operator automatically.

      If you select Manual updates, when a newer version of the Operator is available, the OLM creates an update request. As a cluster administrator, you must then manually approve the update request to ensure that the Operator is updated to the new version.

  6. Click Install.

    Note

    If you have selected a Manual approval strategy, you must approve the install plan before the installation is complete. The JWS Operator now appears in the Installed Operators section of the Operators tab.

3.4.2. Installing the JWS Operator from the command line

You can install the JWS Operator by using the oc command-line tool. The steps to install the JWS Operator from the command line include verifying the supported installModes and available channels for the Operator, creating an Operator group, and creating a Subscription object.

Note

When you install the JWS Operator by using the web console, and the Operator is using SingleNamespace mode, the OperatorGroup and Subscription objects are installed automatically

Prerequisites

  • You have deployed an OpenShift Container Platform cluster using an account with Operator installation permissions.
  • You have installed the oc tool on your local system.

Procedure

  1. To inspect the JWS Operator, perform the following steps:

    1. To verify the supported installation modes for the JWS Operator, enter the following command:

      $ oc get packagemanifests -n openshift-marketplace | grep jws

      The preceding command produces the following type of output:

      jws-operator    Red Hat Operators   16h
    2. To verify the available channels for the JWS Operator, enter the following command:

      $ oc describe packagemanifests jws-operator -n openshift-marketplace | grep "Catalog Source"

      The preceding command produces the following type of output:

      Catalog Source:     redhat-operators
  2. To create an Operator group, perform the following steps:

    1. To check the actual list of Operator groups, enter the following command:

      $ oc get operatorgroups -n <project_name>
      Note

      In the preceding example, replace <project_name> with your OpenShift project name.

      The preceding command produces the following type of output:

      NAME       AGE
      mygroup    17h
    2. Create a YAML file for the OperatorGroup object.

      For example:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <project_name>
      spec:
        targetNamespaces:
        - <project_name>
      Note

      In the preceding example, replace <project_name> with the namespace of the project where you want to install the Operator (oc project -q). and replace `<operatorgroup_name> with the name of the OperatorGroup object.

    3. Create the OperatorGroup object from the YAML file:

      $ oc apply -f <filename>.yaml
      Note

      In the preceding example, replace <filename>.yaml with the name of the YAML file that you have created for the OperatorGroup object.

  3. To create a Subscription object, perform the following steps:

    1. Create a YAML file for the Subscription object.

      For example:

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: jws-operator
          namespace: <project_name>
      spec:
          channel: alpha
          name: jws-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace
      Note

      In the preceding example, replace <project_name> with the namespace of the project where you want to install the Operator (oc project -q). If the Operator is using AllNamespaces mode, replace <project_name> with openshift-operators.

      Ensure that the source setting matches the Catalog source value based on the command-line output when you verified the available channels for the Operator (for example, redhat-operators).

    2. Create the Subscription object from the YAML file:

      $ oc apply -f <filename>.yaml
      Note

      In the preceding example, replace <filename>.yaml with the name of the YAML file that you have created for the Subscription object.

Verification

  • To verify that the JWS Operator is installed successfully, enter the following command:

    $ oc get csv -n <project_name>
    Note

    In the preceding example, replace <project_name> with the namespace of the project where have installed the Operator.

    The preceding command produces the following type of output:

    NAMEDISPLAYVERSIONREPLACES PHASE

    jws-operator.V<version>

    JBoss Web Server Operator

    <version>

    Succeeded

    Note

    In the preceding example, <version> refers to the Operator version (for example, 1.1.0).

3.5. Deploying an existing JWS image

You can deploy an existing JWS image by using the OpenShift web console.

Prerequisites

  • You have installed the JWS Operator by using the web console or from the command line.

    To ensure that the JWS Operator is installed, enter the following command:

    $ oc get deployment.apps/jws-operator

    The preceding command produces the following type of output:

    NAME            READY 	UP-TO-DATE   AVAILABLE   AGE
    jws-operator    1/1   	1            1           15h
    Note

    If you want to view more detailed output, you can use the following command:

    oc describe deployment.apps/jws-operator

Procedure

  1. Prepare your image and push it to the location where you want to display the image (for example, quay.io/<USERNAME>/tomcat-demo:latest).
  2. To create a YAML file for a Custom Resource web server, perform the following steps:

    1. Create a file named, for example, webservers_cr.yaml.
    2. Enter details in the following format:

      apiVersion: web.servers.org/v1alpha1
      kind: WebServer
      metadata:
          name: example-image-webserver
      spec:
          # Add fields here
          applicationName: jws-app
          replicas: 2
      webImage:
         applicationImage: quay.io/<USERNAME>/tomcat-demo:latest
  3. To deploy your web application, perform the following steps:

    1. Go to the directory where you have created the web application.
    2. Enter the following command:

      $ oc apply -f webservers_cr.yaml

      The preceding command produces the following output:

      webserver/example-image-webserver created
      Note

      The Operator creates a route automatically.

  4. Verify the route that the Operator creates:

    $ oc get routes
  5. Optional: Delete the webserver that you created in the preceding step:

    $ oc delete webserver example-image-webserver
    Note

    Alternatively, you can delete the webserver by deleting the YAML file. For example:

    oc delete -f webservers_cr.yaml

3.6. JWS Operator deletion

You can delete the JWS Operator from a cluster by using either of the following methods:

3.6.1. Deleting the JWS Operator by using the web console

You can delete the JWS Operator from a cluster by using the OpenShift web console.

Prerequisites

  • You have deployed an OpenShift Container Platform cluster using an account with cluster admin permissions.

    Note

    If you do not have cluster admin permissions, you can circumvent this requirement. For more information, see Allowing non-cluster administrators to install Operators.

Procedure

  1. Open the web console and click Operators > Installed Operators.
  2. Select the Actions menu and click Uninstall Operator.

    Note

    The Uninstall Operator option automatically removes the Operator, any Operator deployments, and Pods.

    Deleting the Operator does not remove any custom resource definitions or custom resources for the Operator, including CRDs or CRs. If the Operator has deployed applications on the cluster, or if the Operator has configured off-cluster resources, you must clean up these applications and resources manually.

3.6.2. Deleting the JWS Operator from the command line

You can delete the JWS Operator from a cluster by using the oc command-line tool.

Prerequisites

  • You have deployed an OpenShift Container Platform cluster using an account with cluster admin permissions.

    Note

    If you do not have cluster admin permissions, you can circumvent this requirement. For more information, see Allowing non-cluster administrators to install Operators.

  • You have installed the oc tool on your local system.

Procedure

  1. Check the current version of the subscribed Operator:

    $ oc get subscription jws-operator -n <project_name> -o yaml | grep currentCSV
    Note

    In the preceding command, replace <project_name> with the namespace of the project where you installed the Operator. If your Operator was installed to all namespaces, replace <project_name> with openshift-operators.

    The preceding command produces the following output, where v<version> refers to the Operator version (for example, v1.1.0):

    f:currentCSV: {}
    currentCSV: jws-operator.v<version>
  2. Delete the subscription for the Operator:

    $ oc delete subscription jws-operator -n <project_name>
    Note

    In the preceding command, replace <project_name> with the namespace of the project where you installed the Operator. If your operator was installed to all namespaces, replace <project_name> with openshift-operators.

  3. Delete the CSV for the Operator in the target namespace by using the currentCSV value that you obtained from the previous steps:

    $ oc delete clusterserviceversion <currentCSV> -n <project_name>
    Note

    In the preceding command, replace <project_name> with the namespace of the project where you installed the Operator, and replace <currentCSV> with the currentCSV value that you obained in the preceding steps (for example, jws-operator.v<version>).

    The preceding command produces the following type of output:

    clusterserviceversion.operators.coreos.com "jws-operator.v<version>" deleted
    Note

    In the preceding command, <project_name> refers to the namespace of the project where you installed the operator, and v<version> refers to the operator version (for example, v1.1.0). If your operator was installed to all namespaces, use openshift-operators in place of <project_name>.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.