Chapter 10. Optional procedures after deploying your environment

Procedure

1. 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:

   1. Prepare the id_rsa file with a private key that matches a public key stored in the repository.
   2. Prepare the known_hosts file with the correct name, address, and public key for the repository.

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

   4. Mount the secret in the SSH key path of the Business Central deployment, for example:

      oc set volume dc/<myapp>-rhdmcentr --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.

2. 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 values 755 and the following content:

   git push

   Note

   A pre-commit script is not supported in Business Central. Use a post-commit script.

3. Supply the Git hooks directory to the Business Central deployment. You can use a configuration map or a persistent volume.

   1. If the Git hooks consist of one or several fixed script files, use a configuration map. Complete the following steps:

      1. Change into the Git hooks directory that you have created.

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

      3. Mount the configuration map on the Business Central deployment in the path that you have configured:

         oc set volume dc/<myapp>-rhdmcentr --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 of GIT_HOOKS_DIR that was set when configuring the template.

   2. 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-rhdmcentr 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.

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

Procedure

1. 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, typically RSA.
   • 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 is mykeystorepass.

     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

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

3. 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-rhdmcentr --add --overwrite --name=custom-trustore-volume --mount-path /etc/custom-secret-volume --secret-name=custom-secret
   
   oc set env dc/myapp-rhdmcentr 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.

Procedure

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

2. 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 the AUTH_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

3. 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 the AUTH_ROLE_MAPPER_ROLES_PROPERTIES parameter, for example, /opt/eap/standalone/configuration/rolemapping .