Author: Leela Chitta & Dhanesh M

             IBM Documentation Reference - 

Introduction

IBM Business Automation Insights (BAI) is a powerful analytics component within the IBM Cloud Pak for Business Automation ecosystem that enables real-time monitoring, visualization, and operational intelligence. In its standalone deployment mode, BAI runs independently from the other Cloud Pak components and can be integrated with external applications or deployed in air-gapped or restricted environments. This makes it particularly suitable for organizations that need to isolate BAI from the full Cloud Pak stack or wish to use it purely for analytics and monitoring purposes.

BAI Standalone now supports deployment on platforms aligned with the Cloud Native Computing Foundation (CNCF), such as Rancher. The CNCF is an open-source software foundation that promotes cloud-native technologies such as Kubernetes and container-based architectures.

In this blog, we’ll walk through Airgap deployment steps of IBM BAI on a CNCF-compliant platform, using Rancher as orchestration platform. By the end of this blog, you’ll have a working standalone BAI setup running on a Rancher-managed Kubernetes cluster, along with on how to mirror required images into your local docker registry and deploy using these mirrored images onto your Rancher cluster.

Prerequisites for the Deployment

Before proceeding with the Airgap deployment of IBM Business Automation Insights (BAI) on a Rancher-managed CNCF platform, ensure the following prerequisites are met:

• Rancher and RKE2 Cluster Setup
  A Kubernetes cluster must be provisioned using RKE2, with Rancher installed and configured to manage the cluster.
• Bastion host with an internet access
• Private registry to mirror images
• KUBECTL Installed on Load Balancer Node
  Ensure the load balancer node has the kubectl CLI installed and properly configured to interact with the cluster.

• ·       Install OLM version v0.27.0
• curl -L "https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.27.0/install.sh" -o install.sh
• chmod +x install.sh
• ./install.sh v0.27.0
• IBM Entitlement Registry Key
  Acquire a valid IBM Entitlement Registry Key, which is required to pull container images from IBM's container registry.
• Storage Requirements
  The cluster must have a supported Container Storage Interface (CSI) solution available. Compatible options include IBM Storage Fusion, AWS EFS, Azure Files, Portworx and other CNCF-compatible CSI drivers. Storage must meet the following access mode and binding requirements:

• Block storage (ReadWriteOnce): must support VolumeBindingMode = WaitForFirstConsumer
• File storage (ReadWriteMany): must support VolumeBindingMode = Immediate  

• NGINX Ingress Controller
  The NGINX ingress controller must be installed in the cluster. Ensure that enable-ssl-passthrough is set to true – this is critical for secure Kafka communication.
  In Rancher, this is typically done by creating or updating the HelmChartConfig object for the ingress controller to include the enable-ssl-passthrough annotation.

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-ingress-nginx
  namespace: kube-system
spec:
  valuesContent: |-
    controller:
      config:
        enable-underscores-in-headers: "true"
        use-forwarded-headers: true
      extraArgs:
        enable-ssl-passthrough: true

• System Configuration for OpenSearch
  Since OpenSearch is a component of BAI, configure all cluster nodes to support its memory requirements. This is essential for the OpenSearch pods to reach the Running state.

To apply the required setting, SSH into each worker node of your Rancher-managed cluster and run the following command:

ssh root@<worker-node>
sysctl -w vm.max_map_count=262144

Repeat this process for each worker node in the cluster. For reference and additional context, see the official OpenSearch documentation: https://docs.opensearch.org/docs/latest/install-and-configure/install-opensearch/index/#important-settings

·       There is a native way of doing this in Rancher which we have found this.

o   https://gist.github.com/brooksphilip/c9ed00c8db921b5e0a2a1c8c8903dfdb

• Deployment Approach
  For this blog, we will be using supported and recommended way of deployment which is using script-based deployment. 

Setting up the bastion host:

·      Install OCP CLI tool 4.14.xx or later from https://www.ibm.com/links?url=https%3A%2F%2Fmirror.openshift.com%2Fpub%2Fopenshift-v4%2Fclients%2Focp%2F

