notice
This is documentation for Rasa X Documentation v0.35.x, which is no longer actively maintained.
For up-to-date documentation, see the latest version (1.1.x).
Customize Your Deployment
This page contains information about customizing Rasa X.
Server Quick-Install
You can customize the quick-install script using the environment variables listed below. To apply the settings to a new or an existing deployment, simply (re)run the installation command.
E.g. to configure the Rasa X user password, do the following:
Available Settings:
INITIAL_USER_PASSWORD
(generated by default): The password to log into Rasa X.ACTION_SERVER_IMAGE
(default: an empty placeholder image): The image which runs your custom actions server (if you don’t have one yet, see Building an Action Server Image).ACTION_SERVER_TAG
(default:""
): The tag of your action server image.ADDITIONAL_CHANNEL_CREDENTIALS
: Messaging and voice channels which can be used to send messages to Rasa Open Source. Examples:REST:
export ADDITIONAL_CHANNEL_CREDENTIALS="rest=''"Facebook:
export ADDITIONAL_CHANNEL_CREDENTIALS='facebook.verify="rasa-bit",facebook.secret="secret",facebook.page-access-token="token"'
RASA_X_VERSION
(default: 0.35.3): Version of Rasa X to install. Don't forget to specify the Rasa Open Source version too using the `RASA_VERSION` variable.
RASA_VERSION
(default: currently latest version): Version of Rasa Open Source to install.DEBUG_MODE
(default:false
): Runs the deployment in debug mode which provides more information to debug the deployment in case of problems.ENABLE_DUCKLING
(default:False
): Define if the deployment should include Duckling.
note
The Quick-Install script provides a quick deployment to get started. It provides only essential customization options. If you want to have more control over the deployment, you can use the Rasa X Helm Chart directly.
Helm Chart
Making Changes to the Deployment
If you want to change values for an installed Rasa X deployment, please follow these steps.
To modify the parameters of an existing deployment, set the relevant values in your
values.yml
.Get the release name which Helm used during the installation. If are unsure which release name was used, use the following command to find out the release name:
helm list --namespace <your namespace>Upgrade the deployment
helm repo updatehelm upgrade \--values values.yml \--namespace <your namespace> \--reuse-values \<your release name> rasa-x/rasa-x
Adding a Custom Action Server
To use a custom action server you need to build a Docker image for your action server. Please see Building an Action Server Image for more information on how to build an image and deploy it to a registry.
Add the image and tag you want to use to the
values.yml
. If your image is stored in a private registry, please refer to this guide in order to see how to add image pull secrets to your deployment.# app (custom action server) specific settingsapp:# name of the custom action server image to usename: "<name of your action server image>"# tag refers to the custom action server image tagtag: "<tag of your image>"
Configuring Rasa Open Source Channels
To configure the
messaging and voice channels
which the Rasa container should use, put the content of your credentials.yml
in the
values.yml
as done in this example:
Adding Environment Variables
To add extra environment variables to your containers, add the
environment variable to an extraEnvs
array on the service in your values.yml
. These
values can be provided directly or refer to secrets.
The extraEnvs
parameter is available for the rasa
, rasax
, eventService
, and app
services.
For example:
To add environment variables to the postgres
, rabbit
, or redis
services,
see Configuring the Subcharts.
Adding Image Pull Secrets for Private Registries
Create a secret for your private registry. You can do so by following the Kubernetes or OpenShift guide.
Add the name of the created secret to your
values.yml
file.# images: Settings for the imagesimages:# imagePullSecrets which are required to pull images for private registriesimagePullSecrets:- name: <name of your pull secret>
Create / Update Rasa X Users
- Get the name of the Rasa X pod:
- Kubernetes
- OpenShift
rasa-rasa-x-6dcf57bb45-jnt4f
is in our case the name of the Rasa X container.
- Connect to the shell of this pod:
- Kubernetes
- OpenShift
Rasa Enterprise only: Run the following command to create a new user. Please see Role-Based Access Control for available default roles.
python scripts/manage_users.py create <username> <password> <role>To update the password of an existing user (the username for the single Rasa X user is
me
and the role isadmin
) run the following command:python scripts/manage_users.py create --update <username> <password> <role>
Debug Mode
Sometimes it’s helpful to have more log messages in the Rasa pods. To activate the
debug mode for all Rasa Open Source and Rasa X related pods, use the following
configuration in your values.yml
:
Specifying Volume Sizes
Rasa X requires two volume claims: one for Rasa X, and one for the database.
You can define the claim sizes by setting the size
of these services in your
override file:
Using an External Secret
By default, the Helm chart will use the passwords specified in the values.yml
and
expose them within the cluster as a
secret.
You can also provide your own secrets instead of having the Helm chart generate them for you. This section shows you how to create an external secret using the example of the secret which is used for the Rasa components (this does not include components like the database). To see the required structure for secrets used by the subcharts, please follow the documentation of the subcharts. You can find the necessary links in the values.yml of the Rasa X Helm chart.
Specify the name of your secret in the
values.yml
:rasaSecret: "<name of your secret>"Create a yaml file
<secret-filename>.yml
which contains the following entries (make sure to replace the<your value>
entries):apiVersion: "v1"kind: "Secret"metadata:name: "<name of your secret>"type: "Opaque"data:initialPassword: {{ .Values.rasax.initialUser.password | b64enc | quote }}rasaToken: {{ <your value> | b64enc | quote }}rasaXToken: {{ <your value>| b64enc | quote }}passwordSalt: {{ <your value> | b64enc | quote }}jwtSecret: {{<your value> | b64enc | quote }}Create the secret on the cluster by running this command:
- Kubernetes
- OpenShift
- Then deploy the Rasa X chart. The components will then use the provided external secrets.
Using HTTPS
We recommend that you enable HTTPS on your server by adding SSL certificates (for example using Let’s encrypt).
The recommended way of doing it is to enable SSL on either the ingress controller or the load balancer serving the ingress. Please refer to the documentation of your cloud provider / ingress controller.
You can also configure the Nginx reverse proxy in the chart to use SSL. To do so, you
need a PEM-encoded private key file (privkey.pem
) and a PEM-encoded certificate
chain file (fullchain.pem
). Provide their content in a secret, which looks like the
following:
Then specify the name of this secret in your override file:
This will automatically be mounted in the correct place within the Nginx pod.
Configuring the Subcharts
Rasa X builds on existing charts for postgresql
, rabbitmq
, and redis
. To
see all configuration values please check the READMEs of the subcharts. The Rasa X chart
contains a link to the used chart versions and their READMEs in its
values file.
If you don’t want to use the subcharts and decide to provide your own deployments, you
can disable the subchart usage through the Rasa X values file. E.g. to skip installing
the postgresql
subchart specify this in your override file:
Additionally you have to provide the connection details of your external instances and
the required credentials. For postgresql
this would e.g. be:
Docker Compose
Connecting a Custom Action Server
If you don’t yet have an image for your custom action server, follow the instructions in Building an Action Server Image to build your image and push it to a container registry.
Replace the default
app
image with the image of your custom action server:To avoid your changes in the docker-compose file being overwritten when you update versions, you should not apply your changes to
docker-compose.yml
. Instead, create a new file calleddocker-compose.override.yml
inside your/etc/rasa
directory and apply your changes there. Docker will automatically take that file into account and override any attributes indocker-compose.yml
with changes from the override file.The contents of
docker-compose.override.yml
might look like this:version: '3.4'services:app:image: <image:tag>If your Docker containers are already running, take them down and then start Rasa X again:
cd /etc/rasasudo docker-compose downsudo docker-compose up -d
Securing with SSL
You can secure your server with SSL certificates of your choice.
For example, you can use Let’s Encrypt - a free, automated, and open Certificate Authority. It uses an Automatic Certificate Management Environment (ACME) protocol. You can learn more about it on the Getting Started page.
There are many ACME Clients Implementations, for different shell environments and different programming languages.
As an example, we use these ACME clients to generate the SSL certificates:
- Linux
- Windows PowerShell
Requirements:
A notification email address (used by Let’s Encrypt to notify about urgent renewal and security notices)
A domain name for the installation (in this example we use
rasa.example.com
) – you will not be able to set up SSL with a bare IP address without DNS
All of these instructions should be followed on the server.
- Linux
- Windows PowerShell
Install the ACME client:
Certbot installation instructions for Ubuntu 18.04 LTS
Certbot offers multiple ways to obtain a certificate. Let’s pick the
temporary webserver
option since it doesn’t require any additional
configuration.
If your Rasa-X server is already running, first bring it down:
Then run the following to start the interactive process to obtain the SSL certificate:
It’ll first ask you to pick the authentication method:
Here, pick 1
and press return.
Then, fill in the aforementioned email address:
Then, accept the Terms of Services and decide if you’d like to share your email address with the EFF:
In the last step you’re providing your domain name:
After that finished successfully, you’ll see a message similar to the one below:
Your certificate has been generated and is now saved on the machine at
/etc/letsencrypt/live/rasa.example.com/
. Please run the following to copy
them over to the appropriate directory so that the docker container can access
them:
You can then bring your Rasa X server up again:
Let’s Encrypt certificates are short-lived, this means
they expire after 90 days. This means that you’ll have to renew them
on a regular basis. Thankfully this can be done with certbot
as well.
Run the following commands in order to renew your certificate (you should
automate this renewal process with a cron job).
:::note Be aware that the update process will introduce downtime.
:::
Configuring Databases
Rasa X is officially compatible with the following databases:
PostgreSQL
Oracle >= 11.0
By default, Rasa X uses PostgreSQL as a database. It can be configured to use an on-premise database or your own cloud provided database. Using Oracle as your Rasa X database instead of PostgreSQL also requires some additional setup (see below).
PostgreSQL
Please check out the Environment Variables for how to configure Rasa X to use a non-default PostgreSQL database.
Oracle
Using Oracle as your Rasa X database instead of PostgreSQL requires some additional setup, which we’ll go over here.
Database Setup
In your Oracle database, create an empty database called
rasa
and configure a user/password that has access to it. You can also use a database with a different name, as long as it is empty and you specify this in theDB_DATABASE
environment variable (read more in Environment Variables).Rasa X Configuration
Next you have to extend the Rasa X image to include the necessary drivers and clients. First download the Oracle Instant Client, rename it to
oracle.rpm
and store it in the directory from where you’ll be building the Docker image.Copy the following into a file called
Dockerfile
:# if using community edition, please replace with rasa-x-ceFROM gcr.io/rasa-platform/rasa-x-ee:0.35.3# Switch to root user to install packagesUSER rootRUN apt-get update -qq && apt-get install -y --no-install-recommends alien libaio1 && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*# Copy in oracle instaclient# [https://www.oracle.com/database/technologies/instant-client/linux-x86-64-downloads.html](https://www.oracle.com/database/technologies/instant-client/linux-x86-64-downloads.html)COPY oracle.rpm oracle.rpm# Install the Python wrapper library for the Oracle driversRUN pip install cx-Oracle# Install Oracle client librariesRUN alien -i oracle.rpmUSER 1001Then build the Docker image:
docker build . -t rasa/rasa-x:0.35.3-oracle
You can now use this image instead of the standard one, by replacing it in your
docker-compose.override.yml
file. You will also have to configure the following environment variables for Rasa X in order to connect to the database:DB_USER="<user>" # username used for authenticationDB_PASSWORD="<password>" # password used for authenticationDB_DATABASE= "rasa" # path to your dbDB_DRIVER="oracle+cx_oracle"DB_PORT="<port of db>" # Port of your SQL serverDB_HOST="<host of db>" # host of your Oracle serverDB_QUERY="<query>" # optional dictionary to be added as a query string to the connection URLAlternatively, you can also directly pass the database connection URL to the container, by defining the
DB_URL
variable:DB_URL="oracle+cx_oracle://user:password@your.database.com:<port>/<database name>":::note To use Oracle for the tracker store, please see the Rasa Open Source docs.
:::
Telemetry
Rasa X tracks a minimal amount of anonymized usage information (like how often the “Train” button is used) to help us improve Rasa X. None of your training data or conversations will ever be sent to Rasa. You can disable telemetry by sending the following API request:
note
Rasa Enterprise does not track any usage information.
Environment Variables
Global Environment Variables
This group of variables is mainly used by docker-compose. All the variables get interpolated when starting the services
with docker-compose up
and then are passed to services. It is possible to see the docker-compose.yml
file with the substituted variables by using docker-compose config
. These variables have no default
value and must be defined in the .env
file.
Variable | Description |
---|---|
RASA_X_VERSION | The version of Rasa X used by the Rasa X docker container. |
RASA_VERSION | The version of Rasa used by the Rasa docker containers. |
RASA_TOKEN | Authentication token for the Rasa service. This is used by other services to communicate with Rasa. |
RASA_X_TOKEN | Authentication token for the Rasa X service. This is used by other services to communicate with Rasa X. |
PASSWORD_SALT | Salt used to securely store the users passwords. |
JWT_SECRET | Symmetric JWT token for authentication protection of the Rasa API server. |
RABBITMQ_PASSWORD | Used by other services to access RabbitMQ. |
DB_PASSWORD | Used by other services to access the PostgreSQL database. |
REDIS_PASSWORD | Used by other services to access Redis. |
RASA_X_DEMO_VERSION | Custom action server version. Only required if using the demo app image. |
Rasa Variables
These variables define the behavior of the Rasa containers and how the other services connect to them.
Variable | Default Value | Description |
---|---|---|
RASA_TOKEN | No default, must be defined in .env | Authentication token for the Rasa service. This is used by other services to communicate with Rasa. |
RASA_MODEL_PULL_INTERVAL | 10 | How often to check for new models, in seconds |
RABBITMQ_QUEUE (rasa-production ) | rasa_production_events | Which Rabbit event queue to publish events to. |
DB_DATABASE (rasa-production ) | tracker | Which database table to use to access and store trackers. |
DB_DATABASE (rasa-worker ) | worker_tracker | Which database table to use to access and store trackers. |
POSTGRESQL_SCHEMA | No default | PostgreSQL track store database schema to access. By default, Rasa accesses the public schema. |
RASA_MODEL_SERVER | http://rasa-x:5002 /api/projects/default /models/tags/production | URL where to access stored models and store new ones. |
Rasa X API Variables
These variables define the behavior of the Rasa X API and how the other services connect to it.
Variable | Default Value | Description |
---|---|---|
RASA_X_HOST | "http://rasa-x:5002" | The URL of the Rasa X services. This is used by other services to connect to the Rasa X API. |
RASA_X_TOKEN | No default, must be defined in .env | The token used for authentication between other services and the Rasa X API. |
RASA_X_USERNAME (only for Rasa Enterprise) | admin | If RASA_X_PASSWORD is specified then the user with this username will be created automatically after Rasa X is started for the first time. |
RASA_X_PASSWORD | No default, must be defined in .env if you want user to be created | If specified, this user with username RASA_X_USERNAME will be created immediately after Rasa X is started for the first time. |
JWT_SECRET | No default, must be defined in .env | Symmetric JWT token for authentication protection of the Rasa API server. |
RASA_USER_APP | ""http://app:5055"" | URL of the custom action server. |
RASA_PRODUCTION_HOST | http://rasa-production:5005 | Host and port at which to find the rasa-production server. |
RASA_WORKER_HOST | "http://rasa-worker:5005" | Host and port at which to find the rasa-worker server. |
RASA_WORKER_TOKEN | Interpolated from RASA_TOKEN | Authentication token used to connect to the Rasa services. |
RASA_MODEL_DIR | /app/models | The directory in which models are stored on the Rasa X container. |
RABBITMQ_QUEUE | rasa_production_events | Which queue to read conversation events from. |
PASSWORD_SALT | No default, must be defined in .env | Salt used to securely store the users passwords. |
RASA_X_USER_ANALYTICS | 0 | Binary value specifying whether Rasa X UI users’ conversations should be included in conversation analytics in the analytics tab. (Rasa Enterprise only) |
SANIC_RESPONSE_TIMEOUT | 28800 | Number of seconds a request can run before Sanic generates a 503 response. |
SANIC_REQUEST_MAX_SIZE_IN_BYTES | 800000000 | Maximum size of requests sent to server. For uploading large models. |
SANIC_ACCESS_CONTROL_MAX_AGE | 1800 | Value (in seconds) to use for the Access-Control-Max-Age header in responses to preflight requests. |
RUN_EVENT_CONSUMER_AS_SEPARATE_SERVICE | "false" | Whether the event service is run as a separate service. If "false" , Rasa X will launch the event service automatically as a subprocess. |
JWT_PUBLIC_KEY_PATH | "/app/public_key" | Path where to store JWT authentication. |
JWT_PRIVATE_KEY_PATH | "/app/private_key" | Path where to store JWT authentication. |
JWT_EXPIRATION_TIME | 28800 | Expiration time in seconds for JWT tokens. |
DEBUG_MODE | "false" | Whether or not to turn on debug logs. |
LOG_LEVEL | "INFO" | Log level to use, overwritten by DEBUG_MODE if DEBUG_MODE variable is set. |
SAML_PATH | "/app/auth/saml" | Path at which to store SAML authentication (Rasa Enterprise). |
SAML_DEFAULT_ROLE | "tester" | Role to assign to SSO users upon first sign on (Rasa Enterprise). |
RASA_MODEL_DIR | "/app/models" | Directory where models are stored on the Rasa X container. |
CREDENTIALS_PATH | "/app/credentials.yml" | Path to credentials.yml in the Rasa X container. |
RASA_X_SSL_CERTIFICATE | None | Path to SSL certificate if running the rasa-x container on HTTPS. |
RASA_X_SSL_KEYFILE | None | Path to SSL keyfile if running the rasa-x container on HTTPS. |
RASA_X_SSL_PASSWORD | None | Path to SSL password if running the rasa-x container on HTTPS with a password-protected keyfile. |
DEFAULT_E2E_TESTS_DIR | "tests" | Directory where tests are saved on the Rasa X container. |
DEFAULT_E2E_TEST_FILE_PATH | "conversation_tests.md" | File inside DEFAULT_E2E_TESTS_DIR where end-to-end tests are saved by default on the Rasa X container. |
MAX_DUMPING_DELAY_IN_SECONDS | 60 | Training data changes are dumped to disk in a batches. This variable describes the maximum time in seconds after which changes are dumped to disk. |
POSTGRESQL_SCHEMA | No default | PostgreSQL database schema to access. By default, Rasa X accesses the public schema. |
note
Changing some of these variables requires changes in other containers; for example, if updating your endpoints path,
you should also add the new path (relative from the app
directory) to the start up command of your Rasa containers
with the --endpoints
flag.
RabbitMQ Variables
These variables define the behavior of RabbitMQ and how the other services connect to it. More information about RabbitMQ can be found in the RabbitMQ docs.
Variable | Default Value | Description |
---|---|---|
RABBITMQ_HOST | "rabbit" | Hostname of the container hosting RabbitMQ. |
RABBITMQ_USERNAME | "user" | Username used by other services to access RabbitMQ. |
RABBITMQ_PASSWORD | No default, must be defined in .env | Password used by other services to access RabbitMQ. |
RABBITMQ_DISK_FREE_LIMIT | "{mem_relative, 0.1}" | Disk free space limit of the partition on which RabbitMQ is storing data |
DB Variables
These variables define the credentials for the PostgreSQL database and configure how other services connect to it.
Variable | Default Value | Description |
---|---|---|
DB_HOST | "db" | Hostname of the container hosting the PostgreSQL database. |
DB_PORT | "5432" | Port used by other services to access the database. |
POSTGRESQL_USERNAME (DB_USER ) | "admin" | Username used by other services to access the database. |
POSTGRESQL_PASSWORD (DB_PASSWORD ) | No default, must be defined in .env | Password used by other services to access the database. |
DB_LOGIN_DB | "rasa" | Database connection used to create tracker database. |
POSTGRESQL_DATABASE (DB_DATABASE ) | "rasa" | Database used by other services to access the database. |
Redis Variables
These variables define the behavior of the Redis lock store and how other services connect to it.
Variable | Default Value | Description |
---|---|---|
REDIS_HOST | "redis" | Hostname of the container hosting Redis. |
REDIS_PORT | "6379" | Port used by other services to access Redis. |
REDIS_PASSWORD | No default, must be defined in .env | Password used by other services to access Redis. |
REDIS_DB | "1" | Database name used by other services to access Redis. |
Duckling Variables
These variables define the behavior of the Duckling service.
Variable | Default Value | Description |
---|---|---|
RASA_DUCKLING_HTTP_URL | "http://duckling:8000" | Used by other services to access Duckling. |