Chapter 2. Preparing to deploy Red Hat Process Automation Manager in your OpenShift environment
Before deploying Red Hat Process Automation Manager in your OpenShift environment, you need to complete several preparatory tasks. You do not need to repeat these tasks if you want to deploy additional images, for example, for new versions of processes or for other processes.
2.1. Ensuring your environment is authenticated to the Red Hat registry
To deploy Red Hat Process Automation Manager components of Red Hat OpenShift Container Platform, you must ensure that OpenShift can download the correct images from the Red Hat registry. OpenShift must be configured to authenticate with the Red Hat registry using your service account user name and password.
Procedure
- Determine whether Red Hat OpenShift Container Platform was configured with the user name and password for Red Hat registry access. For details about the required configuration, see Configuring a Registry Location. If you are using an OpenShift Online subscription, it is configured for Red Hat registry access.
If Red Hat OpenShift Container Platform was configured with the user name and password for Red Hat registry access, no further action is required. Otherwise, complete the following steps:
-
Ensure you are logged in to OpenShift with the
oc
command and that your project is active. - Complete the steps documented in Registry Service Accounts for Shared Environments. You must log in to Red Hat Customer Portal to access the document and to complete the steps to create a registry service account.
- Select the OpenShift Secret tab and click the link under Download secret to download the YAML secret file.
-
View the downloaded file and note the name that is listed in the
name:
entry. Run the following commands:
oc create -f <file_name>.yaml oc secrets link default <secret_name> --for=pull oc secrets link builder <secret_name> --for=pull
Replace
<file_name>
with the name of the downloaded file and<secret_name>
with the name that is listed in thename:
entry of the file.
-
Ensure you are logged in to OpenShift with the
2.2. Creating the secrets for Process Server
OpenShift uses objects called Secrets
to hold sensitive information, such as passwords or keystores. For more information about OpenShift secrets, see the Secrets chapter in the OpenShift documentation.
Process Server uses an SSL certificate to provide HTTPS access. The deployment can create a sample secret automatically. However, in production environments you must create an SSL certificate for Process Server and provide it to your OpenShift environment as a secret.
Procedure
Generate an SSL keystore with a private and public key for SSL encryption for Process Server. In a production environment, generate a valid signed certificate that matches the expected URL of the Process Server. Save the keystore in a file named
keystore.jks
. Record the name of the certificate and the password of the keystore file.For more information on how to create a keystore with self-signed or purchased SSL certificates, see Generate a SSL Encryption Key and Certificate.
Use the
oc
command to generate a secret namedkieserver-app-secret
from the new keystore file:$ oc create secret generic kieserver-app-secret --from-file=keystore.jks
2.3. Creating the secrets for Business Central
If you are planning to deploy Business Central or Business Central Monitoring in your OpenShift environment, note that this component uses an SSL certificate to provide HTTPS access. The deployment can create a sample secret automatically. However, in production environments you must create an SSL certificate for Business Central and provide it to your OpenShift environment as a secret. Do not use the same certificate and keystore for Business Central and for Process Server.
Procedure
Generate an SSL keystore with a private and public key for SSL encryption for Business Central. In a production environment, generate a valid signed certificate that matches the expected URL of the Business Central. Save the keystore in a file named
keystore.jks
. Record the name of the certificate and the password of the keystore file.For more information on how to create a keystore with self-signed or purchased SSL certificates, see Generate a SSL Encryption Key and Certificate.
Use the
oc
command to generate a secret namedbusinesscentral-app-secret
from the new keystore file:$ oc create secret generic businesscentral-app-secret --from-file=keystore.jks
2.4. Creating the secrets for Smart Router
If you are planning to deploy Smart Router in your OpenShift environment, note that this component uses an SSL certificate to provide HTTPS access. The deployment can create a sample secret automatically. However, in production environments you must create an SSL certificate for Smart Router and provide it to your OpenShift environment as a secret. Do not use the same certificate and keystore for Smart Router as the ones used for Process Server or Business Central.
Procedure
Generate an SSL keystore with a private and public key for SSL encryption for Smart Router. In a production environment, generate a valid signed certificate that matches the expected URL of the Smart Router. Save the keystore in a file named
keystore.jks
. Record the name of the certificate and the password of the keystore file.For more information on how to create a keystore with self-signed or purchased SSL certificates, see Generate a SSL Encryption Key and Certificate.
Use the
oc
command to generate a secret namedsmartrouter-app-secret
from the new keystore file:$ oc create secret generic smartrouter-app-secret --from-file=keystore.jks
2.5. Changing GlusterFS configuration
Check whether your OpenShift environment uses GlusterFS to provide permanent storage volumes. If it uses GlusterFS, to ensure optimal performance, tune your GlusterFS storage by changing the storage class configuration.
Procedure
To check whether your environment uses GlusterFS, run the following command:
oc get storageclass
In the results, check whether the
(default)
marker is on the storage class that listsglusterfs
. For example, in the following output the default storage class isgluster-container
, which does listglusterfs
:NAME PROVISIONER AGE gluster-block gluster.org/glusterblock 8d gluster-container (default) kubernetes.io/glusterfs 8d
If the result has a default storage class that does not list
glusterfs
or if the result is empty, you do not need to make any changes. In this case, skip the rest of this procedure.To save the configuration of the default storage class into a YAML file, run the following command:
oc get storageclass <class-name> -o yaml >storage_config.yaml
Replace
<class-name>
with the name of the default storage class. For example:oc get storageclass gluster-container -o yaml >storage_config.yaml
Edit the
storage_config.yaml
file:Remove the lines with the following keys:
-
creationTimestamp
-
resourceVersion
-
selfLink
-
uid
-
On the line with the
volumeoptions
key, add the following two options:features.cache-invalidation on, performance.nl-cache on
. For example:volumeoptions: client.ssl off, server.ssl off, features.cache-invalidation on, performance.nl-cache on
To remove the existing default storage class, run the following command:
oc delete storageclass <class-name>
Replace
<class-name>
with the name of the default storage class. For example:oc delete storageclass gluster-container
To re-create the storage class using the new configuration, run the following command:
oc create -f storage_config.yaml