이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 10. Optional procedures after deploying your environment


Depending on the needs for your environment, you might need to complete certain optional procedures after deploying it.

10.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 Decision Manager authoring environment using templates
  • You set the GIT_HOOKS_DIR parameter in the deployment

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
      Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap

      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
    Copy to Clipboard Toggle word wrap
    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> ...
        Copy to Clipboard Toggle word wrap

        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
        Copy to Clipboard Toggle word wrap
      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
        Copy to Clipboard Toggle word wrap

        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, KIE Server might not start at all. To see if KIE Server has started, check the output of the following command:

    oc get pods
    Copy to Clipboard Toggle word wrap

    If a working KIE Server pod is not present, start it:

    oc rollout latest dc/<myapp>-kieserver
    Copy to Clipboard Toggle word wrap

    Replace <myapp> with the application name that was set when configuring the template.

Components of your Red Hat Decision Manager infrastructure might need to use HTTPS access to servers that have a self-signed HTTPS certificate. For example, Business Central 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 Decision Manager components to communicate with servers that use self-signed HTTPS server certificates.

Prerequisites

  • You deployed a Red Hat Decision Manager environment using templates
  • You have the client certificates that you want to add to the deployment

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
    Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  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'
    Copy to Clipboard Toggle word wrap
    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'
    Copy to Clipboard Toggle word wrap

    Replace myapp with the application name that you set when configuring the template.

10.3. (Optional) Providing the LDAP role mapping file

If you configure the AUTH_ROLE_MAPPER_ROLES_PROPERTIES parameter with a file name, you must provide a file that defines the role mapping. Mount this file on all affected deployment configurations.

Prerequisites

  • You deployed a Red Hat Decision Manager environment using templates
  • You set the AUTH_ROLE_MAPPER_ROLES_PROPERTIES parameter in the deployment

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...
    Copy to Clipboard Toggle word wrap

    For example:

    admins=kie-server,rest-all,admin
    Copy to Clipboard Toggle word wrap
  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>
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

    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 .

10.4. Providing Elytron user configuration or other post-configuration settings

If you do not use LDAP or RH-SSO authentication, Red Hat Decision Manager relies on internal users in the Elytron subsystem of Red Hat JBoss EAP. By default, only the administrative user is created. You might need to add other users to the Elytron security subsystem of Red Hat JBoss EAP. To do so, you must run an Red Hat JBoss EAP post-configuration script.

You can configure this post-configuration script, or any other Red Hat JBoss EAP post-configuration script, in a deployment of Red Hat Decision Manager on Red Hat OpenShift Container Platform.

Procedure

  1. Download sample files from the GitHub repository.
  2. Prepare the following files based on the sample files:

    • postconfigure.sh: The post-configuration shell script that Red Hat JBoss EAP must run. In the example, this script uses the add-users.cli script to add Elytron users. If you want to complete post-configuration tasks outside of the CLI script, modify this script.
    • delayedpostconfigure.sh: An empty file, required in Red Hat Decision Manager version 7.12.0.
    • add-users.cli: The Red Hat JBoss EAP command line interface script for configuring Elytron users or for any other CLI tasks. Add your commands between the following lines:

      embed-server --std-out=echo --server-config=standalone-openshift.xml batch
      
        <your jboss-cli commands>
      
      run-batch quit
      Copy to Clipboard Toggle word wrap
  3. Log in to your Red Hat OpenShift Container Platform cluster with the oc command and change to the namespace of your deployment.
  4. Create a ConfigMap with the files that you prepared by using the following command:

    oc create configmap postconfigure \
        --from-file=add-users.cli=add-users.cli \
        --from-file=delayedpostconfigure.sh=delayedpostconfigure.sh \
        --from-file=postconfigure.sh=postconfigure.sh
    Copy to Clipboard Toggle word wrap
  5. Add mounting of the ConfigMap to the deployment configurations for Business Central and KIE Server by using the following commands:

    oc set volumes dc/myapp-kieserver --add  \
        --configmap-name=postconfigure \
        --mount-path=/opt/eap/extensions \
        --default-mode=0555
    oc set volumes dc/myapp-rhdmcentr --add  \
        --configmap-name=postconfigure \
        --mount-path=/opt/eap/extensions \
        --default-mode=0555
    Copy to Clipboard Toggle word wrap

    Replace myapp with the application name that you configured. If necessary, you can remove the commands for any deployment configurations you don’t need. If you have several KIE Server instances, you can add commands for them.

    The change causes redeployment of the components.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동