Customize Your Deployment

This page contains information about customizing Rasa X.

Making Changes to the Deployment#

If you want to change values for an installed Rasa X deployment, please follow these steps.

Adding a Custom Action Server#

1. 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.

2. 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.

   Copy

   # app (custom action server) specific settings

   app:

   # name of the custom action server image to use

   name: "<name of your action server image>"

   # tag refers to the custom action server image tag

   tag: "<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#

1. Create a secret for your private registry. You can do so by following the Kubernetes or OpenShift guide.

2. Add the name of the created secret to your values.yml file.

   Copy

   # images: Settings for the images

   images:

   # imagePullSecrets which are required to pull images for private registries

   imagePullSecrets:

   - name: <name of your pull secret>

The secret has to be created before you deploy Rasa X. If you use rasactl to create a deployment, you can define a namespace with the secret as an argument in CLI, e.g. the secret has been created in the my-namespace namespace, then use the rasactl start my-namespace command to create Rasa X deployment.

Create / Update Rasa X Users#

1. Get the name of the Rasa X pod:

rasa-rasa-x-6dcf57bb45-jnt4f is in our case the name of the Rasa X container.

2. Connect to the shell of this pod:

3. Rasa Enterprise only: Run the following command to create a new user. Please see Role-Based Access Control for available default roles.

   Copy

   python scripts/manage_users.py create <username> <password> <role>

4. To update the password of an existing user (by default, the username for the single Rasa X user is admin and its role is admin) run the following command:

   Copy

   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.

1. Specify the name of your secret in the values.yml:

   Copy

   rasaSecret: "<name of your secret>"

2. Create a yaml file <secret-filename>.yml which contains the following entries (make sure to replace the <your value> entries):

   Copy

   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 }}

3. Create the secret on the cluster by running this command:

4. 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.

Deploying to a Subpath#

By default, Rasa X assumes it is being served at the root of the host. To serve it at a subpath, e.g. "/rasa-x", you will need to:

1) set the environmental variable ROOT_URL in the rasa-x pod to the full URL you want Rasa X to be served at e.g.:

2) configure Nginx/your ingress (depending on which you're using) to use the correct subpath. For Nginx, you will need to create a customized version of rasax.nginx.template that includes the subpath everywhere in the server definition. See the instructions for configuring Nginx.

Configuring Nginx#

If you are using Nginx and you need to customize it's configuration to e.g. serve Rasa X at a subpath or enable SSL, you will need to create a custom config map.

Your configmap should include at least the keys nginx.conf, ssl.conf, and rasax.nginx.template. If you include additional keys for other configuration templates, you need to specify the paths to which to mount these files under nginx.extraVolumeMounts. The standard versions of nginx.conf, ssl.conf, and rasax.nginx.template can be found here. Assuming your customized versions of these files are in the directory ./custom-nginx-conf-files, you can create a custom configmap as follows:

To use your custom configmap, specify its name in your values:

The configmap has to be created before you deploy Rasa X. If you use rasactl to create a deployment, you can define a namespace with the secret as an argument in CLI, e.g. the secret has been created in the my-namespace namespace, then use the rasactl start my-namespace command to create Rasa X deployment.

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:

Deploying to a Subpath#

By default, Rasa X assumes it is being served at the root of the host. To serve it at a subpath, e.g. "/rasa-x", you will need to

Use the following configuration in your values.yaml to define a Subpath.

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.

1. 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 the DB_DATABASE environment variable (read more in Environment Variables).

2. 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:

   Copy

   FROM rasa/rasa-x:1.0.1

   # Switch to root user to install packages

   USER root

   RUN 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 drivers

   RUN pip install cx-Oracle

   # Install Oracle client libraries

   RUN alien -i oracle.rpm

   USER 1001

   Then build the Docker image:

   docker build . -t rasa/rasa-x:1.0.1-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:

   Copy

   DB_USER="<user>" # username used for authentication

   DB_PASSWORD="<password>" # password used for authentication

   DB_DATABASE= "rasa" # path to your db

   DB_DRIVER="oracle+cx_oracle"

   DB_PORT="<port of db>" # Port of your SQL server

   DB_HOST="<host of db>" # host of your Oracle server

   DB_QUERY="<query>" # optional dictionary to be added as a query string to the connection URL

   Alternatively, you can also directly pass the database connection URL to the container, by defining the DB_URL variable:

   Copy

   DB_URL="oracle+cx_oracle://user:password@your.database.com:<port>/<database name>"

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:

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.

Rasa Variables

These variables define the behavior of the Rasa containers and how the other services connect to them.

Rasa X API Variables

These variables define the behavior of the Rasa X API and how the other services connect to it.

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.

DB Variables

These variables define the credentials for the PostgreSQL database and configure how other services connect to it.

Redis Variables

These variables define the behavior of the Redis lock store and how other services connect to it.

Duckling Variables

These variables define the behavior of the Duckling service.