Orchestrating Dundas BI with Kubernetes and Helm charts

1. Overview

This article describes how to run Dundas BI on Kubernetes using Helm charts for automated scaling and management of Dundas BI containers.

These containers run Dundas BI Docker images, but you can use a Helm chart as shown below rather than managing and running Docker images directly. You can deploy Dundas BI this way on your choice of OS or cloud platform.

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/dundas-bi --set dundas.bi.appDb.express="true" --set dundas.bi.key.email="youremail@yourdomain.com" --set dundas.bi.key.key="12345-54321-12345-54321"

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.

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 tables lists the configurable parameters of the Dundas BI chart and their default values:

6.1. Key

When creating new databases through the chart you will be required to enter your email and key. The key is available in the downloads section: https://www.dundas.com/support/my-account/#downloads. If you do not have an account you can create one at https://www.dundas.com/support/. It's easy to create and free. If you are not creating new databases these parameters can be left as defaults.

6.2. Database

6.3. Website

6.4. Scheduler

6.5. AuthBridge

6.6. Setup

6.7. Password

6.8. Image

6.9. Ingress

7. Defining the Dundas BI connection

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

• Set dundas.bi.appDb.express to true. This will create PostgreSQL database pods and will be used for this instance.
• 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 Dundas BI authbridge

There are two ways to enable the authbridge. The first way is to set dundas.bi.website.includeSchedulerAndAuthBridgeInWebsiteContainer to true. The second way is set dundas.bi.website.includeSchedulerAndAuthBridgeInWebsiteContainer to false, and set dundas.bi.authbridge.enabled to true. In this case it requires the ingress to be enabled as the authbridge website needs to be placed as a virtual directory under the Dundas BI website.

11. 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.

12. 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 an 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: /

13. 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 } ]

14. 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. You can override both the Dundas BI website and scheduler images in this way using their respective parameters.

15. Upgrading

An upgrade can be accomplished by setting the version parameter to a new version.  Upgrading to a new major version will require a database upgrade and this will be done automatically when setting the new version. It is recomended to back up the Dundas BI databases before upgrading.

16. Setup orchestrator

The Dundas BI setup orchestrator provides a means of managing initialization traffic by providing a simple locking mechanism to prevent multiple pods running the initialization at the same time. It is enabled when dundas.bi.website.replicaCount is greater than one, or if dundas.bi.website.autoscaling.enabled is set to true.

17. Other considerations

17.1. OpenShift notes

• When using Federated Authentication on Red Hat OpenShift, it is recommended to use the Dundas BI full image that contains both the scheduler and the authbridge website inside the Dundas BI website image. This can be done by setting dundas.bi.website.includeSchedulerAndAuthBridgeInWebsiteContainer to true, and then setting to dundas.bi.authbridge.enabled, and dundas.bi.scheduler.enabled to false. Alternatively, you would need to use networking to ensure that the DundasBI authbridge website is a directory below the Dundas BI website. For more information, see the Dundas BI and reverse proxies article.

18. See also

• Kubernetes: Getting started
• Helm: Quickstart Guide
• Kubernetes: Container Images
• Using Dundas BI Docker containers