Author: Benjamin Wende
IntroductionThe Business Teams Service (BTS) is a foundation service that is used within CloudPak for Business Automation. BTS and it's Operator in Openshift own a Custom Resource Definition that defines the configuration attributes of the BTS server instance. This Blog describes the procedure to apply custom configuration for BTS when used with CloudPak for Business Automation (CP4BA) and the CP4BA-Operator and Custom Resource (CR). The features described in this Blog are available with the July interim fixes for CP4BA 22.0.1 and 21.0.3.Configuration in CP4BACustom configuration for CP4BA is usually applied in the Openshift/Kubernetes Custom Resource instance of type icp4acluster. For example, the YAML content of an already installed CR can be shown with:
# list the available icp4acluster instance, usually exactly 1
oc get icp4acluster
# show the YAML source
oc get icp4acluster <name> -o yaml
Custom BTS ConfigurationThe custom configuration for BTS is also part of the CP4BA Custom Resource YAML. In order to add this custom configuration for BTS, the spec.bts_configuration section needs to be added to the icp4acluster YAML:
...
spec:
bts_configuration:
template:
<bts-configuration-items>
...
The whole sub-mapping of the template section will be copied over to the BTS CR that is created by the CP4BA Operator. CP4BA has a default BTS CR that by default contains certain configuration options, like a storage-class, image-pull-secrets and a deployment-profile for sizing the BTS deployment. Using the template above, it is also possible to overwrite these default-settings, e.g. to use a different storage-class as well as adding your own configuration options.BTS Configuration OptionsThe available BTS Configuration Options depend on the version that is used in the Openshift Cluster. To list the available options, it is possible to inspect the Custom Resource Definition (CRD) of BTS. Below are example commands on how to do this.
# show the BTS CRD including it's schema
oc get crd businessteamsservices.operator.ibm.com -o yaml
# list the top-level configuration attributes and their description, this is using the jq tool for formatting
oc get crd businessteamsservices.operator.ibm.com -o json | jq '.spec.versions[0].schema.openAPIV3Schema.properties.spec.properties | to_entries | .[] | .key + ": " + .value.description'
Sample output:
...
"deploymentProfile: The Deployment Profile of BTS (can be \"starter\" or \"production\")"
"deploymentProfileSize: The Deployment Profile Size of BTS (can be \"small\", \"medium\" or \"large\")"
...
Example 1: Configure BTS Backup to Amazon S3In order to enable the BTS backend to backup it's data into an Amazon S3 bucket, following configuration would need to be added to the bts_configuration section.
spec:
bts_configuration:
template:
backup:
barmanObjectStore:
destinationPath: s3://<amazon-s3-bucket-name>/
s3Credentials:
accessKeyId:
key: ACCESS_KEY_ID # key inside the s3-credentials secret
name: s3-credentials # points to a secret name
secretAccessKey:
key: ACCESS_SECRET_KEY
name: s3-credentials
Note that this will only enable the Backup procedure, but not start it immediately. A Backup or a Scheduled Backup must be triggered by a Backup or ScheduledBackup CR. More details on this procedure can be found in [1].Example 2: Configure BTS Recovery from a Amazon S3 BackupThe BTS database can also be recovered from an existing Backup in Amazon S3. Note that it is important to fill-in this configuration before the CP4BA CR is applied for the first time. Otherwise the database is already initialized and will not be recovered afterwards.
spec:
bts_configuration:
template:
recovery:
barmanObjectStore:
destinationPath: s3://<s3-bucket-name>/
s3Credentials:
accessKeyId:
key: ACCESS_KEY_ID
name: s3-credentials
secretAccessKey:
key: ACCESS_SECRET_KEY
name: s3-credentials
Further ExamplesEnable a Deployment ProfileDeployment Profiles help to scale BTS with pre-defined values. For more information about Deployment Profiles, see the Scaling section in [2].
spec:
bts_configuration:
template:
deploymentProfile: "production"
deploymentProfileSize: "large"
Scale BTS using custom replica countsBelow example will scale the BTS to 6 pods and the PostgreSQL pods to 2. Note that more than 2 database pods might not be helpful, as the database has always 1 active replica and a number of secondary in-active pods. These pods get only active when the active pod fails. Instead it might make sense to increase memory on the database pods, as shown below.
spec:
bts_configuration:
template:
replicas: 6
replicasDatabase: 2
Assign custom resource requests and limitsIn the example below, custom CPU and memory resources are assigned to BTS and it's database.
spec:
bts_configuration:
template:
resources:
limits:
cpu: "2"
memory: "2Gi"
requests:
cpu: "1"
memory: "1Gi"
resourcesPostgres:
limits:
cpu: "2"
memory: "2Gi"
requests:
cpu: "1"
memory: "1Gi"
Activate trace logs in the BTS server instanceBelow example will enable typical trace settings in the BTS server instance. For more information about traces, see the Troubleshooting section in [3].
spec:
bts_configuration:
template:
traceSpec: "com.ibm.dba.ums.*=all:*=info"
Reference:[1] BTS Knowledge Center - Backing up and restoring: https://www.ibm.com/docs/en/cloud-paks/1.0?topic=service-backup-restore[2] BTS Knowledge Center - Post Installation: https://www.ibm.com/docs/en/cloud-paks/1.0?topic=service-post-installation[3] BTS Knowledge Center - Troubleshhoting: https://www.ibm.com/docs/en/cloud-paks/1.0?topic=service-troubleshooting