Deploy the Tenant Service

From Genesys Documentation
Revision as of 20:38, June 30, 2021 by Corinne.hicks@genesys.com (talk | contribs) (Published)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This topic is part of the manual Tenant Service Private Edition Guide for version Current of Genesys Multicloud CX Private Edition.

Learn how to deploy the Tenant Service.

Important
Make sure to review Before you begin for the full list of prerequisites required to deploy the Tenant Service.

For solution-level deployment information, see [[PrivateEdition/Current/PEGuide/GetStarted|]].

Deployment scenarios

More than one deployment scenario is supported, including single region, redundant and multi-region deployment, and multi-tenant deployment.

Single region/location/cluster

You deploy Tenant resources in a single Azure Kubernetes Service (AKS) cluster within the same or separate namespace (project) with the Voice platform. If shared resources are being deployed across all tenants, they must also be added to the same target namespace.

Before proceeding with the Tenant(s) deployment at a location, the following features are required:

  •   POD Monitor for all tenant pods
  •   FluentBit logging framework

The deployment must include the tenant-monitor module execution at a location, as described in tenant-monitor.

Single tenant

Basic deployment

Single-node deployment requires a single override file and one "tenant" module to deploy, with reference implementation described at Single service at one location.

Mandatory parameters for basic installation are:

  • tenant uuid (v4)
  • tenant nickname (becomes a Helm release name)
  • all backend parameters (along with all secrets that may be required based on these parameters)

To increase the number of nodes, adjust the node count parameter. For more information, see Scalability and redundancy parameters.

Upgrade

The upgrade can be performed by re-running deployment with the same mandatory parameters and adjusted version of tenant image(s) and Helm charts. The upgrade is performed automatically, one node at a time (if node count is > 1). The update of the tenant configuration may happen automatically upon upgrade of the primary node. Genesys recommends performing a backup of the backend database for a Tenant Service before upgrading.

Multiple tenants at one location

Basic deployment

Additional tenants can be deployed at the same location with following guidelines:

  • Each Tenant Service must have a unique tenant uuid, shortid, and nickname.
  • Each Tenant Service is deployed or upgraded and adjusted independently.

Multiple regions/locations/clusters

Basic deployment

In multi-regional/multi-location deployments, one region/location is considered "master" (from a tenant perspective) and includes the database backend with write capabilities. Other regions/locations have replicas of the database backend in read-only mode.  A Tenant Service at each location may be deployed to have one of its nodes running as master (write access to provisioning data via config API) or have all its nodes running only as replicas (read access to configuration).

Multi-regional deployments have to be done according to these steps (with pre-requisites already satisfied at each region/location):

  • If required, deploy the tenant-monitor module at a location planned as a master tenant node.
  • Complete basic deployment of a Tenant Service in the master region, including specification of DR parameters for master, as per Scalability and redundancy parameters.
  • Complete deployment of the database backend with replica of master database at location(s) where replica tenant nodes are expected to run, including provisioning of access keys/secrets to access local replica.
  • If required, deploy the tenant-monitor module at location(s) , where replicas are expected to run.
  • Complete basic tenant deployment for additional region(s) and specify DR parameters for a master region (see Scalability and redundancy parameters).

The same customization scenarios discussed for tenant nodes can be applied for each location independently.  

Upgrade

Can be performed by re-running deployment with the same mandatory parameters and adjusted  version of tenant image(s) and helm charts for every location. Update of tenant configuration may happen automatically upon upgrade of master node in master region. It is recommended to perform back up of the backend database for a Tenant Service before upgrading the master region.

Deploy the service

This section provides reference commands with key parameters that are required to complete each deployment step.

Prerequisite

Before proceeding with the Tenant Service deployment, ensure you have completed procedures in the Configure security section of this guide.


Location-specific deployment steps

tenant-monitor

Monitoring/logging shared configuration and infrastructure deployment:
helm upgrade --install --force --wait --timeout 600s -n voice  tenant-monitor https://<jfrog artifactory/helm location>/tenant-monitor-$TENANT_MANIFEST_VERSION.tgz  --username "$JFROG_USER" --password "$JFROG_PASSWORD"
To enable fluent bit logging and Prometheus monitoring, the following overrides can be used with tenant-monitor:
prometheus:
  podMonitor:
    create: "true"
 