·      Install podman on the RHEL machine using https://www.ibm.com/links?url=https%3A%2F%2Fpodman.io%2Fgetting-started%2Finstallation.html

·      Download and install the most recent version of IBM Catalog Management Plug-in.

o   Download IBM Catalog Management plug-in from https://www.ibm.com/links?url=https%3A%2F%2Fgithub.com%2FIBM%2Fibm-pak%2Freleases

o   Extract the binary file with below command.

§  tar -xf oc-ibm_pak-linux-amd64.tar.gz

o   Run the following commands to move the file to /usr/local/bin

§  mv oc-ibm_pak-linux-amd64 /usr/local/bin/oc-ibm_pak

§  chmod 755 /usr/local/bin/oc-ibm_pak

o   Confirm by executing the following command.

§  oc ibm-pak –help

·      Download and install oc mirror with version 4.14.xx to mirror images using oc mirror

o   Download oc mirror tool from here https://www.ibm.com/links?url=https%3A%2F%2Fmirror.openshift.com%2Fpub%2Fopenshift-v4%2Fx86_64%2Fclients%2Focp%2F4.14.17%2F

o   Extract the binary

§  tar -xf oc-mirror.tar.gz

o   Run the following commands to move the file to /usr/local/bin

§  mv oc-mirror /usr/local/bin/oc-mirror

§  chmod 755 /usr/local/bin/oc-mirror

·      Make sure the following network ports are available on the host.

o   *.icr.io:443 for IBM Entitlement Registry

o   github.com for CASE and tools.

Setting up the private registry:

A private image registry must be used to store all images in your local environment. Create a registry and make sure that it meets the requirements. It must be available and accessible from the Kubernetes cluster nodes.

Make sure that the registry meets below requirements.

·      Supports Docker Manifest V2, Schema 2

·      Supports multi-architecture images.

·      Is accessible from both the host and your Rancher cluster.

·      User/password who can read images from and write images to.

Configure the private registry something like below:

mirrors:

  "icr.io":

    endpoint:

      - "https://my-private-registry.com"

    rewrite:

      "^(.+)": "bai2500/${1}"

  "cp.icr.io":

    endpoint:

      - "https://my-private-registry.com"

    rewrite:

      "^(.+)": "bai2500/${1}"

configs:

  "my-private-registry.com":

    auth:

      username: "<username>"

      password: "<password>"

    tls:

      cert_file:            # path to the cert file used to authenticate to the registry

      key_file:             # path to the key file for the certificate used to authenticate to the registry

      ca_file:              # path to the ca file used to verify the registry's certificate

      insecure_skip_verify: # may be set to true to skip verifying the registry's certificate

For specific instructions on how to configure private registries, see https://docs.rke2.io/install/private_registry#registries-configuration-file

Note: bai2500 is the namespace name created in your local private registry.

Important: If you are going to use a user that does not have permission to create namespaces in the local private registry, then you need to perform these steps with your administrator before you start the mirroring process.

·      Create a namespace in your local private registry to mirror product specific images such as “bai2500” for this version. For example: my-private-registry.com/bai2500

Note: Use specific namespace for each version so that you can remove the unused namespace later. For example: my-private-registry.com/bai2501 for 25.0.0-IF001

·      Create a sub-folder called cpopen under created namespace in Step 1 in local private registry to mirror images from IBM Entitlement Registry icr.io/cpopen.

The cpopen namespace is for publicly available images that are hosted by IBM.

Downloading the CASE files and cert-kubernetes-bai:

Before mirroring the images, you must connect to the internet so that you can download the corresponding CASE files.

·      Connect your host to the internet and disconnect it from local air-gapped network.

·      Download IBM Business Automation Insights container images to your host.

·      Using IBM Catalog Management Plug-in (ibm-pak) v1.13.0 or later, you can download CASE files. You can view the current configuration of the plug-in by running the following command.

                                               i.     oc ibm-pak config

