Install Symphony - Kubernetes

Adding Logi Symphony to your environment involves installing, configuring, and licensing the components you'll use as a stand alone or embedded resource. You may need to install multiple components that work together to provide your desired analytics experience, depending on your licensing arrangements.

Important: To install Symphony in a Kubernetes environment, you'll need an intermediate level of familiarity and experience with Kubernetes. See https://kubernetes.io/docs/home/.

Important: Download the latest installation package and the complete readme at https://repo-logisymphony.insightsoftware.com/helm-charts/.

Prerequisites

A Kubernetes cluster of appropriate compute availability
The Helm CLI installed
Your command line tool, kubectl, is installed and configured to use with your cluster
Know your selection of modules you wish to install:
- Full Symphony
- Symphony with Logi AI (beta)
- Symphony with Visual Data Discovery only
- Symphony with Managed Dashboards and Reports only

Kubernetes Cluster Requirements

There are no specific limits in the Helm chart by default, but we suggest the following compute availability on your cluster:

Recommended Compute Availability

10 Cores
24 Gi Memory

Required for Scheduling by Kubernetes

4 Cores
16 Gi Memory

Important: These specifications are intended as an initial installation guide. Your environment's specific workloads may demand a higher number of cores and more memory available for computing.

Other Requirements

The memory requirements above do not take into account other components that are a part of Logi Symphony. These components are external to Helm chart requirements. Size your environment following the recommendations for each component. These components include:

PostgreSQL
RabbitMQ

Installation Steps - All Modules

Step 1: Install a Proxy or Ingress Controller
Step 2: Determine Your URL
Step 3: Add the Symphony Helm Repository
Step 4: Create a Symphony values.yaml File
Step 5: Install Logi Symphony
Step 6: Get the Pods for Your Namespace

For information about accessing Symphony after it is installed, see Access Symphony and Log Into the Symphony UI .

Step 1: Install a Proxy or Ingress Controller

Install the proxy or ingress controller you want to use to provide flexible control over incoming traffic to your Symphony environment.

One option is to install a NGINX Ingress Controller as in the example provided here.

Note: For other install methods for the ingress controller, see https://bitnami.com/stack/nginx-ingress-controller/helm.

Install a NGINX Ingress Controller

Install NGINX using the following commands:

helm repo add bitnami https://charts.bitnami.com/bitnami helm repo update helm install my-ingress-controller bitnami/nginx-ingress-controller
Verify your ingress controller by running the following command to return all services in the namespace:

kubectl get services
If the EXTERNAL-IP is set to a value and not stuck in a pending space, the ingress controller is exposed correctly. You can additionally verify this by visiting the external IP address: you should be served an NGINX 404 page.

Step 2: Determine Your URL

You have two options to choose from for your environment's URL:

Use the EXTERNAL-IP returned in the previous step
Use the URL from your cluster

Step 3: Add the Symphony Helm Repository

Install the Helm chart with the release name of logisymphony1 on your Kubernetes cluster using default configuration settings. Adjust parameters as needed.

helm repo add insightsoftware https://repo-logisymphony.insightsoftware.com/helm-charts/
helm repo update
helm install logisymphony1 insightsoftware/logisymphony	

Uninstall the Helm Chart

If you need to uninstall the Helm chart, run this command to remove all Kubernetes components associated with the chart and delete Symphony.

helm delete logisymphony1

Step 4: Create a Symphony`values.yaml` File

Use Helm to generate a values.yaml file:

helm show values insightsoftware/logisymphony

helm show values insightsoftware/logisymphony > values.yaml

Next, edit in an updated Admin user password, and the ingress information.

Set the Admin Password and Enable Features

Set a strong password: a combination of at least nine characters that includes upper and lower case letters, numbers, and special characters. Enable and disable features as needed:

# Default values for Logi Symphony.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

global:
  logi:
    symphony:  
    
      # Use an existing secret to provide all Logi Symphony related secrets.  
      # It will use a single secret, and will expect specific keys to available in
      # the secret.  See the helm readme for more details on using the value.
      existingSecret: ""
    
      # Set the Composer, and Dundas BI admin credentials.
      auth:
        adminPassword: "ChangeMe!123"
      # If the above section is not set, then the admin password is
      # set through the .values.managed, or .values.discovery sections.

      managed:
        # The managed component cannot be completely be disabled, however setting enabled to false will result in running
        # the managed component in a minimal mode.
        enabled: true
                
      discovery:
        # Disable the data discovery component.
        enabled: true

      rabbitmq:
        # Disables the rabbitmq component.
        enabled: true

      ai:
        # Enables the BETA AI feature.
        enabled: false

Enable the Data Gateways

To enable data gateways, add to the respective modules as needed.

Visual Data Discovery

discovery:
  # Data Gateway Service configuration
  dataGatewayService:
    # Is Data Gateway Service enabled
    enabled: true

Managed Dashboards and Reports