fluent:
  enable: "true"
Enable Persistent Volume Claim to store tenant logs, then the following overrides can be used with tenant-monitor (logStorageClass must be provided by the infrastructure team):
tenant:
  logging:
    volume:
      enabled: "true"
      createSC: "false"
      createpvClaim: "true"
      logClaim: "tenant-logs-pvc"
      logClaimSize: "5Gi"
      logStorageClass: "azure-files"
      Storageprovisioner: "TBD OC provosioner"
      parameters: {}


Service-specific deployment steps

Single service at one location

A single-service deployment can be implemented with these sample parameters in tenant-node-values.yaml:
tenantid: 9350e2fc-a1dd-4c65-8d40-1f75a2e080dd
  
replicaCount: 1
pgdb:
  dbhost: "/opt/genesys/dbserver/dbserver"
  dbuser: "/opt/genesys/dbuser/dbuser"
  dbname: "/opt/genesys/dbname/dbname"
  pgpwdSecretName: "/opt/genesys/dbpassword/dbpassword"
  usesecret: "true"
    
pullSecrets: mycred
  
   
image:
  registry: <docker-repo>
  tag: <version of tenant service>
  
initcontianer:
  registry: <docker-repo>
  tag: <version of tenant service>
    
addonpulseinitcontainer:
  registry: <docker-repo>
  tag: <version of tenant service>
  enable: "true"
  pulsemode: "setup"  
  
rcsinitcontianer:
  enable: "true"
  registry: <docker-repo>
  tag: <version of roles service batch image>
  
    
resources:
  limits:
    cpu: "2"
    memory: 4Gi
  requests:
    cpu: "1"
    memory: 1Gi
  
containerSecurityContext:
  readOnlyRootFilesystem: false
  runAsNonRoot: true
  runAsUser: 500
  runAsGroup: 500
   
service:
  type: ClusterIP
  
  
tenant:
  serviceuser: "default"
  serviceuserpwd: "<random-password-string>"
  consul:
    acl:
      usetoken: "true"
      token: "/opt/genesys/consul-shared-secret/consul-consul-voice-token"    
       
  volumes: |
    - name: fluent-logs
      emptyDir: {}
    - name: tenants-fluent-bit-config
      configMap:
        name: tenants-fluent-bit-config
    - name: consul-shared-secret
      secret:
        secretName: consul-voice-token
    - name: dbserver
      secret:
        secretName: dbserver
    - name: dbname
      secret:
        secretName: dbname
    - name: dbuser
      secret:
        secretName: dbuser
    - name: dbpassword
      secret:
        secretName: dbpassword
    - name: redis-config-secret
      secret:
        defaultMode: 420
        secretName: redis-config-token
    - name: kafka-secrets
      secret:
        defaultMode: 420
        secretName: kafka-secrets-token      
    - name: redis-tenant-secret
      secret:
        defaultMode: 420
        secretName: redis-tenant-token
  
    
  volumeMounts: |
    - name: fluent-logs
      mountPath: "/opt/genesys/logs/JSON"
    - name: consul-shared-secret
      readOnly: true
      mountPath: "/opt/genesys/consul-shared-secret"    
    - name: dbserver
      readOnly: true
      mountPath: "/opt/genesys/dbserver"
    - name: dbname
      readOnly: true
      mountPath: "/opt/genesys/dbname" 
    - name: dbuser
      readOnly: true
      mountPath: "/opt/genesys/dbuser" 
    - name: dbpassword
      readOnly: true
      mountPath: "/opt/genesys/dbpassword" 
    - name: redis-config-secret
      readOnly: true
      mountPath: "/opt/genesys/redis-config-secret"
    - name: redis-tenant-secret
      readOnly: true
      mountPath: "/opt/genesys/redis-tenant-secret"
    - name: kafka-secrets
      readOnly: true
      mountPath: "/opt/genesys/kafka-secrets"
      
  
  initVolumeMounts: |
    - name: consul-shared-secret
      readOnly: true
      mountPath: "/opt/genesys/consul-shared-secret"       
    - name: dbserver
      readOnly: true
      mountPath: "/opt/genesys/dbserver"
    - name: dbname
      readOnly: true
      mountPath: "/opt/genesys/dbname" 
    - name: dbuser
      readOnly: true
      mountPath: "/opt/genesys/dbuser" 
    - name: dbpassword
      readOnly: true
      mountPath: "/opt/genesys/dbpassword"
  
       