·      Run the following command to configure a repository that downloads the CASE files from cp.icr.io registry.

                                               i.     oc ibm-pak config repo 'IBM Cloud-Pak OCI registry' -r oci:cp.icr.io/cpopen –enable

·      List all the available CASE files to download by running following command.

                                               i.     oc ibm-pak list

·      Download the bai-case-to-be-mirrored-25.0.0.txt file, or an interim Fix, from github repository.

                                               i.     git clone -b 25.0.0 https://github.com/icp4a/cert-kubernetes-bai.git

                                             ii.     cd cert-kubernetes-bai/scripts/airgap

·      Run the following command to set the environment variable. $IBMPAK_HOME

                                               i.     mkdir /root/bai2500

                                             ii.     export IBMPAK_HOME=/root/bai2500

·      Download CASE files by running below command.

                                               i.     oc ibm-pak get -c file://<absolute path to file>/cert-kubernetes-bai/scripts/airgap/bai-case-to-be-mirrored_25.0.0.txt

The <absolute path to file> needs to be a path starting from "/". For example, "/opt".

By default, the root directory that is used by the ibm-pak plug-in is $IBMPAK_HOME/.ibm-pak. Therefore, by default, the IBM Business Automation Insights CASE is downloaded to $IBMPAK_HOME/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION.

Mirroring catalogs to a private registry using oc mirror:

You need to mirror the catalogs from a public registry to a private registry to install Business Automation Insights for an airgap deployment.

After an upgrade, you can remove images from the previous version from the target registry by creating a new path or folder to copy the images to instead of the default path. For example, the following command mirrors the image to a specific folder (locationX) in the private registry instead of the default path:

oc ibm-pak generate mirror-manifests $CASE_NAME $TARGET_REGISTRY/locationX \ --version $CASE_VERSION

1.    Set the environment variables and authenticate registries.

a.    Set the environment variable $TARGET_REGISTRY by running the following command.

                                               i.     export TARGET_REGISTRY=<local-private-registry>

The <local-private-registry> refers to the registry (fully qualified hostname and port) where the images are mirrored to and accessed by the cluster. For example: localhost.localdomain:5000 or 172.16.0.10:5000

b.    Set the following environment variables with the CASE name and version.

                                               i.     export CASE_NAME=ibm-ba-insights

                                             ii.     export CASE_VERSION=25.0.0

c.     Run the following command to set preferred tool parameter as oc-mirror

                                               i.     oc ibm-pak config mirror-tools --enabled oc-mirror

d.    Authenticate the registry called : cp.icr.io

If you plan to run Podman as the non-root user, see https://www.ibm.com/links?url=https%3A%2F%2Fgithub.com%2Fcontainers%2Fpodman%2Fblob%2Fmain%2Fdocs%2Ftutorials%2Frootless_tutorial.md

Set the environment variable XDG_RUNTIME_DIR by running the following commands:

export XDG_RUNTIME_DIR=/run/user/${UID}

export REGISTRY_AUTH_FILE=$XDG_RUNTIME_DIR/containers/auth.json

where ${UID} is the user id of the current user. Make sure that the directory /run/user/${UID} exists and the current user must have write permission.

Note: Run the following command as the non-root user if you do not want to use sudo podman:

mkdir -p /run/user/<ID of non-root>  && chown <non-root-user>:<non-root-group> /run/user/<ID of non-root>

If you are using Podman, run the following command to configure credentials for all target registries that require authentication. You must run the command separately for each registry.

export REGISTRY_AUTH_FILE=<path to the file that has the auth credentials generated on podman login>

podman login cp.icr.io

podman login <TARGET_REGISTRY>

If you are using docker, run the following command to configure credentials for all target registries that require authentication. You must run the command separately for each registry.

export REGISTRY_AUTH_FILE=<path to the file that has the auth credentials generated on docker login>

docker login cp.icr.io

docker login <TARGET_REGISTRY>

Important: When you log in to cp.icr.io, you must specify the user as cp and the IBM entitlement key as the password.

For example:

podman login cp.icr.io

