-
Language:
English
-
Language:
English
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 the availability of image streams and the image 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. To download the images, OpenShift requires the information about their location (known as image streams). OpenShift also must be configured to authenticate with the Red Hat registry using your service account user name and password.
Some versions of the OpenShift environment include the required image streams. You must check if they are available. If image streams are available in OpenShift by default, you can use them if the OpenShift infrastructure is configured for registry authentication server. The administrator must complete the registry authentication configuration when installing the OpenShift environment.
Otherwise, you must configure registry authentication and install the image streams in the openshift
namespace. You must have administrator access to your OpenShift environment to make these changes.
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, run the following commands:
$ oc get imagestreamtag -n openshift | grep rhpam72-businesscentral $ oc get imagestreamtag -n openshift | grep rhpam72-kieserver
If the outputs of both commands are not empty, the required image streams are available in the
openshift
namespace and no further action is required.If the output of one or both of the commands is empty or if OpenShift was not configured with the user name and password for Red Hat registry access, complete the following steps:
-
Log in to OpenShift with the
oc
command as a user with administrator permissions. - Complete the steps documented in Registry Service Accounts for Shared Environments. You must log on 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 -n openshift oc secrets link default <secret_name> --for=pull -n openshift oc secrets link builder <secret_name> --for=pull -n openshift
Where
<file_name>
is the name of the downloaded file and <secret_name> is the name that is listed in thename:
entry of the file.-
Download the
rhpam-7.2.0-openshift-templates.zip
product deliverable file from the Software Downloads page and extract therhpam72-image-streams.yaml
file. Complete one of the following actions:
Run the following command:
$ oc create -f rhpam72-image-streams.yaml -n openshift
- Using the OpenShift Web UI, select Add to Project → Import YAML / JSON and then choose the file or paste its contents.
-
Log 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. See the Secrets chapter in the OpenShift documentation for more information.
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.See Generate a SSL Encryption Key and Certificate for more information on how to create a keystore with self-signed or purchased SSL certificates.
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.See Generate a SSL Encryption Key and Certificate for more information on how to create a keystore with self-signed or purchased SSL certificates.
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.See Generate a SSL Encryption Key and Certificate for more information on how to create a keystore with self-signed or purchased SSL certificates.
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. Building a custom Process Server image for an external database
If you want to use an external database server for a Process Server and this server is neither MySQL nor PostgreSQL, you must build a custom Process Server image with drivers for this server before deploying your environment.
You can use this build procedure to provide drivers for the following database servers:
- Microsoft SQL Server
- MariaDB
- IBM DB2
- Oracle Database
- Sybase
For the tested versions of the database servers, see Red Hat Process Automation Manager 7 Supported Configurations.
The build procedure creates a custom image that extends the existing Process Server image. It pushes this custom image into a new ImageStream
in the openshift
namespace with the same version tag as the original image.
Prerequisites
-
You have logged on to your project in the OpenShift environment using the
oc
command as a user with thecluster-admin
role. - For IBM DB2, Oracle Database, or Sybase, you have downloaded the JDBC driver from the database server vendor.
Procedure
For IBM DB2, Oracle Database, or Sybase, provide the JDBC driver JAR in a local directory or on an HTTP server. Within the local directory or HTTP server, the following paths are expected:
-
For IBM DB2,
<local_path_or_url>/com/ibm/db2/jcc/db2jcc4/10.5/db2jcc4-10.5.jar
-
For Oracle Database,
<local_path_or_url>/com/oracle/ojdbc7/12.1.0.1/ojdbc7-12.1.0.1.jar
For Sybase,
<local_path_or_url>/com/sysbase/jconn4/16.0_PL05/jconn4-16.0_PL05.jar
Where
<local_path_or_url>
is the path to the local directory or the URL for the HTTP server where the driver is provided.
-
For IBM DB2,
-
To install the source code for the custom build, download the
rhpam-7.2.0-openshift-templates.zip
product deliverable file from the Software Downloads page. Unzip the file and, using the command line, change to thetemplates/contrib/jdbc
directory of the unzipped file. Change to the following subdirectory:
-
For Microsoft SQL Server,
mssql-driver-image
-
For MariaDB,
mariadb-driver-image
-
For IBM DB2,
db2-driver-image
-
For Oracle Database,
oracle-driver-image
-
For Sybase,
sybase-driver-image
-
For Microsoft SQL Server,
Run the following command:
- For Microsoft SQL Server or MariaDB:
../build.sh
- For IBM DB2, Oracle Database, or Sybase:
../build.sh --artifact-repo=<local_path_or_url>
Where
<local_path_or_url>
is the path to the local directory or the URL for the HTTP server where the driver is provided. For example:../build.sh --artifact-repo=/home/builder/drivers ../build.sh --artifact-repo=http://nexus.example.com/nexus/content/groups/public
If you want to configure your OpenShift docker registry address in the process, add also the
--registry=<registry_name.domain_name:port>
parameter to your build command.Examples:
../build.sh --registry=docker-registry.custom-domain:80 ../build.sh --artifact-repo=/home/builder/drivers --registry=docker-registry.custom-domain:80
2.6. 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
Where
class-name
is 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>
Where
class-name
is 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