Configuration

This page contains information about configuring a Rasa X / Enterprise deployment installed using rasactl.

Configuring Values in a Deployment#

You can start a deployment with a predefined configuration by using the --values-file flag to pass a file with configuration, e.g. rasactl start --values-file values.yaml.

Configurable Values#

rasactl uses the Rasa X Helm chart to deploy Rasa X. Therefore the same values that apply to a Helm chart installation apply to a rasactl installation.

Applying Changes#

To change values for an existing Rasa X deployment:

1. Set the relevant values in values.yml.

2. Upgrade the deployment:

   Copy

   rasactl upgrade --values-file values.yml

   If you have multiple deployments, specify the deployment that you want to customize:

   Copy

   rasactl upgrade deployment-name --values-file values.yml

To list all available deployments use the rasactl list command.

Common Customizations#

Use a Specific Rasa X / Enterprise Version#

You can configure a Rasa X deployment to use a specific Rasa X version.

1. Create a values.yaml file with the following content:

   Copy

   rasax:

   tag: "1.1.0"

   eventService:

   tag: "1.1.0"

   dbMigrationService:

   tag: "1.1.0"

2. Apply the values to the deployment:

   Copy

   rasactl upgrade --values-file values.yml

Deploy Rasa X with a Defined Password#

By default, the password for a Rasa X user (the admin user) is rasaxlocal.

You can use the --rasa-x-password flag to defined the user password while creating a new deployment.

You can use the --rasa-x-password-stdin flag if you want to read the password from STDIN.

Enable TLS#

Requirements#

• Your deployment must be available at a hostname (not a bare IP address). If you started your deployment using rasactl start on your local machine, you can use the URL returned by rasactl status. If you use a VM with a dynamic external IP address, use a static one to avoid IP addresses rotation and assign a hostname to it.
• You deployment must be accessible on ports 80 and 443.

Steps#

1. Install cert-manager via helm.

   Copy

   helm repo add jetstack https://charts.jetstack.io

   helm repo update

   helm install \

   cert-manager jetstack/cert-manager \

   --namespace cert-manager \

   --create-namespace \

   --version v1.5.3 \

   --set installCRDs=true

2. Create a Basic ACME Issuer.

   You will need to create a cluster-issuer.yaml file that contains a specification for the cluster issuer. In the example below Let's Encrypt is used as the certificate issuer.

   Copy

   apiVersion: cert-manager.io/v1

   kind: ClusterIssuer

   metadata:

   name: letsencrypt

   spec:

   acme:

   # You must replace this email address with your own.

   # Let's Encrypt will use this to contact you about expiring

   # certificates, and issues related to your account.

   email: user@example.com

   server: https://acme-v02.api.letsencrypt.org/directory

   privateKeySecretRef:

   # Secret resource that will be used to store the account's private key.

   name: example-issuer-account-key

   # Add a single challenge solver, HTTP01 using nginx

   solvers:

   - http01:

   ingress:

   class: nginx

   Then create the ClusterIssuer resource:

   Copy

   kubectl create -f cluster-issuer.yaml

3. Configure your Rasa X / Enterprise deployment

   You will need to upgrade your deployment so that a new TLS certificate can be issued for your domain.

   First, update your deployments values to include configuration for an Ingress resource.

   Copy

   ingress:

   enabled: true

   annotations:

   # add an annotation indicating the issuer to use.

   cert-manager.io/cluster-issuer: letsencrypt

   hosts:

   - host: your-domain.com

   paths:

   - /

   tls:

   # a secret name that is created automatically by cert-manager

   - secretName: rasa-x-tls

   hosts:

   - your-domain.com

   # Disable NGINX which is not needed longer.

   nginx:

   enabled: false

   Then apply the changes by upgrading your deployment:

   Copy

   rasactl upgrade --values-file values.yaml

After the configuration is applied, you should be able to access your deployment over HTTPS. You can execute the rasactl status command to check a URL and if HTTPS is enabled.

Share your bot running locally#

To share your bot you’ll need to make your locally running Rasa X server available to external traffic. You can do this using ngrok.

You can download and install ngrok for free. Once it is installed, open a new terminal window and run:

1. Determine URL for your deployment by executing the rasactl status command.

2. Run ngrok.

This will create a public HTTPS url for your locally running Rasa X server, given that it is running at the default port (if not, change the command above).

You should see something like this:

To share your bot, replace the http://inspiring-albattani.rasactl.localhost portion of your Share your Bot link with the https forwarding address from ngrok. Your link should then look something like this: https://3c3f-2a02-2454-25a-d700-5147-7d98-d4c4-e178.eu.ngrok.io/guest/conversations/production/29fbd34c2a06481f . From there you can follow the instructions for sharing your bot as usual.

Keep in mind that ngrok has limits on free usage and this is not a production set up.

Accessing Secrets#

This section describes how to retrieve secrets from your running deployment. The following secrets are created by default

To view the plaintext value of a secret, run the following, replacing <your deployment name> and <your release name> with your deployment and the name of your release:

For example, if you want to see the value of the redis secret for a release called rasa-x in the local namespace:

Next Steps#

• Deploy Rasa Open Source.
• Connect Rasa Open Source Deployment.