Chapter 7. EAP Operator for Automating Application Deployment on OpenShift

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.

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

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

   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

   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. Import EAP images in OpenShift. For more information, see Importing the OpenShift image streams and templates for JBoss EAP XP.
2. Configure the imagestream to receive updates about the changes in the application imagestream and to trigger new builds. For more information, see Configuring periodic importing of imagestreamtags.

3. Create the eap-s2i-build template for building the application image using EAP S2I images:

   $ oc replace --force -f https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/master/eap-s2i-build.yaml

   This eap-s2i-build template creates two build configurations and two imagestreams corresponding to the intermediate build artifacts and the final application image.

4. Process the eap-s2i-build template with parameters to create the resources for the final application image. The following example creates an application image, my-app:

   $ oc process eap-s2i-build \
     -p APPLICATION_IMAGE=my-app \ 1
     \
     -p EAP_IMAGE=jboss-eap-xp1-openjdk11-openshift:1.0 \ 2
     -p EAP_RUNTIME_IMAGE=jboss-eap-xp1-openjdk11-runtime-openshift:1.0 \ 3
     -p EAP_IMAGESTREAM_NAMESPACE=$(oc project -q) \ 4
     \
     -p SOURCE_REPOSITORY_URL=https://github.com/jboss-developer/jboss-eap-quickstarts.git \ 5
     -p SOURCE_REPOSITORY_REF=xp-1.0.x \ 6
     -p CONTEXT_DIR=microprofile-config | oc create -f - 7

   1

   The name for the application imagestream. The application image is tagged with the latest tag.

   2

   The imagestreamtag for EAP builder image.

   3

   The imagestreamtag for EAP runtime image.

   4

   The namespace in which the imagestreams for Red Hat Middleware images are installed. If omitted, the openshift namespace is used. Modify this only if you have installed the imagestreams in a namespace other than openshift.

   5

   The Git source URL of your application.

   6

   The Git branch or tag reference

   7

   The path within the Git repository that contains the application to build.

5. Prepare the application image for deployment using the EAP operator.

   1. Configure the WildFlyServer resource:

      $ cat > my-app.yaml<<EOF
      
      apiVersion: wildfly.org/v1alpha1
      kind: WildFlyServer
      metadata:
        name: my-app
      spec:
       applicationImage: 'my-app:latest'
       replicas: 1
      EOF

   2. Apply the settings and let the EAP operator create a new WildFlyServer resource that references this application image:

      $ oc apply -f my-app.yaml

   3. View the WildFlyServer resource with the following command:

      $ oc get wfly my-app

      Additional resources

      • For more information about importing an application imagestream, see Importing the latest OpenShift image streams and templates for JBoss EAP XP.
      • For more information about periodic importing of imagestreams, see Configuring periodic importing of imagestreamtags.

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

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

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

     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

     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

     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

     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-openshift.xml

     Note

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

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

     spec:
       disableHTTPRoute: true

Procedure

1. Remove the DeploymentConfig file, created by the eap74-sso-s2i template, from the location where you have built the EAP application image.

2. In the env field of the EAP operator’s WildFlyServer resource, configure all the environment variables and secrets.

   Example configuration

   $ cat > my-app.yaml<<EOF
   
   apiVersion: wildfly.org/v1alpha1
   kind: WildFlyServer
   metadata:
     name: my-app
   spec:
     applicationImage: 'my-app:latest'
     replicas: 1
   
     env:
     - name: SSO_URL
       value: https://secure-sso-sso-app-demo.openshift32.example.com/auth
     - name: SSO_REALM
       value: eap-demo
     - name: SSO_PUBLIC_KEY
       value: realm-public-key
     - name: SSO_USERNAME
       value: mySsoUser
     - name: SSO_PASSWORD
       value: 6fedmL3P
     - name: SSO_SAML_KEYSTORE
       value: /etc/secret/sso-app-secret/keystore.jks
     - name: SSO_SAML_KEYSTORE_PASSWORD
       value: mykeystorepass
     - name: SSO_SAML_CERTIFICATE_NAME
       value: jboss
     - name: SSO_BEARER_ONLY
       value: true
     - name: SSO_CLIENT
       value: module-name
     - name: SSO_ENABLE_CORS
       value: true
     - name: SSO_SECRET
       value: KZ1QyIq4
     - name: SSO_DISABLE_SSL_CERTIFICATE_VALIDATION
       value: true
     - name: SSO_SAML_KEYSTORE_SECRET
       value: sso-app-secret
     - name: HTTPS_SECRET
       value: eap-ssl-secret
     - name: SSO_TRUSTSTORE_SECRET
       value: sso-app-secret
   EOF

   Note

   • Ensure that all environment variables and secrets match the image configuration.
   • The value of the parameter SSO_URL varies depending on the user of the OpenShift cluster.
   • The EAP operator mounts the secrets in the /etc/secret directory, whereas the eap74-sso template mounts the secrets in the /etc directory.
3. Save the EAP operator’s WildFlyServer resource configuration.

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

2. Delete the EAP operator’s subscription:

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

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

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

   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