gws:
  enabled: "false"
  
redis:
  enabled: "true"
  port: 6379
  isCluster: true
  usesecret: "true"
  usesecretenv: "false"
  redisCacheSecretName: "/opt/genesys/redis-config-secret/redis-config-state"
  redisTenantSecretName: "/opt/genesys/redis-tenant-secret/redis-tenant-stream"
  
kafka:
  enabled: "true"
  usesecret: "true"
  usesecretenv: "false"
  kafkaSecretName: "/opt/genesys/kafka-secrets/kafka-secrets"
 
serviceAccount:
  create: true
In addition, use the following deployment command:
helm upgrade --install --force --wait --timeout 600s -n voice -f ./tenant-node-values.yaml tenant<shortid> https://<jfrog artifactory/helm location>/tenant-<helm version>.tgz --username "$JFROG_USER" --password "$JFROG_PASSWORD"
Above deployment will create a Tenant with the password of the service account set up explicitly and without enabling GWS integration. See Samples and references for values that allow you to reset the Tenant password upon deployment using a pre-generated value from the secret and to enable automated GWS integration.

Deploy in OpenShift

Content coming soon

Samples and references

Enabling a service admin password (the secret should be created as described in the Service account password section): 

...
tenant:
  serviceuser: "default"
  svcpwdSecretName: "/opt/genesys/service-user-account/svcpassword"
  ...
  volumes: |
    - name: service-user-account
      secret:
           secretName: svcuseraccount
    ...
  volumeMounts: |
    - name: service-user-account
      readOnly: true
      mountPath: "/opt/genesys/service-user-account"   
    ....
  initVolumeMounts: |        
    - name: service-user-account
      readOnly: true
      mountPath: "/opt/genesys/service-user-account"   
    ....

Enabling GWS integration (the secret should be created as described in the Genesys Authentication backend secrets section): 

...
gws:
  enabled: "true"
  usesecret: "true"
  gwsuserSecretName: "/opt/genesys/gauth-client-id/clientid"
  gwspwdSecretName: "/opt/genesys/gauth-client-token/clientsecret"
 
tenant:
  ...
  volumes: |
    - name: gauth-client-id
      secret:
           secretName: gauthclientid
    - name: gauth-client-token
      secret:
           secretName: gauthclientsecret
    ....
  
  volumeMounts: |
    - name: gauth-client-id
      readOnly: true
      mountPath: "/opt/genesys/gauth-client-id/clientid"   
    - name: gauth-client-token
      readOnly: true
      mountPath: "/opt/genesys/gauth-client-token/clientsecret"   
    ....
  initVolumeMounts: |        
    - name: gauth-client-id
      readOnly: true
      mountPath: "/opt/genesys/gauth-client-id/clientid"   
    - name: gauth-client-token
      readOnly: true
      mountPath: "/opt/genesys/gauth-client-token/clientsecret"   
    ....

Mount Persistent Volume Claim to store Tenant logs, then add the following override values in tenant-node-values.yaml: 

.....
 
tenant:
  ...
  volumes: |
    ...
 
    - name: log
      persistentVolumeClaim:
        claimName: tenant-logs-pvc
 
    ...
 
  volumeMounts: |
    .....
 
    - mountPath: /opt/genesys/logs/volume
      name: log
    - mountPath: /logs
      name: log
 
    ......
 
  initVolumeMounts: |
    ........
 
    - mountPath: /opt/genesys/logs/volume
      name: log
    - mountPath: /logs
      name: log
 
 .....

Validate the deployment

Content coming soon
Retrieved from "https://all.docs.genesys.com/PrivateEdition/Current/TenantPEGuide/Deploy (2024-11-09 06:49:50)"
Comments or questions about this documentation? Contact us for support!