Version: Latest

Deploy Rasa Pro Services

This page explains how to deploy the Rasa Pro Services container using the Rasa Pro Helm chart.

Rasa Pro Services Setup

Installing Rasa Pro Services requires the deployment of a docker container. The container can be deployed in a different environment than Rasa Pro. Both deployments need to be able to connect to the same Kafka cluster to communicate.

Prerequisites

A Rasa Pro Services deployment needs to be connected to

  • Kafka event broker
  • a data warehouse (e.g. PostgreSQL).

The Kafka deployment should be a production deployment. We recommend a managed deployment, e.g. using Amazon Managed Streaming for Apache Kafka.

System Requirements

The minimum hardware requirements include information about the requirements you need to install and use Rasa Pro Services. Hardware requirements are dependent on the average number of conversations and expected workload. Your exact needs may be more, depending on your workload.

The following is the recommended minimum hardware guidance:

  • CPU: 2 vCPU
  • Memory: 4 GB
  • Disk space: 10 GB

These requirements correspond to the t3.medium instance type on AWS.

License

Running Rasa Pro Services requires a valid license. You need to supply the license as an environment variable to the service.

Deploy using Rasa Pro Helm Chart

Prerequisites

Rasa Pro needs to be configured to stream data to Kafka.

The configuration for Kafka should be in the rasa.settings.endpoints.eventBroker portion of the values.yml you used to deploy Rasa Pro. It will look like the example below:

rasa:
settings:
endpoints:
eventBroker:
enabled: true
type: kafka
security_protocol: SASL_SSL
sasl_mechanism: SCRAM-SHA-512
topic: rasa-assistant
url: <KAFKA-BROKER-URL>
sasl_username: <KAFKA-USERNAME>
sasl_password: <KAFKA-PASSWORD>
ssl_check_hostname: true
ssl_cafile: /app/CAroot.pem

Configuration examples for different security protocols and other parameters can be found in the Kafka Event Broker documentation.

Image pull secret

The Rasa Pro Docker image is named rasa-pro. The Docker images are hosted on our GCP Artifact Registry so authenticaiton is required to pull the image.

To enable the Kubernetes cluster to pull the image, an image pull secret must be defined, using the service account key file provided by Rasa:

kubectl create secret docker-registry artifact-registry \
--docker-server=https://europe-west3-docker.pkg.dev \
--docker-email=customer@rasa-releases.iam.gserviceaccount.com \
--docker-username=_json_key \
--docker-password="$(cat <file-path-to-json-key-file>)"

You will use this image pull secret in the values.yml to deploy Rasa Pro Services in the next step.

Update values.yml

Specify image pull secret and license

Specify the image pull secret and Rasa Pro License in your values.yml like below:

# -- imagePullSecrets is used for private repository pull secrets
imagePullSecrets:
- name: artifact-registry
# -- rasaProLicence is license key for Rasa Pro Services.
rasaProLicence:
# name of kubernetes secret
secretName: rasapro-license
secretKey: licensekey

Enable Rasa Pro Services

Enable Rasa Pro Services using the Rasa Pro Helm Chart by updating your values.yml like below:

rasaProServices:
enabled: true
image:
repository: "europe-west3-docker.pkg.dev/rasa-releases/rasa-pro/rasa-pro-services"
# specify version in image tag
tag: "3.2.0-latest"

Configuration through environment variables

Using environment variables, configure Rasa Pro Services to consume from the Kafka topic that Rasa Pro is publishing events to. The configurations should be be added to rasaProServices.environmentVariables in your values.yml.

Connecting to a secured Kafka instance

The connection to a secured Kafka instance can be configured by setting the following environment variables on the Rasa Pro docker container: KAFKA_SASL_MECHANISM, KAFKA_SASL_USERNAME, KAFKA_SASL_PASSWORD and KAFKA_SECURITY_PROTOCOL. Using Kafka truststores and keystores is currently not supported.

Configure using a Kubernetes secret

To use a Kubernetes secret for the environment variable, you can specify it using secret like this example below:

RASA_ANALYTICS_DB_URL:
# this uses a kubernetes secret
secret:
name: analytics-db-url
key: dburl

The Rasa Pro Services part of your values.yml will look like the example below:

rasaProServices:
enabled: true
image:
repository: "europe-west3-docker.pkg.dev/rasa-releases/rasa-pro/rasa-pro-services"
# specify version in image tag
tag: "3.2.0-latest"
environmentVariables:
# Address of the Kafka broker.
KAFKA_BROKER_ADDRESS:
value: <KAFKA-BROKER-URL>
# Topic Rasa Pro publishes events to and Rasa Pro consumes from
KAFKA_TOPIC:
value: rasa-assistant
# URL of the data lake to store analytics data in
RASA_ANALYTICS_DB_URL:
# this uses a kubernetes secret
secret:
name: analytics-db-url
key: dburl
# Security protocol to use for communication with Kafka
KAFKA_SECURITY_PROTOCOL:
value: SASL_SSL
# SASL mechanism to use for authentication.
KAFKA_SASL_MECHANISM:
value: SCRAM-SHA-512
# Username for SASL authentication.
KAFKA_SASL_USERNAME:
secret:
name: kafka-secrets
key: username
# Password for SASL authentication
KAFKA_SASL_PASSWORD:
secret:
name: kafka-secrets
key: password
# Filepath for SSL CA Certificate that will be used to connect with Kafka
KAFKA_SSL_CA_LOCATION:
value: /app/CAroot.pem

Deploy with Helm

To update the helm deployment, you can use:

helm upgrade \
--namespace <your namespace> \
--values values.yml \
<release name> \
rasa-<version>.tgz

Healthcheck Endpoint

Rasa Pro Services exposes a health check endpoint at /healthcheck. The endpoint will return a 200 status code if the service is healthy. If any other status code is returned or if the endpoint is not reachable the service is unhealthy.

Example response for /healthcheck:

{
"details": {
"analytics-consumer": {
"alive": 1,
"isHealthy": true
}
},
"isHealthy": true
}

Upgrading Versions

To upgrade to the latest version of Rasa Pro Services, you must follow these steps:

  1. Read the changelog documentation on breaking changes.
  2. Download a new docker container and run it.
Container Start-up

Note that the container might take some time to start-up as it is running database schema migrations as part of its start-up.

If the migrations have failed, the container will be shut down.