Username: cp

Password: xxxxxxxxxxxxxxxxxxxxx

Login Succeeded!

The password can be copied from the https://myibm.ibm.com/products-services/containerlibrary .You can add --tls-verify=false to the command, if you see "cert error" messages.

If you export REGISTRY_AUTH_FILE=~/.ibm-pak/auth.json, and then run the podman login command, you can see that the file is populated with registry credentials.

If you use docker login, the authentication file is typically located in $HOME/.docker/config.json on Linux or %USERPROFILE%/.docker/config.json on Windows. After you run the docker login command, you can export REGISTRY_AUTH_FILE to point to that location. For example, on Linux you can run the following command:

export REGISTRY_AUTH_FILE=$HOME/.docker/config.json

2.    Run the following command to generate mirror manifests to be used when mirroring the catalog to the target registry. The $TARGET_REGISTRY refers to the registry where the catalogs are mirrored to and accessed by the cluster.

oc ibm-pak generate mirror-manifests $CASE_NAME $TARGET_REGISTRY --version $CASE_VERSION

Important: The generate mirror-manifests command provides an output that lists the command for mirroring. Save the command for later use in step 3.

The following example shows sample output.

-----

oc ibm-pak generate mirror-manifests ibm-ba-insights --version 25.0.0 $TARGET_REGISTRY/bai-2500

ibm-bts-bundle done

ibm-licensing done

ibm-zen  done

ibm-cs-iam done

ibm-cs-install done

ibm-elasticsearch-operator done

ibm-events-operator done

ibm-ba-insights done

ibm-cert-manager done

ibm-cs-flink done

ibm-cloud-native-postgresql done

Generating mirror manifests of CASE: ibm-ba-insights, version: 25.0.0 is complete

Next steps

- To mirror the non curated catalog:

oc mirror --config /root/.ibm-pak/data/mirror/ibm-ba-insights/25.0.0/image-set-config.yaml docker://local_registry/bai2500 --dest-skip-tls --max-per-registry=6

Note: oc mirror arguments are recommendations and may not be valid on all versions of the oc-mirror plug-in.

-----

A new directory $IBMPAK_HOME/.ibm-pak/mirror is created when you issue the oc ibm-pak generate mirror-manifests command. The mirror directory stores the catalog-sources.yaml, image-content-source-policy.yaml, and image-set-config.yaml files.

Tip: If you are using a Red Hat® Quay.io registry and need to mirror the images to a specific organization in the registry, you can set the target to that organization. Specify the organization name in the generate mirror-manifests command:

export ORGANIZATION=<your-organization>

oc ibm-pak generate mirror-manifests $CASE_NAME $TARGET_REGISTRY/$ORGANIZATION --version $CASE_VERSION

Restriction: Currently, you cannot select the images to mirror by their target architecture because image registries do not support sparse manifests (manifests that reference image digests outside of the package).

3.    Run the command generated in Step 2 to mirror the catalogs.

The command does not produce any console logs for about 6 - 8 minutes as it prepares the list from the CASE package. If you want, you can add verbose (-v) to the command with possible values of 1 to 9.

Based on the number and size of the images to mirror, the oc mirror command can take a considerable amount of time. If you are running the command on a remote system, run the command in the background with the nohup POSIX command so that it does not stop if the user logs out. The following command starts the mirroring process in the background and writes the log to a bai-2500.txt file.

nohup oc mirror --config /root/.ibm-pak/data/mirror/ibm-ba-insights/25.0.0/image-set-config.yaml docker://$TARGET_REGISTRY/bai2500 --dest-skip-tls --max-per-registry=6 > /opt/bai-2500.txt 2>&1 &

The following example shows sample output.

-----

nohup: ignoring input

Logging to .oc-mirror.log

Checking push permissions for target_registry

Creating directory: oc-mirror-workspace/src/publish

Creating directory: oc-mirror-workspace/src/v2

Creating directory: oc-mirror-workspace/src/charts

Creating directory: oc-mirror-workspace/src/release-signatures

