Docker-based Deployment

Follow this guide to install Hybrid Chat on Linux in a simplex or redundant fashion. 

Deployment Planning

Please make sure that Solution Prerequisites are met for the desired deployment type. 

For High Availability deployment, see the architecture and components on High Availability with Redundant Deployment. 

Installation Instructions

1. For installing 3.18.0 download script install-hybrid-chat-3.18.0.sh. To upgrade from 3.10.2 & later versions to 3.18.0, follow Upgrade Guide. 

2. Make the script executable.

   BASH

   $ chmod a+x install-hybrid-chat-3.18.0.sh

3. Start the execution of the script with the below-given command. 

   BASH

   $ ./install-hybrid-chat-3.18.0.sh

4. Deployment Option - Choose any of the following installation options.

   	Question	Possible Options
   1	Bot	If you do not already have a bot set up in your environment. It will setup: Rasa with Rasa X  After Rasa with RasaX is installed, open <install-dir>/sds/docker-compose-rasa-x.yml with any text editor and set the replicas value equal to the number of CPUs available in the host machine e.g. docker-compose-rasa-x.yml YML rasa-production: <<: *default-rasa-service environment: <<: *rasa-credentials RASA_ENVIRONMENT: "production" DB_DATABASE: "tracker" RASA_MODEL_SERVER: "http://rasa-x:5002/api/projects/default/models/tags/production" deploy: mode: replicated replicas: 8 Perform an Up operation for all the containers using efutils  Articulate  It's recommended to install the bot on a separate system because of its NLU component's resource utilization requirements.
   2	Hybrid-Chat	It will install the Hybrid Chat solution either in a simplex or redundant fashion. The script installs the solution either standalone or integrated with Cisco UCC. You can also specify external SQL Server credentials that may alter be integrated with Cisco CUIC for reporting.
   3	Integrate-bot	To integrate the Bot with Hybrid Chat. This requires Hybrid Chat and the Bot already installed.
   4	Customer gadget	To install the Customer widget on a web-server. This is usually installed in a DMZ for exposing customer widget from a public website.

5. Deployment Path

   Deployment Path	Default
   DEPLOYMENT_PATH	/var/lib/expertflow – This is the default path unless otherwise changed.

6. For HA deployment, consider the following: 

   	Considerations
   1	Load Balancer	Select this type of node when deploying the current system as a local load-balancer. The basic purpose of this machine is to provide a Layer4 routing between both sites ( master and slave).  Both Master and Slave nodes must be able to communicate with the Load-Balancer node to evolve application  and system load balancing
   2	Master	Select this type of node when deploying a master or active node in High availability mode. This system will be serving all the requests by default.
   3	Slave	Select this type of node when deploying a slave or passive node in High Availability mode. This system is configured for a takeover role when the Master system goes down.
   4	Arbiter	An optional node to be deployed at a neutral location
   5	ReplicaSet Name	Automatically setup during deployment
   6	Mongo Replica Set Configuration	No configuration required for MongoDB in 3.16.x. This process is now automated and doesn't require any additional steps.

7. Apply licenses by following this document.

General Administration

Use the utility efutils to perform routine operations such as up/down/restart services and docker profiles. For complete details, see efutils. 

Limitations

• Separate deployment of Customer-Gadget via deployment script is not functional. 

• In redundant deployment, component-level failover will not work. It means if any of the Hybrid Chat components is down you'll need to down the solution on the primary side and run takeover.sh from the secondary machine. 

  Down the solution on primary

  BASH

  $ efutils all down