Getting Started with JBoss EAP for OpenShift Container Platform

1. OpenJDK images and architectures

1. Log in to your OpenShift instance using the oc login command.

2. Create a new project in OpenShift.

   A project allows a group of users to organize and manage content separately from other groups. You can create a project in OpenShift using the following command.

   $ oc new-project <project_name>

   For example, for the kitchensink quickstart, create a new project named eap-demo using the following command.

   $ oc new-project eap-demo

3. Optional: Create a keystore and a secret.

   Note

   Creating a keystore and a secret is required if you are using any HTTPS-enabled features in your OpenShift project. For example, if you are using the eap74-https-s2i template, you must create a keystore and secret.

   This workflow demonstration for the kitchensink quickstart does not use an HTTPS template, so a keystore and secret are not required.

   1. Create a keystore.

      Warning

      The following commands generate a self-signed certificate, but for production environments Red Hat recommends that you use your own SSL certificate purchased from a verified Certificate Authority (CA) for SSL-encrypted connections (HTTPS).

      You can use the Java keytool command to generate a keystore:

      $ keytool -genkey -keyalg RSA -alias <alias_name> -keystore <keystore_filename.jks> -validity 360 -keysize 2048

      For example, for the kitchensink quickstart, use the following command to generate a keystore:

      $ keytool -genkey -keyalg RSA -alias eapdemo-selfsigned -keystore keystore.jks -validity 360 -keysize 2048

   2. Create a secret from the keystore.

      Create a secret from the previously created keystore using the following command.

      $ oc create secret generic <secret_name> --from-file=<keystore_filename.jks>

      For example, for the kitchensink quickstart, use the following command to create a secret.

      $ oc create secret generic eap7-app-secret --from-file=keystore.jks

1. Follow the instructions on Red Hat Customer Portal to create an authentication token using a registry service account.
2. Download the YAML file containing the OpenShift secret for the token. You can download the YAML file from the OpenShift Secret tab on your token’s Token Information page.

3. Create the authentication token secret for your OpenShift project using the YAML file that you downloaded:

   oc create -f 1234567_myserviceaccount-secret.yaml

4. Configure the secret for your OpenShift project using the following commands, replacing the secret name in the example with the name of your secret created in the previous step.

   oc secrets link default 1234567-myserviceaccount-pull-secret --for=pull
   oc secrets link builder 1234567-myserviceaccount-pull-secret --for=pull

Procedure

1. Create a new OpenShift application that uses the JBoss EAP for OpenShift image and the source code of your Java application. You can use one of the provided JBoss EAP for OpenShift templates for S2I builds. You can also choose to provision a trimmed server.

   For example, to deploy the kitchensink quickstart using the JDK 8 builder image, enter the following command to use the eap74-basic-s2i template in the eap-demo project, created in Prepare OpenShift for Application Deployment, with the kitchensink source code on GitHub. This quickstart does not support the trimming capability.

   oc new-app --template=eap74-basic-s2i \ 1
    -p IMAGE_STREAM_NAMESPACE=eap-demo \ 2
    -p EAP_IMAGE_NAME=jboss-eap74-openjdk8-openshift:7.4.0 \ 3
    -p EAP_RUNTIME_IMAGE_NAME=jboss-eap74-openjdk8-runtime-openshift:7.4.0 \ 4
    -p SOURCE_REPOSITORY_URL=https://github.com/jboss-developer/jboss-eap-quickstarts \ 5
    -p SOURCE_REPOSITORY_REF=7.4.x \ 6
    -p CONTEXT_DIR=kitchensink 7

   1

   The template to use.

   2

   The latest imagestreams and templates were imported into the project’s namespace, so you must specify the namespace where to find the imagestream. This is usually the project’s name.

   3

   The name of the EAP builder image stream for JDK8.

   4

   The name of the EAP runtime image stream for JDK8.

   5

   URL to the repository containing the application source code.

   6

   The Git repository reference to use for the source code. This can be a Git branch or tag reference.

   7

   The directory within the source repository to build.

   As another example, to deploy the helloworld-html5 quickstart using the JDK 11 runtime image and trimming JBoss EAP to include only the jaxrs-server layer, enter the following command. The command uses the eap74-basic-s2i template in the eap-demo project, created in Prepare OpenShift for Application Deployment, with the helloworld-html5 source code on GitHub.

   oc new-app --template=eap74-basic-s2i \ 1
    -p IMAGE_STREAM_NAMESPACE=eap-demo \ 2
    -p EAP_IMAGE_NAME=jboss-eap74-openjdk11-openshift:7.4.0 \ 3
    -p EAP_RUNTIME_IMAGE_NAME=jboss-eap74-openjdk11-runtime-openshift:7.4.0 \ 4
    -p SOURCE_REPOSITORY_URL=https://github.com/jboss-developer/jboss-eap-quickstarts \ 5
    -p SOURCE_REPOSITORY_REF=7.4.x \ 6
    -p GALLEON_PROVISION_LAYERS=jaxrs-server \ 7
    -p CONTEXT_DIR=helloworld-html5 8

   1

   The template to use.

   2

   The latest imagestreams and templates were imported into the project’s namespace, so you must specify the namespace where to find the imagestream. This is usually the project’s name.

   3

   The name of the EAP builder image stream for JDK11.

   4

   The name of the EAP runtime image stream for JDK11.

   5

   URL to the repository containing the application source code.

   6

   The Git repository reference to use for the source code. This can be a Git branch or tag reference.

   7

   Provision a trimmed server with only the jaxrs-server layer.

   8

   The directory within the source repository to build.

   Note

   You might also want to configure environment variables when creating your new OpenShift application.

   For example, if you are using an HTTPS template such as eap74-https-s2i, you must specify the required HTTPS environment variables HTTPS_NAME, HTTPS_PASSWORD, and HTTPS_KEYSTORE to match your keystore details.

   Note

   If the template uses AMQ, you must include the AMQ_IMAGE_NAME parameter with the appropriate value.

   If the template uses SSO, you must include the SSO_IMAGE_NAME parameter with the appropriate value.