No metadata detected, creating new workspace

22 related images processed in 935.023807ms

Writing image mapping to oc-mirror-workspace/operators.1718146125/manifests-ibm-bai-catalog/mapping.txt

wrote mirroring manifests to oc-mirror-workspace/operators.1718146125/manifests-ibm-bts-operator-catalog

--

--

--

info: Mirroring completed in 8m1.74s (0B/s)

Rendering catalog image "target_registry/bai2500.gm/root/ibm-bai-catalog:84a2dd" with file-based catalog

Rendering catalog image "target_registry/bai2500.gm/cpopen/ibm-cert-manager-operator-catalog:41084f" with file-based catalog

Rendering catalog image "target_registry/bai2500.gm/cpopen/ibm-cs-install-catalog:687382" with file-based catalog

Rendering catalog image "target_registry/bai2500.gm/cpopen/ibm-events-operator-catalog:4cd92e" with file-based catalog

Rendering catalog image "target_registry/bai2500.gm/cpopen/ibm-iam-operator-catalog:022616" with file-based catalog

Rendering catalog image "target_registry/bai2500.gm/cpopen/ibm-licensing-catalog:7435ce" with file-based catalog

Rendering catalog image "target_registry/bai2500.gm/cpopen/ibm-opencontent-flink-operator-catalog:880fdd" with file-based catalog

Rendering catalog image "target_registry/bai2500.gm/cpopen/opencontent-elasticsearch-operator-catalog:755b51" with file-based catalog

Rendering catalog image "target_registry/bai2500.gm/cpopen/ibm-bts-operator-catalog:866f02" with file-based catalog

Rendering catalog image "target_registry/bai2500.gm/cpopen/ibm-cpd-cloud-native-postgresql-operator-catalog:0b46a3" with file-based catalog

Rendering catalog image "target_registry/bai2500.gm/cpopen/ibm-zen-operator-catalog:690874" with file-based catalog

Writing image mapping to oc-mirror-workspace/results-1718146867/mapping.txt

Writing CatalogSource manifests to oc-mirror-workspace/results-1718146867

Writing ICSP manifests to oc-mirror-workspace/results-1718146867

-----

4.    For Rancher, configure the private registry. For example:

mirrors:

  "icr.io":

    endpoint:

      - "https://my-private-registry.com"

    rewrite:

      "^(.+)": "bai2500/${1}"

  "cp.icr.io":

    endpoint:

      - "https://my-private-registry.com"

    rewrite:

      "^(.+)": "bai2500/${1}"

configs:

  "my-private-registry.com":

    auth:

      username: "<username>"

      password: "<password>"

    tls:

      cert_file:            # path to the cert file used to authenticate to the registry

      key_file:             # path to the key file for the certificate used to authenticate to the registry

      ca_file:              # path to the ca file used to verify the registry's certificate

      insecure_skip_verify: # may be set to true to skip verifying the registry's certificate

Note: bai2500 is the namespace name created in your local private registry.

Installing operators using scripts:

To begin the deployment of IBM Business Automation Insights (BAI), a cluster administrator must first run the bai-clusteradmin-setup.sh script. This script prepares the cluster by:

• Creating or identifying the BAI namespace
• Applying necessary Custom Resource Definitions (CRDs)
• Setting up RBAC bindings for the specified user
• Deploying a namespace-scoped instance of IBM foundational services

The script can also be run in silent mode by exporting required environment variables in advance.
After the script completes, the administrator must share the output values with the non-admin user who will perform the actual BAI deployment.

Procedure

1. Open the terminal on your load balancer node and clone the BAI deployment scripts from GitHub.
   This blog demonstrates a fresh production deployment for version 25.0.0. 

git clone -b 25.0.0 https://github.com/icp4a/cert-kubernetes-bai.git --single-branch

2. Navigate to the Scripts Directory. 

cd ${PATH_TO_EXTRACTED_FILES}/cert-kubernetes-bai/scripts

3. Start the setup by running the following script:

