Chapter 7. Deploying your Jboss EAP application on the OpenShift Container Platform

Procedure

1. In the OpenShift Container Platform web console, navigate to Operators→ OperatorHub.
2. Scroll down or type EAP into the Filter by keyword box to find the EAP operator.
3. Select JBoss EAP operator and click Install.

4. On the Create Operator Subscription page:

   1. Select one of the following:

      • All namespaces on the cluster (default) installs the operator in the default openshift-operators namespace to watch and be made available to all namespaces in the cluster. This option is not always available.
      • A specific namespace on the cluster installs the operator in a specific, single namespace that you choose. The operator is made available for use only in this single namespace.
   2. Select an Update Channel.
   3. Select Automatic or Manual approval strategy, as described earlier.

5. Click Subscribe to make the EAP operator available to the selected namespaces on this OpenShift Container Platform cluster.

   1. If you selected a manual approval strategy, the subscription’s upgrade status remains Upgrading until you review and approve its install plan. After you approve the install plan on the Install Plan page, the subscription upgrade status moves to Up to date.
   2. If you selected an automatic approval strategy, the upgrade status moves to Up to date without intervention.

6. After the subscription’s upgrade status is Up to date, select Operators Installed Operators to verify that the EAP ClusterServiceVersion (CSV) shows up and its Status changes to InstallSucceeded in the relevant namespace.

   Note

   For the All namespaces…​ installation mode, the status displayed is InstallSucceeded in the openshift-operators namespace. In other namespaces the status displayed is Copied. . If the Status field does not change to InstallSucceeded, check the logs in any pod in the openshift-operators project (or other relevant namespace if A specific namespace…​ installation mode was selected) on the Workloads Pods page that are reporting issues to troubleshoot further.

Procedure

1. View the list of operators available to the cluster from the OperatorHub:

   $ oc get packagemanifests -n openshift-marketplace | grep eap
   NAME        CATALOG               AGE
   ...
   eap         Red Hat Operators     43d
   ...

   Copy to Clipboard Toggle word wrap

2. Create a Subscription object YAML file (for example, eap-operator-sub.yaml) to subscribe a namespace to your EAP operator. The following is an example Subscription object YAML file:

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: eap
     namespace: openshift-operators
   spec:
     channel: stable
     installPlanApproval: Automatic
     name: eap 

   1

   
     source:  redhat-operators 

   2

   
     sourceNamespace: openshift-marketplace

   Copy to Clipboard Toggle word wrap

   1

   Name of the operator to subscribe to.

   2

   The EAP operator is provided by the redhat-operators CatalogSource.

   For information about channels and approval strategy, see the web console version of this procedure.

3. Create the Subscription object from the YAML file:

   $ oc apply -f eap-operator-sub.yaml
   $ oc get csv -n openshift-operators
   NAME                  DISPLAY     VERSION   REPLACES   PHASE
   eap-operator.v1.0.0   JBoss EAP   1.0.0                Succeeded

   Copy to Clipboard Toggle word wrap

   The EAP operator is successfully installed. At this point, the OLM is aware of the EAP operator. A ClusterServiceVersion (CSV) for the operator appears in the target namespace, and APIs provided by the EAP operator is available for creation.

Procedure

1. Open your web browser and log on to OperatorHub.
2. Select the Project or namespace you want to use for your Java application.
3. Navigate to Installed Operator and select JBoss EAP operator.
4. On the Overview tab, click the Create Instance link.

5. Specify the application image details.

   The application image specifies the Docker image that contains the Java application. The image must be built using the JBoss EAP for OpenShift Source-to-Image (S2I) build image. If the applicationImage field corresponds to an imagestreamtag, any change to the image triggers an automatic upgrade of the application.

   You can provide any of the following references of the JBoss EAP for OpenShift application image:

   • The name of the image: mycomp/myapp
   • A tag: mycomp/myapp:1.0
   • A digest: mycomp/myapp:@sha256:0af38bc38be93116b6a1d86a9c78bd14cd527121970899d719baf78e5dc7bfd2
   • An imagestreamtag: my-app:latest

6. Specify the size of the application. For example:

   spec:
     replicas:2

   Copy to Clipboard Toggle word wrap

7. Configure the application environment using the env spec. The Environment variables can come directly from values, such as POSTGRESQL_SERVICE_HOST or from Secret objects, such as POSTGRESQL_USER. For example:

   spec:
     env:
     - name: POSTGRESQL_SERVICE_HOST
       value: postgresql
     - name: POSTGRESQL_SERVICE_PORT
       value: '5432'
     - name: POSTGRESQL_DATABASE
       valueFrom:
         secretKeyRef:
           key: database-name
           name: postgresql
     - name: POSTGRESQL_USER
       valueFrom:
         secretKeyRef:
           key: database-user
           name: postgresql
     - name: POSTGRESQL_PASSWORD
       valueFrom:
         secretKeyRef:
           key: database-password
           name: postgresql

   Copy to Clipboard Toggle word wrap