mananged:
  dundas:
    bi:
      gatewayhub:
        # enables the gatewayhub deployment.
        enabled: true

        # The gatewayhub service.
        service:
          enabled: true

Managed Service Values

Set the Managed service values using the managed section of values.yaml.

managed:
# Default values for dundas-bi.
  dundas:
    bi:

Data Discovery Service Values

Set the Data Discovery service values using the discovery section of values.yaml.

discovery:
  zoomdataClient:

Symphony Databases

If global.postgresql.enabled is true, set the Postgres authentication details in the global.postgresql.auth section.

If global.postgresql.enabled is false, set the database information in the managed and discovery sections of the values.yaml. See the Managed Dashboards and Managed Reports helm readme and the Visual Data Discovery helm readme embedded in their respective helm charts.

The other postgres details are set in the postgresql section of the values.yaml as seen in the following example. Add databases for installed modules as needed.

postgresql:
  # Is PostgreSQL database enabled
  enabled: true
  image:
    # Image tag
    tag: 12
  primary:
    initdb:
      # Username to execute the initdb scripts
      user: "postgres"
      # Password to execute the initdb scripts
      password: "LogiSymphony!123456"
      # Scripts to be run at first boot
        scripts:
          "initdbScript.sql": |
            CREATE DATABASE "zoomdata" WITH OWNER logisymphonyuser;
            CREATE DATABASE "zoomdata-upload" WITH OWNER logisymphonyuser;
            CREATE DATABASE "zoomdata-keyset" WITH OWNER logisymphonyuser;
            CREATE DATABASE "zoomdata-user-auditing" WITH OWNER logisymphonyuser;
            CREATE DATABASE "zoomdata-qe" WITH OWNER logisymphonyuser;

Note: To add more databases for the Visual Data Discovery service , create them in this section along with the postgres database.

Data Discovery

Include this initdbScript.sql with appropriate OWNER information for the Visual Data Discovery module.

CREATE DATABASE "zoomdata" WITH OWNER logisymphonyuser;
CREATE DATABASE "zoomdata-upload" WITH OWNER logisymphonyuser;
CREATE DATABASE "zoomdata-keyset" WITH OWNER logisymphonyuser;
CREATE DATABASE "zoomdata-user-auditing" WITH OWNER logisymphonyuser;
CREATE DATABASE "zoomdata-qe" WITH OWNER logisymphonyuser;

Managed Dashboards and Reports

Include this initdbScript.sql with appropriate OWNER information for the Managed Dashboards and Reports modules.

CREATE DATABASE "dundasbi" WITH OWNER test;
\connect "dundasbi";
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "unaccent";
CREATE DATABASE "dundasbiwh" WITH OWNER test;
\connect "dundasbiwh";
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "unaccent";

Logi AI

Include this initdbScript.sql with appropriate OWNER information for the Logi AI module.

Important: This feature is considered to be released in beta for your testing purposes. Workflows and features may change before a production-ready version is released.

CREATE DATABASE "LogiSymphonyAI" WITH OWNER test;
\connect "LogiSymphonyAI";
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

Data Discovery CORS Whitelisting

If you're embedding your Visual Data Discovery content, you must add the appropriate domain names to whitelisting for CORS.

   properties:
     access.control.allow.origin: "example1.com,example2.com"

RabbitMQ Deployment

By default this helm chart will deploy a RabbitMQ helm chart. The RabbitMQ configuration is passed down to sub charts Visual Data Discovery, and Managed Dashboards and Managed Reports via Environment variables set directly in the values.yaml:

discovery:
  zoomdataWeb:
    extraEnvs:
      # RabbitMQ configuration belongs here.
managed:
  dundas:
    bi:
      setup:
        extraEnvs:
        # RabbitMQ configuration belongs here.

Important: RabbitMQ is required. If you prefer to use it outside of the Symphony helm chart, set global.logi.symphony.rabbitmq.enabled to false and define the environment variables above to point to your accessible RabbitMQ instance.

Important: Currently only the values set by default in values.yaml are supported.

Configure RabbitMQ

You can initialize RabbitMQ with Exchanges, Bindings, and Queues in two different ways.

Method one (default): Pass the following Environment variable. With this set, RabbitMQ populates with the required exchanges, bindings, and queues during the handledatabase container as part of the Managed Dashboards and Managed Reports start up.

managed:
  dundas:
    bi:
      setup:
        - name: INIT_RABBITMQ_FOR_SYMPHONY
          value: "true"

Method two: Pass the configuration information as part of configuration.

