Deploy Designer

This topic is part of the manual Designer Private Edition Guide for version Current of Designer.

Preparation

Important

Review the Before you begin topic for the full list of prerequisites required to deploy Designer.

Before you deploy Designer and DAS using Helm charts, complete the following preparatory steps:

Ensure the Helm client is installed.
Set up an Ingress Controller, if not already done.
Setup an NFS server, if not already done.
Create Persistent Volumes - a sample YAML file is provided in the Designer manifest package.
Download the Designer and DAS docker images and push to the local docker registry.
Download the Designer package and extract to the current working directory.
Configure Designer and DAS value overrides (designer-values.yaml and das-values.yaml); ensure the mandatory settings are configured. If the Blue-Green deployment process is used, Ingress settings are explained in the Blue-Green deployment section.

Important

Depending on the Kubernetes platform or the container orchestration platform that you are deploying Designer on, you might have to carry out some additional steps specific to that platform. For more information, navigate to the required topic in the Kubernetes platform specific information section on the About page.

Set up Ingress

Given below are the requirements to set up an Ingress for the Designer UI:

Cookie name - designer.session.
Header requirements - client IP & redirect, passthrough.
Session stickiness - enabled.
Allowlisting - optional.
TLS for ingress - optional (should be able to enable or disable TLS on the connection).

Set up Application Gateway (WAF) for Designer

Designer Ingress must be exposed to the internet using Application Gateway enabled with WAF.

When WAF is enabled, consider the following exception in the WAF rules for Designer:

Designer sends a JSON payload with data, for example, {profile . {} }. Sometimes, this is detected as OSFileAccessAttempt, which is a false positive detection. Disable this rule if you encounter a similar issue in your WAF setup.

Storage

Designer storage

Designer requires storage to store designer application workspaces. Designer storage is a shared file storage that will be used by the Designer and DAS services.

Important

This storage is critical. Ensure you take backups and snapshots at a regular interval, probably, each day.

A Zone-Redundant Storage system is required to replicate data from the RWX volumes and must be shared across multiple pods:

Capacity - 1 TiB
Tier - Premium
Baseline IO/s - 1424
Burst IO/s - 4000
Egress Rate - 121.4 MiBytes/s
Ingress Rate - 81.0 MiBytes/s

DAS storage

If the Designer workspace is stored in a cloud storage system such as Azure Files, then the data must be synced to the DAS pods using the Designer-Sync service. In this case, DAS must use the StatefulSet deployment type. In the DAS StatefulSet pods, each pod must be attached to a premium SSD disk to store the workspace.

Size - > 500GiB
Max IOPS (Max IOPS w/ bursting) - 2,300 (3,500)
Max throughput (Max throughput w/ bursting) - 150 MB/second (170 MB/second)

Permission considerations for Designer and DAS storage

NFS

For NFS RWX storages, the mount path should be owned by <code>genesys:genesys</code>, that is, <code>500:500</code> with <code>0777</code> permissions. It can be achieved by one of the below methods:

From the NFS server, execute the chmod -R 777 <export_path> and chown -R 500:500 <export_path> commands to set the required permissions.
Create a dummy Linux based pod that mounts the NFS storage. From the pod, execute the chmod -R 777 <mount_path> and chown -R 500:500 <mount_path> commands. This sets the required permissions. However, this method might require the Linux based pods to be run as privileged.

SMB / CIFS

For SMB / CIFS based RWX storages, for instance, Azure file share, the below <code>mountOptions</code> must be used in the StorageClass or the PersistentVolume template:

<code>mountOptions</code>

- dir_mode=0777
- file_mode=0777
- uid=500
- gid=500
- mfsymlinks
- cache=strict

Set up Secrets

Secrets are required by the Designer service to connect to GWS and Redis (if you are using them).

GWS Secrets:

GWS provides a Client ID and secrets to all clients that can be connected. You can create Secrets for the Designer client as specified in the Set up secrets for Designer section below.

Redis password:

If Designer is connected to Redis, you must provide the Redis password to Designer to authenticate the connection.

Set up Secrets for Designer

Use the designer.designerSecrets parameter in the values.yaml file and configure Secrets as follows:

designerSecrets:
  enabled: true
  secrets:
    DES_GWS_CLIENT_ID: xxxx
    DES_GWS_CLIENT_SECRET: xxxx
    DES_REDIS_PASSWORD: xxxxx

Deployment strategies

Designer supports the following deployment strategies:

Rolling Upgrade (default).
Blue-Green (recommended).

DAS (Designer Application Server) supports the following deployment strategies:

Rolling Upgrade (default).
Blue-Green (recommended).
Canary (must be used along with Blue-Green and is recommended in production).

Rolling Upgrade deployment

The rolling deployment is the standard default deployment to Kubernetes. It works slowly, one by one, replacing pods of the previous version of your application with pods of the new version without any cluster downtime. It is the default mechanism of upgrading for both Designer and DAS.

Designer

Initial deployment

To perform the initial deployment for a rolling upgrade in Designer, use the Helm command given below. The values.yaml file can be created as required.

helm upgrade --install designer -f designer-values.yaml designer-100.0.112+xxxx.tgz --set designer.image.tag=9.0.1xx.xx.xx