Orchestrating Dundas BI with Kubernetes and Helm charts

Contents[Hide]

Note

See the Logi Symphony documentation first if you are installing Logi Symphony. The following only applies for the Managed Dashboards & Reports module or for Dundas BI.

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 rather than managing and running Docker images directly, and it will handle many aspects of deployment and scaling for you automatically. You can deploy Dundas BI this way on your choice of OS or cloud platform.

Note

There are certain known limitations when Dundas BI runs on Linux, including these images when using Kubernetes.

2. Prerequisites

Deploying using Dundas BI Helm charts requires 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.

Tip

If you have Docker Desktop installed, its Enable Kubernetes option can be used to start a single-node test cluster.

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. Helm chart use & parameters

See the Helm chart readme on GitHub for all other details on using the Dundas Helm chart and the parameters available. These parameters also apply for the Logi Symphony Helm chart but under managed in its YAML.

If you are defining connection strings to Dundas BI application and warehouse databases, details on their syntax and options can be found in Microsoft Docs for SQL Server and Npgsql for PostgreSQL.

Tip

In general, the Helm chart will configure many things for you automatically, such as the Internal Application URL configuration setting. The express option can deploy and configure a database server for Dundas BI to use as storage automatically, although this is recommended only for evaluation purposes.

5. Other considerations

5.1. WSL2 notes

Due to WSL2 not supporting service sessionAffinity (https://github.com/microsoft/WSL/issues/7124), the defaults in the Dundas BI helm chart will cause the services to be unavailable. This will be worked around in version 11. Until then when using WSL2 for Kubernetes set dundas.bi.website.service.sessionAffinity to None, and set dundas.bi.authbridge.service.sessionAffinity to None. In this scenario, do not use any website scaling or replicas.

5.2. 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 in the same image as the Dundas BI website. This can be done by setting dundas.bi.website.includeSchedulerAndAuthBridgeInWebsiteContainer to true, then setting dundas.bi.authbridge.enabled and dundas.bi.scheduler.enabled to false. Alternatively, you would need to use networking to ensure that the Dundas BI authbridge website is a subdirectory below the Dundas BI website. For more information, see the Dundas BI and reverse proxies article.

Dundas BI, Managed Dashboards & Reports Support