rabbitmq:
  extraSecrets:
    load-definition:
      load_definition.json: |
        {
          "vhosts": [
          {
            "name": "symphony"
          }
          ],
          "users": [
          {
            "name": "{{ .Values.auth.username }}",
            "password": "{{ .Values.auth.password }}",
            "tags": ["administrator"]
          }
          ],
          "permissions": [
          {
              "user": "{{ .Values.auth.username }}",
              "vhost": "symphony",
              "configure": ".*",
              "write": ".*",
              "read": ".*"
            }
          ],
          "exchanges": [
            {
              "name": "composer.source",
              "vhost": "symphony",
              "type": "topic",
              "durable": true,
              "auto_delete": false,
              "internal": false,
              "arguments": {}
            },
            {
              "name": "dundas.broadcast",
              "vhost": "symphony",
              "type": "fanout",
              "durable": true,
              "auto_delete": false,
              "internal": false,
              "arguments": {}
            }
          ],
          "queues": [
            {
              "name": "create-native-structure",
              "vhost": "symphony",
              "durable": true,
              "auto_delete": false,
              "arguments": {}
            },
            {
              "name": "update-native-structure",
              "vhost": "symphony",
              "durable": true,
              "auto_delete": false,
              "arguments": {}
            },
            {
              "name": "delete-native-structure",
              "vhost": "symphony",
              "durable": true,
              "auto_delete": false,
              "arguments": {}
            },
            {
              "name": "create-native-structure-column",
              "vhost": "symphony",
              "durable": true,
              "auto_delete": false,
              "arguments": {}
            },
            {
              "name": "update-native-structure-column",
              "vhost": "symphony",
              "durable": true,
              "auto_delete": false,
              "arguments": {}
            },
            {
              "name": "delete-native-structure-column",
              "vhost": "symphony",
              "durable": true,
              "auto_delete": false,
              "arguments": {}
            }
          ],
          "bindings": [
            {
              "source": "composer.source",
              "vhost": "symphony",
              "destination": "create-native-structure",
              "destination_type": "queue",
              "routing_key": "source.created",
              "arguments": {}
            },
            {
              "source": "composer.source",
              "vhost": "symphony",
              "destination": "update-native-structure",
              "destination_type": "queue",
              "routing_key": "source.updated",
              "arguments": {}
            },
            {
              "source": "composer.source",
              "vhost": "symphony",
              "destination": "delete-native-structure",
              "destination_type": "queue",
              "routing_key": "source.deleted",
              "arguments": {}
            },
            {
              "source": "composer.source",
              "vhost": "symphony",
              "destination": "create-native-structure-column",
              "destination_type": "queue",
              "routing_key": "source.field.created",
              "arguments": {}
            },
            {
              "source": "composer.source",
              "vhost": "symphony",
              "destination": "update-native-structure-column",
              "destination_type": "queue",
              "routing_key": "source.field.updated",
              "arguments": {}
            },
            {
              "source": "composer.source",
              "vhost": "symphony",
              "destination": "delete-native-structure-column",
              "destination_type": "queue",
              "routing_key": "source.field.deleted",
              "arguments": {}
            }
          ]
        }
  loadDefinition:
    enabled: true
    existingSecret: load-definition
  extraConfiguration: |
    default_vhost = symphony
    load_definitions = /app/load_definition.json

Ingress Updates

Modify the ingress section by defining the URL from Step 2, and uncomment any lines until your file matches the commands indicated below.

ingress:
  enabled: true

  appendToPath: ""

  annotations: 
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/proxy-http-version: "1.1"
    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: /
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "86400"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "86400"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "86400"
    nginx.ingress.kubernetes.io/proxy-body-size: "500m"
  hosts:
    - host: <fully-qualified-domain-name>
    paths: 
      - /
		

You must enable sticky sessions for a load balanced implementation of the managed service in Logi Symphony. This example includes 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/proxy-http-version: "1.1"
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "symphonyroute"
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
    nginx.ingress.kubernetes.io/session-cookie-path: /
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "86400"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "86400"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "86400"
    nginx.ingress.kubernetes.io/proxy-body-size: "500m"
    nginx.ingress.kubernetes.io/server-snippet: |
      gzip on;
      gzip_types = text/plain image/svg+xml application/xml text/css application/javascript application/json "application/json;charset=utf-8" application/font-woff;

Alternatively, deploy a redis subchart:

managed:
  dundas: 
    bi: 
      # Dundas BI Cache Provider
      cache: 
        # It is also possible to use a cache provider outside of the helm chart, and is the recommended way for Production.
        redis: 
          # Enables a Redis subchart.  See the Redis subsection for more helm values.
          enabled: true
        
            # If password is empty a random one will be chosen.
            password: ""

SSL Set Up

Use an ingress to enable SSL with the Symphony Helm chart. First create a secret with your certificate information.

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

Next, apply that secret to the ingress inside the tls.

ingress:
  ...
  hosts:
    - host: exampledomain.com
      paths: 
        - /

End readme version of instructions

Step 5: Install Logi Symphony

With the previous steps completed, run the following command:

helm install logisymphony1 insightsoftware/logisymphony -f values.yaml

This installs Symphony. When it starts, proceed to the next step.

Step 6: Get the Pods for Your Namespace

Run this command to return a list of all pods running.

kubectl get pods -A