8. Complete the following optional configurations that are relevant to your application deployment:

   • Specify the storage requirements for the server data directory. For more information, see Configuring Persistent Storage for Applications.

   • Specify the name of the Secret you created in WildFlyServerSpec to mount it as a volume in the pods running the application. For example:

     spec:
       secrets:
         - my-secret

     Copy to Clipboard Toggle word wrap

     The Secret is mounted at /etc/secrets/<secret name> and each key/value is stored as a file. The name of the file is the key and the content is the value. The Secret is mounted as a volume inside the pod. The following example demonstrates commands that you can use to find key values:

     $ ls /etc/secrets/my-secret/
     my-key  my-password
     $ cat /etc/secrets/my-secret/my-key
     devuser
     $ cat /etc/secrets/my-secret/my-password
     my-very-secure-pasword

     Copy to Clipboard Toggle word wrap
     Note

     Modifying a Secret object might lead to project inconsistencies. Instead of modifying an existing Secret object, Red Hat recommends creating a new object with the same content as that of the old one. You can then update the content as required and change the reference in operator custom resource (CR) from old to new. This is considered a new CR update and the pods are reloaded.

   • Specify the name of the ConfigMap you created in WildFlyServerSpec to mount it as a volume in the pods running the application. For example:

     spec:
       configMaps:
       - my-config

     Copy to Clipboard Toggle word wrap

     The ConfigMap is mounted at /etc/configmaps/<configmap name> and each key/value is stored as a file. The name of the file is the key and the content is the value. The ConfigMap is mounted as a volume inside the pod. To find the key values:

     $ ls /etc/configmaps/my-config/
     key1 key2
     $ cat /etc/configmaps/my-config/key1
     value1
     $ cat /etc/configmaps/my-config/key2
     value2

     Copy to Clipboard Toggle word wrap
     Note

     Modifying a ConfigMap might lead to project inconsistencies. Instead of modifying an existing ConfigMap, Red Hat recommends creating a new ConfigMap with the same content as that of the old one. You can then update the content as required and change the reference in operator custom resource (CR) from old to new. This is considered a new CR update and the pods are reloaded.

   • If you choose to have your own standalone ConfigMap, provide the name of the ConfigMap as well as the key for the standalone.xml file:

       standaloneConfigMap:
         name: clusterbench-config-map
         key: standalone.xml

     Copy to Clipboard Toggle word wrap
     Note

     Creating a ConfigMap from the standalone.xml file is not supported in JBoss EAP 8.1.

   • If you want to disable the default HTTP route creation in OpenShift, set disableHTTPRoute to true:

     spec:
       disableHTTPRoute: true

     Copy to Clipboard Toggle word wrap

Procedure

1. In the OpenShift Container Platform web console, navigate to Monitoring→ Metrics.
2. On the Metrics screen, type the name of your application in the text box to select your application. The metrics for your application appear on the screen.

Procedure

1. From the Operators→ Installed Operators page, select JBoss EAP.
2. On the right-hand side of the Operator Details page, select Uninstall Operator from the Actions drop-down menu.
3. When prompted by the Remove Operator Subscription window, optionally select the Also completely remove the Operator from the selected namespace check box if you want all components related to the installation to be removed. This removes the CSV, which in turn removes the pods, deployments, custom resource definitions (CRDs), and custom resources (CRs) associated with the operator.
4. Click Remove. The EAP operator stops running and no longer receives updates.

Procedure

1. Check the current version of the EAP operator subscription in the currentCSV field:

   $ oc get subscription eap-operator -n openshift-operators -o yaml | grep currentCSV
     currentCSV: eap-operator.v1.0.0

   Copy to Clipboard Toggle word wrap

2. Delete the EAP operator’s subscription:

   $ oc delete subscription eap-operator -n openshift-operators
   subscription.operators.coreos.com "eap-operator" deleted

   Copy to Clipboard Toggle word wrap

3. Delete the CSV for the EAP operator in the target namespace using the currentCSV value from the previous step:

   $ oc delete clusterserviceversion eap-operator.v1.0.0 -n openshift-operators
   clusterserviceversion.operators.coreos.com "eap-operator.v1.0.0" deleted

   Copy to Clipboard Toggle word wrap

Procedure

1. Configure the resources:

   apiVersion: wildfly.org/v1alpha1
   kind: WildFlyServer
   metadata:
     name: eap-helloworld
   spec:
     applicationImage: 'eap-helloworld:latest'
     replicas: 1
     resources:
       limits:
         cpu: 500m
         memory: 2Gi
       requests:
         cpu: 100m
         memory: 1Gi

   Copy to Clipboard Toggle word wrap
   Important

   You must specify the resource limits and requests for containers in a pod for autoscaling to work as expected.

2. Create the Horizontal pod autoscaler:

   oc autoscale wildflyserver/eap-helloworld --cpu-percent=50 --min=1 --max=10

   Copy to Clipboard Toggle word wrap