Version: 1.0.x

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:

    rasactl upgrade --values-file values.yml

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

    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:

    rasax:
    tag: "1.0.0"
    eventService:
    tag: "1.0.0"
    dbMigrationService:
    tag: "1.0.0"
  2. Apply the values to the deployment:

    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.

rasactl start --rasa-x-password my-password

Enable TLS

Requirements

  • Your deployment must be available at a domain (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 domain to it.
  • You deployment must be accessible on ports 80 and 433.

Steps

  1. Install cert-manager via helm.

    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.

    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:

    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.

    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:

    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.

$ rasactl status
Name: quirky-jang
Status: Running
URL: https://rasa-x.example.com
Version: 1.0.1
Enterprise: inactive
Rasa production version: 0.0.0
Rasa worker version: 0.0.0
Project path: not defined

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.
$ rasactl status
Name: inspiring-albattani
Status: Running
URL: http://inspiring-albattani.rasactl.localhost
Version: 1.0.1
Enterprise: inactive
Rasa production version: 0.0.0
Rasa worker version: 0.0.0
Project path: not defined
  1. Run ngrok.
ngrok http -host-header=inspiring-albattani.rasactl.localhost inspiring-albattani.rasactl.localhost

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

note

You can use the -region flag along with the ngrok http command to set region, default is us.

You should see something like this:

Session Status online
Session Expires 1 hour, 58 minutes
Version 2.3.40
Region Europe (eu)
Web Interface http://127.0.0.1:4040
Forwarding http://3c3f-2a02-2454-25a-d700-5147-7d98-d4c4-e178.eu.ngrok.io -> http://inspiring-albattani.rasactl.localhost:80
Forwarding https://3c3f-2a02-2454-25a-d700-5147-7d98-d4c4-e178.eu.ngrok.io -> http://inspiring-albattani.rasactl.localhost:80
Connections ttl opn rt1 rt5 p50 p90
18 5 0.14 0.05 0.18 16.03

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

descriptiondefault secret name
PostgreSQL database passwordpostgresql
Redis lock store and cache passwordredis
RabbitMQ event broker passwordrabbit

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:

secret=<secret name>
namespace=<your deployment name>
release_name=<your release name>
kubectl --namespace ${namespace} \
| get secret ${release_name}-${secret} -o yaml \
| awk -F ': ' '/password/{print $2}' | base64 -d

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

$ secret=redis
$ namespace=local
$ release_name=rasa-x
$ kubectl --namespace ${namespace} get secret ${release_name}-${secret} -o yaml \
| awk -F ': ' '/password/{print $2}'\
| base64 -d
redis-password
note

If you’re not sure what deployment name or release name your deployment runs under, you can use the following commands to find out. To list the available deployments, run:

rasactl list

And to list the releases under a particular deployment, run:

rasactl status <deployment-name> --details

The release name can be found in the Helm release field.

Next Steps