Orchestrating Dundas BI with Kubernetes and Helm charts

Contents[Hide]

1. Overview

This article outlines using Dundas BI with Kubernetes and Helm charts for automated scaling and management of Dundas BI containers.

2. Prerequisites

This article is advanced and assumes you already have the following:

A Kubernetes cluster
Helm 3 installed

For information about these, see Getting started in the Kubernetes documentation, and Quickstart Guide in the Helm documentation.

3. Helm repository

To add the Dundas repository, run the following command:

helm repo add dundas https://helm-charts.dundas.com/repo/
helm repo update

4. Installing the chart

To install the chart with the release name my-dundasbi:

helm install my-dundasbi dundas/dundasbi --set dundas.bi.appDb.appDbConnString="YourConnectionString"

This command deploys Dundas BI on the Kubernetes cluster with the default configuration. The Parameters section below lists the parameters that can be configured during installation.

Tip

List all releases using helm list.

5. Uninstalling the chart

helm delete my-dundasbi

This command removes all the Kubernetes components associated with the chart and deletes the release.

6. Parameters

The following table lists the configurable parameters of the Dundas BI chart and their default values:

Parameters	Description	Default
version	The version of Dundas BI images to pull.	8.0.0.101
dundas.bi.appDb.appDbConnString	The application database connection string. This is used if dundas.bi.appDb.useExistingSecretForAppDbConnString is set to false.	placeholder
dundas.bi.appDb.useExistingSecretForAppDbConnString	If dundas.bi.appDb.useExistingSecretForAppDbConnString is set to true, the dundas.bi.appDb.secretKeyRef.appDbConnStringSecretName and dundas.bi.appDb.secretKeyRef.appDbConnStringSecretKey are used to set the application database connection string. Otherwise, the dundas.bi.appDb.appDbConnString is used.	false
dundas.bi.appDb.secretKeyRef.appDbConnStringSecretName	The name of the secret that has the Dundas BI application database connection string.	placeholder
dundas.bi.appDb.secretKeyRef.appDbConnStringSecretKey	The key of the secret that has the Dundas BI application database connection string.	DBI_CONNECTION_STRING
dundas.bi.appDb.appStorage	The application database type: either SqlServer or Postgres.	SqlServer
dundas.bi.website.port	The port to run the Dundas BI website on.	9090
dundas.bi.website.replicaCount	The number of Dundas BI website replicas. This is only used if dundas.bi.website.autoscaling.enabled is false .	1
dundas.bi.website.autoscaling	The parameters for autoscaling the Dundas BI website.	{ enabled: false, minReplicas: 1, maxReplicas: 100, targetCPUUtilizationPercentage: 80 }
dundas.bi.website.image.override.enabled	Enables overriding the Dundas BI website image.	false
dundas.bi.website.image.override.name	The name of the Dundas BI website image to override.
dundas.bi.website.includeSchedulerInWebsiteContainer	Set to true to deploy the scheduler inside the Dundas BI website container, which means you will not need a separate scheduler deployment and you would set dundas.bi.scheduler.enabled to false.	false
dundas.bi.scheduler.enabled	This will create the scheduler deployment.	true
dundas.bi.scheduler.replicaCount	The number of Dundas BI scheduler replicas.	1
dundas.bi.scheduler.sleepInSecondsOnStart	Delay after the website has started to start the scheduler.	120
dundas.bi.scheduler.image.override.enabled	Enables overriding the Dundas BI scheduler image.	false
dundas.bi.scheduler.image.override.name	The name of the Dundas BI scheduler image to override.
image.pullPolicy	The container image pull policy.	IfNotPresent
imagePullSecrets		[]
service.enabled	Enable the service.	true
service.type	The type of service.	ClusterIP
service.sessionAffinity	The sessionAffinity for the service.	ClientIP
ingress.enabled	Set to true to enable the ingress.	false
ingress.annotations	Ingress load balancer annotations	{}
ingress.hosts	Proxied hosts.	[]
ingress.tls	This maximum number of Dundas BI websites when autoscaling.	[]