./bai-clusteradmin-setup.sh

a. Would you like to set up the cluster for an online based IBM Business Automation Insights deployment or for an airgap/offline based IBM Business Automation Insights deployment:

1) Online

2) Offline/Airgap

Enter a valid option [1 to 2]:

Select: 2 (Offline)

b. Select the cloud platform to deploy:

1) RedHat OpenShift Kubernetes Service (ROKS) - Public Cloud

2) Openshift Container Platform (OCP) - Private Cloud

3) Other - Cloud Native Computing Foundation ( CNCF )

Enter a valid option [1 to 3]:

Select: 3 (Other – Cloud Native Computing Foundation ( CNCF ))

c. Where would you like to deploy IBM Business Automation Insights?

Enter the name for a new project or an existing project (namespace):
Example Input: bai2500 

d. Provide the domain name for your cluster (This is the ingress that must be created and provided as a prerequisite for the deployment):

Enter the FQDN of your Rancher CNCF cluster.

Wait for the script to execute completely before proceeding to the next step.

4. After the script completes, ensure that all required operators have been installed successfully in the specified namespace. Use the following command: 

kubectl get csv -n <namespace>

Example Output:

[root@ranchernew1 scripts]# kubectl get csv -n bai2500
NAME                                          DISPLAY                                VERSION   REPLACES   PHASE
ibm-bai-foundation-operator.v25.0.0           IBM BAI Foundation                     25.0.0               Succeeded
ibm-bai-insights-engine-operator.v25.0.0      IBM Business Automation Insights       25.0.0               Succeeded
ibm-cert-manager-operator.v4.2.13             IBM Cert Manager                       4.2.13               Succeeded
ibm-common-service-operator.v4.12.0           IBM Cloud Pak foundational services    4.12.0               Succeeded
operand-deployment-lifecycle-manager.v4.5.0   Operand Deployment Lifecycle Manager   4.5.0                Succeeded

All operators should show PHASE = Succeeded.

Preparing LDAP Secrets and Generating Property Files using the bai-prerequisites.sh script

The bai-prerequisites.sh script helps prepare your environment for BAI deployment by generating the required property files and secrets for LDAP integration.

Instead of manually creating LDAP secrets, this script simplifies the process by producing the necessary YAML templates.

The script supports three modes:

• property – Generates the required property files:
  bai_user_profile.property and bai_LDAP.property.
  Review and update these files with your LDAP server details and attributes.
• generate – Uses the updated property files to generate the YAML templates for secrets.
• validate – Verifies that the generated secrets are properly configured and ready for use.

Procedure

1. Open the terminal on your load balancer node and navigate to the scripts directory. 
    

cd ${PATH_TO_EXTRACTED_FILES}/cert-kubernetes-bai/scripts

2. Run the bai-prerequisites.sh script in property mode. 
    

./bai-prerequisites.sh -m property -n < namespace >

a. Do you accept the IBM Business Automation Insights standalone license (Yes/No, default: No):

Enter: Yes 

b. Select the cloud platform to deploy: 
1) RedHat OpenShift Kubernetes Service (ROKS) - Public Cloud
2) Openshift Container Platform (OCP) - Private Cloud

3) Other - Cloud Native Computing Foundation ( CNCF )
Enter a valid option [1 to 3]:

Select: 3 (Other – Cloud Native Computing Foundation ( CNCF ))

c. Do you want to configure an LDAP for this IBM Business Automation Insights stand-alone deployment? (Yes/No, default: Yes): 

Enter:Yes (or No if LDAP is not required)

d. Please enter one LDAP user for BAI stand-alone: 

Enter: <ldap_user>

e. What is the LDAP type that will be used for this deployment? 
1) Microsoft Active Directory
2) IBM Tivoli Directory Server / Security Directory Server
Enter a valid option [1 to 2]: 

Enter:1 (Active Directory) or 2 (IBM Directory Server)

f. To provision the persistent volumes and volume claims
Please enter the file storage classname for medium storage(RWX):

Enter the storage class configured in the cluster for medium storage.