2. Retrieve the name of the build configuration.

   $ oc get bc -o name

3. Use the name of the build configuration from the previous step to view the Maven progress of the build.

   $ oc logs -f buildconfig/BUILD_CONFIG_NAME

   For example, for the kitchensink quickstart, the following command shows the progress of the Maven build.

   $ oc logs -f buildconfig/eap-app

1. Get the service name of your application using the following command.

   $ oc get service

2. Expose the main service as a route so you can access your application from outside of OpenShift. For example, for the kitchensink quickstart, use the following command to expose the required service and port.

   $ oc expose service/eap-app --port=8080

   Note

   If you used a template to create the application, the route might already exist. If it does, continue on to the next step.

3. Get the URL of the route.

   $ oc get route

4. Access the application in your web browser using the URL. The URL is the value of the HOST/PORT field from the previous command’s output.

   If your application does not use the JBoss EAP root context, append the context of the application to the URL. For example, for the kitchensink quickstart, the URL might be http://HOST_PORT_VALUE/kitchensink/.

5. Optionally, you can also scale up the application instance by running the following command. This increases the number of replicas to 3.

   $ oc scale deploymentconfig DEPLOYMENTCONFIG_NAME --replicas=3

   For example, for the kitchensink quickstart, use the following command to scale up the application.

   $ oc scale deploymentconfig eap-app --replicas=3

Procedure

1. In the main navigation, click the drop-down menu and select Developer.

2. In the navigation menu, click Add.

   The Add page opens.

3. In the Add page, click Helm Chart.
4. In the Helm Charts catalog, search for JBoss EAP 7.4.

5. Click the JBoss EAP 7.4 Helm chart tile.

   The side panel displays information about the JBoss EAP 7 Helm chart.

6. Click Install Helm Chart.

   Some form sections are collapsed by default. Click > to expand and view its content.

   Note

   No updates are required to these sections to proceed.

   The details about the Jakarta EE application that you are building and deploying are specified in the build.uri field.

   build:
     uri: https://github.com/jboss-eap-up-and-running/eap7-getting-started

   Note

   If you are building a different application, you must change this uri field to point to the Git repository of that application.

7. Click Install to create the JBoss EAP 7 application using the Helm chart.

Procedure

1. In the navigation menu, click Helm.

2. Click eap74 Helm release.

   The Helm Release details page opens. It shows all the information related to the Helm release that you installed.

3. Click the Resources tab. It lists all the resources created by this Helm release.

Procedure

