Chapter 12. Optional procedures after deploying your environment
Depending on the needs for your environment, you might need to complete certain optional procedures after deploying it.
12.1. (Optional) Providing the Git hooks directory
If you deploy an authoring enviropnent and configure the GIT_HOOKS_DIR
parameter, you must provide a directory of Git hooks and must mount this directory on the Business Central deployment.
The typical use of Git hooks is interaction with an upstream repository. To enable Git hooks to push commits into an upstream repository, you must also provide a secret key that corresponds to a public key configured on the upstream repository.
Prerequisites
- You deployed a Red Hat Process Automation Manager authoring environment using templates
-
You set the
GIT_HOOKS_DIR
parameter in the deployment
Procedure
If interaction with an upstream repository using SSH authentication is required, complete the following steps to prepare and mount a secret with the necessary files:
-
Prepare the
id_rsa
file with a private key that matches a public key stored in the repository. -
Prepare the
known_hosts
file with the correct name, address, and public key for the repository. Create a secret with the two files using the
oc
command, for example:oc create secret git-hooks-secret --from-file=id_rsa=id_rsa --from-file=known_hosts=known_hosts
Mount the secret in the SSH key path of the Business Central deployment, for example:
oc set volume dc/<myapp>-rhpamcentr --add --type secret --secret-name git-hooks-secret --mount-path=/home/jboss/.ssh --name=ssh-key
Replace
<myapp>
with the application name that you set when configuring the template.
-
Prepare the
Create the Git hooks directory. For instructions, see the Git hooks reference documentation.
For example, a simple Git hooks directory can provide a post-commit hook that pushes the changes upstream. If the project was imported into Business Central from a repository, this repository remains configured as the upstream repository. Create a file named
post-commit
with permission values755
and the following content:git push
NoteA
pre-commit
script is not supported in Business Central. Use apost-commit
script.Supply the Git hooks directory to the Business Central deployment. You can use a configuration map or a persistent volume.
If the Git hooks consist of one or several fixed script files, use a configuration map. Complete the following steps:
- Change into the Git hooks directory that you have created.
Create an OpenShift configuration map from the files in the directory. Run the following command:
oc create configmap git-hooks --from-file=<file_1>=<file_1> --from-file=<file_2>=<file_2> ...
Replace
file_1
,file_2
, and so on with Git hook script file names. Example:oc create configmap git-hooks --from-file=post-commit=post-commit
Mount the configuration map on the Business Central deployment in the path that you have configured:
oc set volume dc/<myapp>-rhpamcentr --add --type configmap --configmap-name git-hooks --mount-path=<git_hooks_dir> --name=git-hooks
Replace
<myapp>
with the application name that was set when configuring the template and<git_hooks_dir>
is the value ofGIT_HOOKS_DIR
that was set when configuring the template.
-
If the Git hooks consist of long files or depend on binaries, such as executable or KJAR files, use a persistence volume. You must create a persistent volume, create a persistent volume claim and associate the volume with the claim, transfer files to the volume, and mount the volume in the
myapp-rhpamcentr
deployment configuration (replace myapp with the application name). For instructions about creating and mounting persistence volumes, see Using persistent volumes. For instructions about copying files onto a persistent volume, see Transferring files in and out of containers.
Wait a few minutes, then review the list and status of pods in your project. Because Business Central does not start until you provide the Git hooks directory, the KIE Server might not start at all. To see if it has started, check the output of the following command:
oc get pods
If a working KIE Server pod is not present, start it:
oc rollout latest dc/<myapp>-kieserver
Replace
<myapp>
with the application name that was set when configuring the template.
12.2. (Optional) Providing a truststore for accessing HTTPS servers with self-signed certificates
Components of your Red Hat Process Automation Manager infrastructure might need to use HTTPS access to servers that have a self-signed HTTPS certificate. For example, Business Central, Business Central Monitoring, and KIE Server might need to interact with an internal Nexus repository that uses a self-signed HTTPS server certificate.
In this case, to ensure that HTTPS connections complete successfully, you must provide client certificates for these services using a truststore.
Skip this procedure if you do not need Red Hat Process Automation Manager components to communicate with servers that use self-signed HTTPS server certificates.
Prerequisites
- You deployed a Red Hat Process Automation Manager environment using templates
- You have the client certificates that you want to add to the deployment
Procedure
Prepare a truststore with the certificates. Use the following command to create a truststore or to add a certificate to an existing truststore. Add all the necessary certificates to one truststore.
keytool -importcert -file certificate-file -alias alias -keyalg algorithm -keysize size -trustcacerts -noprompt -storetype JKS -keypass truststore-password -storepass truststore-password -keystore keystore-file
Replace the following values:
-
certificate-file
: The pathname of the certificate that you want to add to the truststore. -
alias
: The alias for the certificate in the truststore. If you are adding more than one certificate to the truststore, every certificate must have a unique alias. -
algorithm
: The encryption algorithm used for the certificate, typicallyRSA
. -
size
: The size of the certificate key in bytes, for example,2048
. -
truststore-password
: The password for the truststore. keystore-file
: The pathname of the truststore file. If the file does not exist, the command creates a new truststore.The following example command adds a certificate from the
/var/certs/nexus.cer
file to a truststore in the/var/keystores/custom-trustore.jks
file. The truststore password ismykeystorepass
.keytool -importcert -file /var/certs/nexus.cer -alias nexus-cert -keyalg RSA -keysize 2048 -trustcacerts -noprompt -storetype JKS -keypass mykeystorepass -storepass mykeystorepass -keystore /var/keystores/custom-trustore.jks
-
Create a secret with the truststore file using the
oc
command, for example:oc create secret generic truststore-secret --from-file=/var/keystores/custom-trustore.jks
In the deployment for the necessary components of your infrastructure, mount the secret and then set the
JAVA_OPTS_APPEND
option to enable the Java application infrastructure to use the trast store, for example:oc set volume dc/myapp-rhpamcentr --add --overwrite --name=custom-trustore-volume --mount-path /etc/custom-secret-volume --secret-name=custom-secret oc set env dc/myapp-rhpamcentr JAVA_OPTS_APPEND='-Djavax.net.ssl.trustStore=/etc/custom-secret-volume/custom-trustore.jks -Djavax.net.ssl.trustStoreType=jks -Djavax.net.ssl.trustStorePassword=mykeystorepass'
oc set volume dc/myapp-kieserver --add --overwrite --name=custom-trustore-volume --mount-path /etc/custom-secret-volume --secret-name=custom-secret oc set env dc/myapp-kieserver JAVA_OPTS_APPEND='-Djavax.net.ssl.trustStore=/etc/custom-secret-volume/custom-trustore.jks -Djavax.net.ssl.trustStoreType=jks -Djavax.net.ssl.trustStorePassword=mykeystorepass'
Replace
myapp
with the application name that you set when configuring the template.
12.3. (Optional) Providing the LDAP role mapping file
If you configure the AUTH_ROLE_MAPPER_ROLES_PROPERTIES
parameter, you must provide a file that defines the role mapping. Mount this file on all affected deployment configurations.
Prerequisites
- You deployed a Red Hat Process Automation Manager environment using templates
-
You set the
AUTH_ROLE_MAPPER_ROLES_PROPERTIES
parameter in the deployment
Procedure
Create the role mapping properties file, for example,
my-role-map
. The file must contain entries in the following format:ldap_role = product_role1, product_role2...
For example:
admins = kie-server,rest-all,admin
Create an OpenShift configuration map from the file by entering the following command:
oc create configmap ldap-role-mapping --from-file=<new_name>=<existing_name>
Replace
<new_name>
with the name that the file is to have on the pods (it must be the same as the name specified in theAUTH_ROLE_MAPPER_ROLES_PROPERTIES
file) and<existing_name>
with the name of the file that you created. Example:oc create configmap ldap-role-mapping --from-file=rolemapping.properties=my-role-map
Mount the configuration map on every deployment configuration that is configured for role mapping.
The following deployment configurations can be affected in this environment:
Replace
myapp
with the application name. Sometimes, several KIE Server deployments can be present under different application names.For every deployment configuration, run the command:
oc set volume dc/<deployment_config_name> --add --type configmap --configmap-name ldap-role-mapping --mount-path=<mapping_dir> --name=ldap-role-mapping
Replace
<mapping_dir>
with the directory name (without file name) set in theAUTH_ROLE_MAPPER_ROLES_PROPERTIES
parameter, for example,/opt/eap/standalone/configuration/rolemapping
.