g. Please enter the file storage classname for fast storage(RWX):

Enter the storage class configured in the cluster for fast storage.

h. Please enter the block storage classname for Zen(RWO):

Enter the storage class configured in the cluster for Zen.

i. Please select the deployment profile (default: small).  Refer to the documentation in BAI stand-alone Knowledge Center for details on profile.
1) small
2) medium
3) large
Enter a valid option [1 to 3]: 

Enter: 1 (small)

j. Do you want to use the default IAM admin user: [cpadmin] (Yes/No, default: Yes): 

Enter: Yes 

k. Do you want to generate the network policy templates for this BAI stand-alone deployment? (Notes: Starting from 25.0.0, the BAI stand-alone operators no longer install network policies automatically. If you want the operators to generate network policies from a set of templates, select Yes. You can install the network policies by running a script after the BAI Deployment is installed. If you select No, then no network policies will be generated.) (Yes/No, default: No):

Enter: No

l. Do you want to use an external Postgres **** If you select "Yes", IM service uses an external Postgres DB as IM metastore DB. If you select "No", IM service uses an embedded cloud native postgresql DB as IM metastore DB.) (Yes/No, default: No):

Enter: No

m. Do you want to use an external Postgres DB*** If you select "Yes", Zen service uses an external Postgres DB as Zen metastore DB.. If you select "No", Zen service uses an embedded cloud native postgresql DB as Zen metastore DB ) (Yes/No, default: No):

Enter: No

n. Do you want to use an external Postgres DB*** If select "Yes", BTS service uses an external Postgres DB as BTS metastore DB. If select "No", BTS service uses an embedded cloud native postgresql DB as BTS metastore DB ) (Yes/No, default: No): 

Enter: No

o. For which components do you want to enable the Flink job for: 
1) BAW 
2) BAW Advanced events 
3) ICM 
4) ODM 
5) Content 
6) ADS 
7) Navigator 
Tips:Press [ENTER] to accept the default (None of the components are selected)
Enter a valid option [1 to 7]:

Select all (1–7) as needed. Press Enter when done.

p. Once completed, the script will generate:

• bai_user_profile.property
• bai_LDAP.property

3. Navigate to the property file folder 

cd ${PATH_TO_EXTRACTED_FILES}/cert-kubernetes-bai/scripts/bai-prerequisites/project/<namespace>/propertyfile

4. Edit the bai_LDAP.property file:
• Replace all <Required> placeholders with actual LDAP server details.
5. Edit the bai_user_profile.property file:
• Replace all <Required> placeholders with actual values with details specific to your environment.
6. If LDAP_SSL_ENABLED="True", place your LDAP certificate file (ldap-cert.crt) under the following 

cd ${PATH_TO_EXTRACTED_FILES}/cert-kubernetes-bai/scripts/bai-prerequisites/project/<namespace>/propertyfile/cert/ldap

7. Run the bai-prerequisites.sh script in generate mode. 
    

./bai-prerequisites.sh -m generate -n < namespace >

a. This generates the create_secret.sh script in the path: 

cert-kubernetes-bai/scripts/bai-prerequisites/project/<namespace>/create_secret.sh

b. Set the current namespace context: 

kubectl config set-context --current --namespace=<namespace>

c. Navigate to the project-specific directory: 

cd cert-kubernetes-bai/scripts/bai-prerequisites/project/<namespace>

d. Run the create_secret.sh script to create the secrets in your cluster: 

./create_secret.sh

After this step, your LDAP secrets will be available in the specified namespace and ready for the BAI deployment process.

8. Navigate to the scripts directory. 
    

cd ${PATH_TO_EXTRACTED_FILES}/cert-kubernetes-bai/scripts

9. Run the bai-prerequisites.sh script in validate mode. 
    

./bai-prerequisites.sh -m validate -n < namespace >

This command performs several checks:

• Verifies that the storage classes provided earlier meet the required access modes:
• RWX for file storage classes
• RWO for block storage classes
  If valid, the result is marked PASSED.
