Using external database and storage services with Concert Workflows

By default, important Concert Workflows data is stored in internal instances of database and storage services, such as MySQL, PostgreSQL, and Minio. When you install Concert Workflows, you can use external MySQL and PostgreSQL databases and an AWS S3 bucket for data and object storage instead.

Attention: This feature is not supported in Concert Workflows deployments on FIPS-enabled environments.

To use one or more of these external services, you must create a base64-encoded secret called cw-secrets in the namespace where you intend to install Concert Workflows.

When you create this secret, you must provide the required access parameters and values for each of the external services that you want to use. You must also ensure that the values in the secret are base64-encoded by including --from-literal or --from-file options in the create secret command.

If all of the required fields are included in the secret, Concert Workflows will use the external services that you specified after its installation is complete.

For more information about the sizing and configuration requirements for each external service, as well as the service parameters that you must provide in the Kubernetes secret, review the following sections.

Using an external MySQL database

MySQL is an open-source relational database management system (RDBMS). By default, Concert Workflows uses an internal MySQL database to store important data, such as workflows, authorization keys, permissions, and other configuration data. All sensitive information, such as authentication credential information, is encrypted.

If you want to use an external MySQL database instead, you must ensure that it is sized and configured appropriately, and ensure that you configure the required parameters when you create the Kubernetes secret.

Sizing requirements for host server
The host server where you intend to install the external MySQL instance must, at a minimum, meet these resource allocation requirements:
  • 2 allocated virtual CPUs (vCPUs).
  • 4 gigabytes (GB) of allocated RAM.
  • 50 GB of allocated disk storage space.
If you intend to provision the MySQL instance in the cloud, use an appropriate managed database service or instance type that fits your chosen cloud platform and meets these resource requirements.
Supported MySQL version

The MySQL version for the external database must be 8.0.0 or later.

Database server configuration
In the MySQL database server configuration file, to ensure efficient database performance, set the tuning parameters that are shown in this table to the specified values:
Table 1. Recommended MySQL database server parameter values
Parameter Value
max_binlog_size 100M
expire_logs_days 1
default-authentication-plugin mysql_native_password
ssl-fips-mode STRICT
max_connections 151
innodb_buffer_pool_size 128 MB
innodb_log_buffer_size 16 MB
innodb_log_file_size 48 MB
tmp_table_size 16 MB
max_heap_table_size 16 MB

For more information about performance tuning in MySQL databases, see MySQL Performance Tuning and Optimization Resources.

Database preparation

In the external MySQL database, create an administrative database user that has sufficient privileges to manage the application schema (for example, a user that has these privileges: CREATE, ALTER, DROP, INDEX, SELECT, INSERT, UPDATE, DELETE).

When you create the Kubernetes secret later, you must specify the username and password for this administrative user.

Recommendations for using Amazon Aurora MySQL
If you intend to use the Amazon Aurora MySQL service that is offered by Amazon Web Services (AWS) as your external MySQL database, follow this process:
  1. In the Amazon RDS console, create a database parameter group and choose Aurora MySQL as the database engine.
  2. Configure all required MySQL parameters as specified in table 1 ('Recommended MySQL database server parameter values').
  3. Create the Aurora cluster and the Aurora MySQL database.
  4. Create a dedicated application database user with the required privileges (for example, a user that has these privileges: CREATE, ALTER, DROP, INDEX, SELECT, INSERT, UPDATE, DELETE).
  5. Associate the custom DB cluster parameter group with the newly created Aurora MySQL cluster.
After the cluster is created and the parameter group is applied, you can validate the database configuration by using standard MySQL commands, for example:.
SHOW VARIABLES LIKE 'max_connections'

When deploying Amazon Aurora MySQL, network access to the database must be enabled within the VPC where the Aurora cluster is created. The database port that is configured for the Aurora cluster (for example, 3306 for MySQL) must be consistently allowed at the network level and match the port value that is provided to Concert Workflows during installation.

For more information about Amazon Aurora MySQL, see Working with Amazon Aurora MySQL.

Configuring the Kubernetes secret

To use an external MySQL database instance, include the following parameters and appropriate values when you create the cw-secrets secret:

Table 2. Secret parameters and values for an external MySQL database
Parameter Value
MYSQLDB_HOST The domain name of the external MySQL database's host server.
MYSQLDB_PORT The server port number where the external MySQL database is hosted.
MYSQLDB_USER The username of the administrative user that you configured in the external MySQL database.
MYSQLDB_PASSWORD The configured user's password.
MYSQLDB_DBNAME The name of the external MySQL database.
For example, you might create a secret to store the access details for an external MySQL database by running this command:
kubectl create secret generic cw-secrets \
 --namespace=concert-workflows \
 --from-literal=MYSQLDB_HOST="my-server.example.com" \
 --from-literal=MYSQLDB_PORT="3306" \
 --from-literal=MYSQLDB_USER="admin" \
 --from-literal=MYSQLDB_PASSWORD="adminpw456" \
 --from-literal=MYSQLDB_DBNAME="extmySQLDB" 

If all of the required fields are included in the secret, Concert Workflows will use the external MySQL database when you complete the installation. If not, the default internal MySQL database will be used.

Backing up and restoring

External MySQL databases are not included in the standard Concert Workflows backup and restore process. If you use an external MySQL database, you must make arrangements to back it up and, if required, restore it.

Using an external PostgreSQL database

PostgreSQL, also known as Postgres, is a free and open-source relational database management system (RDBMS). By default, Concert Workflows uses an internal PostgreSQL database to store data that can be accessed by the ai assistant, such as example workflows, information about available Concert Workflows integrations, and product documentation.

If you want to use an external PostgreSQL database instead, you must ensure that it is sized and configured appropriately, and ensure that you configure the required parameters when you create the Kubernetes secret.

Note: You must use a PostgreSQL database distribution or managed service in which the pgvector extension is supported.
Sizing requirements for host server
The host server where you intend to install the external PostgreSQL instance must, at a minimum, meet these resource allocation requirements:
  • 2 allocated virtual CPUs (vCPUs).
  • 8 gigabytes (GB) of allocated RAM.
  • 50 GB of allocated disk storage space.
If you intend to provision the PostgreSQL instance in the cloud, use an appropriate managed database service or instance type that fits your chosen cloud platform and meets these resource requirements.
Supported PostgreSQL version

The PostgreSQL version for the external database must be 15.0 or later.

Database configuration
In the PostgreSQL database configuration, to ensure efficient database performance, set the tuning parameters that are shown in this table to the specified values:
Table 3. Recommended PostgreSQL database configuration parameter values
Parameter Value
synchronous_commit off
wal_writer_delay 500ms
wal_buffers 64 MB
max_wal_size 4 GB
checkpoint_timeout 30 min
autovacuum off
max_connections 100
shared_buffers 128 MB
work_mem 4 MB
maintenance_work_mem 64 MB
effective_cache_size 4 GB

For more information about performance tuning in PostgreSQL databases, see Performance Tips.

If you intend to use the Amazon Aurora PostgreSQL service that is offered by Amazon Web Services (AWS) as your external PostgreSQL database, you can configure these parameters by setting up a custom database parameter group. For more information about Amazon Aurora PostgreSQL, see Working with Amazon Aurora PostgreSQL.

Database preparation
In the external PostgreSQL database, enable the pgvector extension by connecting to the database instance and running this command:
CREATE EXTENSION IF NOT EXISTS vector;
Tip: If you intend using Amazon Aurora PostgreSQL service as your external PostgreSQL database, you can connect to the database instance via AWS CloudShell or a bastion host, then enable the extension.

In addition, you must create an administrative database user that has sufficient privileges to manage the application schema (for example, a user that has these privileges: CREATE, ALTER, DROP, INDEX, SELECT, INSERT, UPDATE, DELETE).

When you create the Kubernetes secret later, you must specify the username and password for this administrative user.

Configuring the Kubernetes secret

To use an external PostgreSQL database instance, include the following parameters and appropriate values when you create the cw-secrets secret:

Table 4. Secret parameters and values for an external PostgreSQL database
Parameter Value
POSTGRESQL_HOST The domain name of the external PostgreSQL database's host server.
POSTGRESQL_PORT The server port number where the external PostgreSQL database is hosted.
POSTGRESQL_USER The username of the administrative user that you configured in the external PostgreSQL database.
POSTGRESQL_PASSWORD The configured user's password.
POSTGRESQL_DBNAME The name of the external PostgreSQL database.
For example, you might create a secret to store the access details for an external PostgreSQL database by running this command:
kubectl create secret generic cw-secrets \
 --namespace=concert-workflows \
 --from-literal=POSTGRESQL_HOST="my-host.ibm.com" \
 --from-literal=POSTGRESQL_PORT="5432" \
 --from-literal=POSTGRESQL_USER="admin" \
 --from-literal=POSTGRESQL_PASSWORD="adminpw123" \
 --from-literal=POSTGRESQL_DBNAME="myextPGDB" 