1. In the navigation menu, and click Topology.

   In the Topology view the eap74 deployment displays a code icon in the bottom right-hand corner.

   This icon either represents the Git repository of the associated code, or if the appropriate operators are installed, it will bring up the associated code in your IDE.

2. If the icon shown is CodeReady Workspaces or Eclipse Che, click it to bring up the associated code in your IDE. Otherwise, click it to navigate to the associated Git repository.

Procedure

1. In the navigation menu, click Topology.

2. In the Topology view, click the D eap74 icon.

   A side panel opens with detailed information about the application.

3. In the side panel, click the Resources tab. The Builds section shows all the details related to builds of the application.

Procedure

1. In the navigation menu, and click Topology.

2. In the Topology view, click D eap74.

   A side panel opens with detailed information about the application.

3. In the Details tab, hover over the pod to see the pod status in a tooltip.

   • The number of pods is displayed inside the pod circle.

   • The color of the pod circle indicates the pod status: Light blue = Pending, Blue = Not Ready, Dark blue = Running.

     Note

     In the Topology view, the dark outer circle of the D eap74 deployment icon also indicates the pod status.

1. If a pom.xml file is present in the source code repository, the S2I builder image initiates a Maven build process. The Maven build uses the contents of $MAVEN_ARGS.

   If a pom.xml file is not present in the source code repository, the S2I builder image initiates a binary type build.

   To add custom Maven arguments or options, use $MAVEN_ARGS_APPEND. The $MAVEN_ARGS_APPEND variable appends options to $MAVEN_ARGS.

   By default, the OpenShift profile uses the Maven package goal, which includes system properties for skipping tests (-DskipTests) and enabling the Red Hat GA repository (-Dcom.redhat.xpaas.repo).

   The results of a successful Maven build are copied to the EAP_HOME/standalone/deployments/ directory inside the JBoss EAP for OpenShift image. This includes all JAR, WAR, and EAR files from the source repository specified by the $ARTIFACT_DIR environmental variable. The default value of ARTIFACT_DIR is the Maven target directory.

   Note

   To use Maven behind a proxy on JBoss EAP for OpenShift image, set the $HTTP_PROXY_HOST and $HTTP_PROXY_PORT environment variables. Optionally, you can also set the $HTTP_PROXY_USERNAME, $HTTP_PROXY_PASSWORD, and $HTTP_PROXY_NONPROXYHOSTS variables.

2. All files in the modules source repository directory are copied to the EAP_HOME/modules/ directory in the JBoss EAP for OpenShift image.
3. All files in the configuration source repository directory are copied to the EAP_HOME/standalone/configuration/ directory in the JBoss EAP for OpenShift image. If you want to use a custom JBoss EAP configuration file, name the file standalone-openshift.xml.

Procedure

1. Build a custom layer using the Galleon Maven plugin.

   For more information, see Preparing the Maven project.

2. Deploy the custom layer to an accessible Maven repository.

3. You can use custom Galleon feature-pack environment variables to customize Galleon feature-packs and layers during the S2I image build process.

   For more information about customizing Galleon feature-packs and layers, see Using the custom Galleon feature-pack during S2I build.

4. Optional: Create a custom provisioning file to reference the user-defined layer and supported JBoss EAP layers and store it in your application directory.

   For more information about creating a custom provisioning file, see Custom provisioning files for JBoss EAP.

5. Run the S2I process to provision a JBoss EAP server in OpenShift.

   For more information, see Using the custom Galleon feature-pack during S2I build.

1. Get the name of the pod that has been having trouble.

   You can see pod names, as well as the number times each pod has restarted with the following command.

   $ oc get pods

2. To diagnose why a pod has restarted, you can examine the JBoss EAP logs of the previous pod, or the OpenShift events.

   1. To see the JBoss EAP logs of the previous pod, use the following command.

      oc logs --previous POD_NAME

   2. To see the OpenShift events, use the following command.

      $ oc get events

3. If a pod has restarted because of a resource issue, you can attempt to modify your OpenShift pod configuration to increase its resource requests and limits. See the OpenShift documentation for more information on configuring pod compute resources.

1. First open a remote shell session to the running pod.

   $ oc rsh POD_NAME

2. Run the following command from the remote shell session to launch the JBoss EAP management CLI:

   $ /opt/eap/bin/jboss-cli.sh

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