• Ensures the required secrets are created and accessible.
• Submits a validation query to the LDAP server to verify connectivity.
• (If configured) Checks the connection to an external PostgreSQL DB used for the Zen metastore.

Note:
This validation step does not modify any data. it only tests the connections and reports the results.

If any validation step fails, review and correct the corresponding entries in the property files and re-run the validate mode.

Once everything passes, you're ready to move on with the BAI deployment!

Generate the BAI Standalone Custom Resource file for deployment:

The bai-deployment.sh script is used to generate the Custom Resource (CR) file required for deploying IBM Business Automation Insights (BAI) Standalone.

This CR file acts as the primary input for the BAI Operator to install and configure the BAI components based on the selected settings.

 

Procedure

1. Navigate to the scripts directory. 
    

cd ${PATH_TO_EXTRACTED_FILES}/cert-kubernetes-bai/scripts

2. Set the current namespace context: 

kubectl config set-context --current --namespace=<namespace>

3. Run the bai-deployment.sh script. 
    

./bai-deployment.sh -n <namespace>

a.      Do you accept the IBM Business Automation Insights standalone license (Yes/No, default: No):

Enter: Yes 

b. Do you want to generate the network policy templates for this BAI stand-alone deployment? (Notes: Starting from 25.0.0, the BAI stand-alone operators no longer install network policies automatically. If you want the operators to generate network policies from a set of templates, select Yes. You can install the network policies by running a script after the BAI Deployment is installed. If you select No, then

no network policies will be generated.) (Yes/No, default: No):

Enter: Yes 

c. A summary of your selection is displayed. Verify the information is correct and Enter: Yes .

A custom resource file is generated.

${PATH_TO_EXTRACTED_FILES}/cert-kubernetes-bai/scripts/ibm_bai_cr_final.yaml

Apply the BAI Custom Resource

Once the BAI Standalone Custom Resource (CR) has been generated, the next step is to apply it so that the BAI Operator can begin the deployment process.

Procedure

1. Set the current namespace context: 

kubectl config set-context --current --namespace=<namespace>

2. To install the deployment, apply the CR using: 

kubectl apply -f ${PATH_TO_EXTRACTED_FILES}/cert-kubernetes-bai/scripts/generated-cr/project/<namespace>/ibm_bai_cr_final.yaml

kubectl apply -f /opt/bai2500/cert-kubernetes-bai/scripts/generated-cr/project/bai2500/ibm_bai_cr_final.yaml

3. Monitor the Operator Logs. Watch the BAI Insights Engine Operator logs to ensure the deployment is progressing correctly.
   
   You can also track the status of the deployed components using 

kubectl get InsightsEngine -o json | grep -A100 "status"

This will show the current state of each component in the deployment. 

The deployment is successfully completed when the field insightsEngineStatus in the applied CR shows: 

insightsEngineStatus: Ready

Create Ingress Resources

After the BAI deployment is completed, you must create ingress endpoints to access BAI services.


Procedure

1. Navigate to the scripts directory. 
    

cd ${PATH_TO_EXTRACTED_FILES}/cert-kubernetes-bai/scripts

2. Set the current namespace context: 

kubectl config set-context --current --namespace=<namespace>

3. Run the following command: 

./bai-deployment.sh --ingress -n <namespace>

[WARNING]: Before proceeding with the ingress generation, make sure the BAI Standalone components have been installed by looking at the status section of the InsightsEngine Custom Resource file and monitoring the Insights Engine Operator logs 
Confirm if you want to proceed with generating ingress templates required for a BAI

a.      Standalone deployment (Yes/No, default: No): 

Enter: Yes

4.     Get the list of created ingresses:

kubectl get ingress

Verification and access deployed resources

1.     Access the URL’s for generated ingresses

kubectl get configmap bai-bai-access-info -o yaml

2.     Access the URL for Business Performance Center, OpenSearch URL.
 

Fresh IBM Business Automation Insights (BAI) Production Deployment in a CNCF Platform is now completed successfully!