Introduction
With Business Teams Service (BTS) v3.27.0 it is now possible to bring your own database. Previously only the built-in PostgreSQL database could be used with BTS. Now an existing PostgreSQL database can be used, which will save CPU and Memory resources in the Kubernetes Cluster, where BTS is installed. Although resources still need to be spend on the shared database too, it might still lead to overall reduced resource consumption when using a shared database instance for several services.
Database Configuration
BTS v3.27.0 introduces new configuration properties to the BTS Custom Resource (CR). Here is an example for a custom Database Configuration:
apiVersion: operator.ibm.com/v1alpha1
kind: BusinessTeamsService
metadata:
name: bts
namespace: cp4ba
spec:
databaseConfig:
serverName: mypostgresql.ibm.com
portNumber: 5432
databaseName: umsdb02
userSecretName: postgresql-user
ssl: "true"
sslMode: verify-ca
sslSecretName: postgres-ssl
The databaseConfig property indicates that no separate EDB PostgreSQL installation should be deployed for this BTS installation and there is already an existing database that hosts the BTS data.
The basic database configuration properties include the serverName, the portNumber and databaseName. These properties define the database endpoint and the database name to use. BTS will automatically create the necessary tables in this database if they do not exist.
Further there is the userSecretName. This must point to an existing secret in the same namespace as BTS should be installed. An example secret resource looks like this:
apiVersion: v1
kind: Secret
metadata:
name: postgresql-user
type: Opaque
stringData:
username: "postgres"
password: "Passw0rd"
The username and password properties in this secret define the credentials for login to the database.
SSL Configuration
In order to keep communication between BTS and the database private, it is strongly recommended to use SSL Encryption. The example above shows the properties ssl, sslMode and sslSecretName.
The ssl property is a boolean switch that must be set to “true” in order to enable SSL communication in general.
The sslMode property defines how the certificate of the database should be validated by the client. It is recommended to set this to verify-ca or verify-full. The value verify-ca will verify the Certificate, but not the hostname, while verify-full will also verify the hostname of the Certificate. The meaning of the single SSL Modes is fully documented under [1].
The sslSecretName must point to an existing secret in the same namespace where BTS is installed. The example below shows such a secret:
apiVersion: v1
kind: Secret
metadata:
name: postgres-ssl
type: Opaque
stringData:
ca.crt: |-
-----BEGIN CERTIFICATE-----
…<PEM encoded CA certificate>…
-----END CERTIFICATE-----
tls.crt: |-
-----BEGIN CERTIFICATE-----
…<PEM encoded certificate>…
-----END CERTIFICATE-----
In the example the secret contains the keys ca.crt and tls.crt. These keys contain the respective certificate data as PEM encoded strings. It’s also possible to set only one of the keys. The content of the secret will be mounted into the BTS container. The ca.crt property will be set as sslrootcert property of the data source and tls.crt will be set as value of sslcert. The properties sslrootcert and sslcert are fully documented in [1].
Custom Properties
It is also possible to set custom properties in order to handle special configuration cases. For example:
apiVersion: operator.ibm.com/v1alpha1
kind: BusinessTeamsService
metadata:
name: bts
namespace: cp4ba
spec:
databaseConfig:
userSecretName: postgresql-user
customProperties:
- name: connectTimeout
value: "5"
- name: URL
value: jdbc:postgresql://mypostgresql.ibm.com:5432/umsdb02
In this case the JDBC URL is directly set via the customProperties list. The JDBC URL already contains the host, port and database name, so there is no need to set any of these properties under databaseConfig. Further another custom property called connectTimeout is set to a value of “5” seconds. Note that it is still needed to set userSecretName as the database credentials must be passed in a confidential way. It is not recommended to directly set username and password via custom properties.
All supported properties that my be specified under customProperties are documented in [2] (section properties.postgresql), while some of the descriptions can only be taken from [1].
Configuration in CloudPak for Business Automation (CP4BA)
In CP4BA there is a separate CR kind present that is called icp4acluster. This CR defines the CloudPak installation configuration. Because the BTS CR is created automatically by the CP4BA Operator, the BTS CR cannot be changed directly. Any changes will be overwritten after a short time.
To overcome this limitation, the CP4BA CR has a mechanism to pass in any custom BTS CR configuration. The mechanism is further described in another Blog in [3].
An example with the databaseConfig from above would look like this:
apiVersion: icp4a.ibm.com/v1
kind: ICP4ACluster
metadata:
name: icp4a-deploy
spec:
bts_configuration:
template:
databaseConfig:
userSecretName: postgresql-user
customProperties:
- name: connectTimeout
value: "5"
- name: URL
value: jdbc:postgresql://mypostgresql.ibm.com:5432/umsdb02
There is a template property under bts_configuration that may contain any custom configuration. The CP4BA Operator will take over this configuration and merge it into the default BTS CR.
Reference