If all of the required fields are included in the secret, Concert Workflows will use the external PostgreSQL database when you complete the installation. If not, an internal PostgreSQL database will be used.

Backing up and restoring

External PostgreSQL databases are not included in the standard Concert Workflows backup and restore process. If you use an external MySQL database, you must make arrangements to back it up and, if required, restore it.

Using AWS S3 for object storage

By default, Concert Workflows uses an internal instance of the Minio object storage service to store configuration files and worker builds. However, when you install Concert Workflows, you can use an Amazon S3 bucket to store this data instead.

Simple storage service (S3) is a cloud-based object storage service that is offered by Amazon Web services (AWS). Data is stored as objects in AWS S3 buckets, each of which has its own access controls and geographic region.

If you want to use an S3 bucket for object storage with Concert Workflows, you must create an identity and access management (IAM) user in AWS that has the required access permissions for the S3 bucket, then ensure that you configure the required parameters when you create the Kubernetes secret.

AWS configuration
In your AWS account, create an IAM user, then create a policy that includes the following permissions for the S3 bucket that you want to use and attach the policy to the IAM user:
  • s3:Listbucket
  • s3:Getobject
  • s3:Putobject
  • s3:Deleteobject
For more information about S3 policies and permissions, see Policies and permissions in Amazon S3.
Note: If the S3 bucket that you want to use does not exist, you do not need to create it. If you include the bucket name in the CW_BUCKET attribute when you create the Kubernetes secret, the bucket will be created and configured automatically in AWS when you install Concert Workflows.
Configuring the Kubernetes secret

To use an AWS S3 bucket for object storage with Concert Workflows, include the following parameters and appropriate values when you create the cw-secrets secret:

Table 5. Secret parameters and values for an AWS S3 bucket
Parameter Value
CW_ACCESS_KEY The access key ID of the IAM user that you created.
CW_SECRET_KEY The secret access key of your IAM user.
CW_AUTH_TYPE The AWS authentication type. This value must be set to HMAC.
CW_BUCKET The name of the S3 bucket that you want to use.
CW_HOST The AWS host where the bucket is located. This value must be set to s3.<region>.amazonaws.com, where <region> contains the host’s AWS region.
CW_REGION The region where the AWS host and bucket are located.
CW_PORT The Concert Workflows port that is used for communication with the AWS host. This value must be set to 443.
For example, you might create a secret to store the access details for an AWS S3 bucket by running this command:
kubectl create secret generic cw-secrets \
 --namespace=concert-workflows \
 --from-literal=CW_ACCESS_KEY=AKIaiOSFODNN7EXAMPLE \
 --from-literal=CW_SECRET_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
 --from-literal=CW_AUTH_TYPE=HMAC \
 --from-literal=CW_BUCKET=my-S3-bucket-name \
 --from-literal=CW_HOST=s3.us-east-1.amazonaws.com \
 --from-literal=CW_REGION=us-east-1 \
 --from-literal=CW_PORT=443 

If all of the required fields are included in the secret, Concert Workflows will use the AWS S3 bucket for object storage when you complete the installation. If not, the internal Minio object storage service will be used.

Backing up and restoring

AWS S3 buckets that are used with Concert Workflows are not included in the standard backup and restore process. If you use an AWS S3 bucket, you must make arrangements to back it up.

Using more than one external service

To use more than one external service, ensure that when you create the cw-secrets secret, you include the required access parameters and values for each external service that you want to use. For example, to create a secret that stores the access details for an external PostgreSQL database and an AWS S3 bucket, you might run this command:
kubectl create secret generic cw-secrets \
 --namespace=concert-workflows \
 --from-literal=POSTGRESQL_HOST="my-HOST.ibm.com" \
 --from-literal=POSTGRESQL_PORT="3306" \
 --from-literal=POSTGRESQL_USER="admin" \
 --from-literal=POSTGRESQL_PASSWORD="adminpw123" \
 --from-literal=POSTGRESQL_DBNAME="myextPGDB" \
 --from-literal=CW_ACCESS_KEY=AKIaiOSFODNN7EXAMPLE \
 --from-literal=CW_SECRET_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
 --from-literal=CW_AUTH_TYPE=HMAC \
 --from-literal=CW_BUCKET=my-S3-bucket-name \
 --from-literal=CW_HOST=s3.us-east-1.amazonaws.com \
 --from-literal=CW_REGION=us-east-1 \
 --from-literal=CW_PORT=443