Chapter 4. Deployment Considerations for Intelligent Process Server for OpenShift

4.1. Creating the Service Account

Intelligent Process Server for OpenShift requires a service account for deployments. For multiple node deployments, the service account must have the view role enabled so that it can manage the various pods in the cluster. In addition, you will need to configure SSL to enable connections to Intelligent Process Server from outside of the OpenShift instance.

  1. Create the service account: 

    $ echo '{"kind": "ServiceAccount", "apiVersion": "v1", "metadata": {"name": "<service-account-name>"}}' | oc create -f -

    OpenShift 3.2 users can use the following command to create the service account: 

    $ oc create serviceaccount <service-account-name>

  2. Add the view role to the service account: 

    $ oc policy add-role-to-user view system:serviceaccount:<project-name>:<service-account-name>

4.2. Configuring Keystores

Intelligent Process Server for OpenShift requires two keystores:

  • An SSL keystore to provide private and public keys for https traffic encryption
  • A JGroups keystore to provide private and public keys for network traffic encryption between nodes in the cluster

These keystores are expected by Intelligent Process Server for OpenShift, even if the application uses only http on a single-node OpenShift instance. Note that self-signed certificates do not provide secure communication and are intended for internal testing purposes.

Warning

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

See Generate a SSL Encryption Key and Certificate for more information on how to create a keystore with self-signed or purchased SSL certificates.

4.3. Generating the Secret

OpenShift uses objects called Secrets to hold sensitive information, such as passwords or keystores. See the Secrets chapter in the OpenShift documentation for more information.

Intelligent Process Server for OpenShift requires a secret that holds the two keystores described earlier. This provides the necessary authorization to applications in the project.

Use the Java and JGroups keystore files to create a secret for the project: 

$ oc create secret generic <ips-secret-name> --from-file=<jgroups.jceks> --from-file=<keystore.jks>

After the secret has been generated, it can be associated with a service account.

4.4. Creating the Service Account

The service account allows users to associate certain secrets and roles with applications in a project namespace. This provides the application with the necessary authorization to run with all required privileges.

  1. Create a service account to be used for the Intelligent Process Server deployment: 

    $ oc create serviceaccount <service-account-name>

  2. Add the view role to the service account. This enables the service account to view all the resources in the application namespace in OpenShift, which is necessary for managing the cluster. 

    $ oc policy add-role-to-user view system:serviceaccount:<project-name>:<service-account-name>

  3. Add the secret created for the project to the service account: 

    $ oc secret add sa/<service-account-name> secret/<ips-secret-name>

4.5. Configuring the Project Remote Repository

The project must be configured to use a remote repository so that Business Central can push changes and OpenShift can pull the repository to build the application. In the application repository files:

  1. The pom.xml must be configured to use a remote repository so that OpenShift can access it. 

    ...
<distributionManagement>
  <repository>
    <id>deployment</id>
    <name>OpenShift Maven repo</name>
    <url>http://maven.example/deployment/filepath/</url>
  </repository>

  <snapshotRepository>
    <id>deployment</id>
    <name>OpenShift Maven repo</name>
    <url>http://maven.example/snapshots/filepath/</url>
  </snapshotRepository>
</distributionManagement>
...

    For more information, see the Red Hat JBoss BPM Suite Administration and Configuration Guide.

  2. The configuration/settings.xml file must have the remote repository defined so that OpenShift can download the application artifacts. 

    ...
<profiles>
  <profile>
    <id>openshift-mirror-repositories</id>
    <repositories>
      <repository>
        <id>openshift-mirror</id>
        <url>http://maven.example/public/filepath/</url>
      </repository>
    </repositories>

    <pluginRepositories>
      <pluginRepository>
        <id>openshift-mirror</id>
        <url>http://maven.example/public/filepath/</url>
      </pluginRepository>
    </pluginRepositories>
  </profile>
</profiles>
...

    For more information, see the Red Hat JBoss BPM Suite Installation Guide.

  3. The hidden .s2i/environment file defines the KIE container deployment, including which KIE jars to use and the location from which to retrieve them. When OpenShift deploys the built image, the pod name is derived from the deployment alias defined in this file: 

    KIE_CONTAINER_DEPLOYMENT=<alias>=<group_id>:<artifact_id>:<version>

    For example: 

    KIE_CONTAINER_DEPLOYMENT=ApplicationTest=com.example.openshift:example_workflow:1.0