7. Defining the Dundas BI connection

There are two ways to define the Dundas BI connection string:

Define the dundas.bi.appDb.appDbConnString parameter, and define the dundas.bi.appDb.appStorage.
Alternatively, create a secret and set dundas.bi.appDb.useExistingSecretForAppDbConnString to true. Next pass the name of the secret with dundas.bi.appDb.secretKeyRef.appDbConnStringSecretName, and the key with dundas.bi.appDb.secretKeyRef.appDbConnStringSecretKey. Finally, define the dundas.bi.appDb.appStorage.

8. Defining the Dundas BI website

The Dundas BI website parameter names start with dundas.bi.website.

The dundas.bi.website.port is the port that the website runs on.

To scale the Dundas BI website, you can either set the dundas.bi.website.replicaCount to the number of Dundas BI websites you would like across the cluster, or set the dundas.bi.website.autoscaling properties, which will take precedence over the dundas.bi.website.replicaCount property. When the dundas.bi.website.autoscaling.enabled parameter is true, a HorizontalPodAutoscaler will be created in Kubernetes with the details.

9. Defining the Dundas BI scheduler

Dundas BI requires one scheduler service. If multiple scheduler services are running only one will do the work at a time, and the others will act as a backup if it goes down.

The Dundas BI Helm chart allows for multiple ways to set up the scheduler service, determined by the parameters with names starting with dundas.bi.scheduler:

The service can be added to every website deployment by setting the dundas.bi.website.includeSchedulerInWebsiteContainer to true, which will add the scheduler to the website deployment container(s).
Alternatively, you can run the scheduler as a separate deployment by setting the dundas.bi.scheduler.enabled to true.

10. Defining the service

To enable a service to be created with your Dundas BI Helm deployment, set the service.enabled to true. Otherwise, it will be expected that after deploying you would set this up manually in Kubernetes.

If you plan on using an ingress, the default service type is ClusterIP. If want to expose the Dundas BI website but don't plan on using an ingress, you would use ClusterIP and use a kubectl port forward command, or you can expose it by setting the service.type to LoadBalancer.

11. Load balancing

It is important to enable sticky sessions for any load balanced implementation of Dundas BI. The following is an example of the annotations to add to enable sticky sessions with a NGINX ingress controller:

ingress:
  enabled: true
  annotations: 
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "dbiroute"
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
    nginx.ingress.kubernetes.io/session-cookie-path: /

12. SSL

It is expected to use an ingress to enable SSL with the Dundas BI Helm chart. You would first create a secret with your certificate information by calling kubectl:

kubectl create secret tls exampledomain --key C:\temp\exampledomain.keyfile --cert C:\temp\exampledomain.certfile

Then you would apply that secret to the ingress inside the tls:

ingress:
  ...
  hosts:
    - host: exampledomain.com
      paths: 
        - /
  tls: [ { hosts: [ exampledomain.com ], secretName: exampledomain } ]

13. Image overriding

In order for certain drivers to work it may be necessary to override the Dundas BI docker images. In this case you would set dundas.bi.website.image.override.enabled to true and then define the new image name using dundas.bi.website.image.override.name. Both the Dundas BI website and scheduler contain these properties and can be overridden.

14. Upgrading

An upgrade can be accomplished by setting the version parameter to a new version.

Upgrading to a new major version will require upgrading Dundas BI's application and warehouse databases, which should be performed prior to setting the version parameter. The following will perform this database upgrade:

If the database server is on a Kubernetes cluster, use kubectl to call the setup image of the same version. The following is an example of this:
```
kubectl run -it mydundassetup --image dundas/dundas-bi-setup:{new version number} --rm
```
Alternatively, you can call a docker command to run the database upgrade:
```
docker run -it dundas/dundas-bi-setup:{new version number}
```

Revision upgrades do not require database upgrades and can be done by setting the version parameter. Alternatively, upgrades can be accomplished by overriding the images with new upgraded images.

Welcome to Dundas BI Support