Connect a Rasa Deployment¶
Rasa X helps you improve your assistant by leveraging real conversations. If you’re already running a Rasa Open Source deployment, you can simply connect it to Rasa X to annotate conversations - even if it’s running on a separate system.
To achieve this, you have two options:
Import historical conversations from your Rasa Open Source deployment into Rasa X
Automatically forward all new incoming messages directly from Rasa Open Source to Rasa X
1. Import Existing Conversations from Rasa Open Source¶
In order to annotate conversations users have already had with a live Rasa Open Source deployment, you can import conversations from your current tracker store into Rasa X.
Rasa Open Source Configuration¶
Open the .env
file in your Rasa X installation directory (/etc/rasa
by
default) and make a note of the entry for RABBITMQ_PASSWORD
.
If you’ve deployed Rasa X in a cluster using Helm, Kubernetes or OpenShift, check out
Accessing Secrets.
Enable your RabbitMQ service to receive events from a different server by following Exposing the RabbitMQ Port. Make a note of the exposed IP address.
Now go to your Rasa Open Source deployment and note down the following values used in your Rasa tracker store: the database username, the database password and the name of the database.
On the same machine in a different directory, or an a different machine, create a new
file called endpoints.yml
(alternatively you
can go to your project directory in your Rasa Open Source deployment and modify the
existing endpoints.yml
there).
Have a look at Exposing the Database Port to make your database accessible from the outside world if you’re working on a different machine than your Rasa Open Source deployment.
In this file, create two sections defining the tracker store from which
to import conversations, as well as the event broker that’s used to move the
conversations from your Rasa Open Source deployment to Rasa X. You will forward
historical events in your Rasa Open Source deployment to the Rasa X
event broker.
RabbitMQ is used as the message broker for Rasa X, so we will use the
Pika
Python configuration in the Rasa endpoints.yml
.
Create the following two entries in endpoints.yml
:
tracker_store:
type: sql # other databases are supported
dialect: <if using SQL, your Rasa Open Source deployment's SQL dialect, e.g. "postgresql">
url: <URL of the database service in your Rasa Open Source deployment>
username: <tracker database username in your Rasa Open Source deployment>
password: <tracker database password in your Rasa Open Source deployment>
db: <name of the tracker database in your Rasa Open Source deployment>
event_broker:
type: "pika"
url: <URL of the exposed RabbitMQ service in your Rasa X deployment>
port: 5672 # change if your RabbitMQ service is exposed on a different port
username: "user" # if customized, value of the RABBITMQ_USERNAME environment variable
password: <value of RABBITMQ_PASSWORD>
queues:
- "rasa_production_events" # if using a custom queue, value of the RABBITMQ_QUEUE environment variable
Migrate Conversations¶
You can use Rasa’s rasa export
command-line tool to export conversations from the
tracker database to an event broker. From there, your running Rasa X deployment will
consume the events and save them to your Rasa X database.
Head to the same directory as your endpoints.yml
file from above. To export all
conversations contained in the tracker database, simply run
rasa export
The rasa export
command allows you to specify a subset of conversation IDs to
export, or restrict the time range of events. Just run rasa export --help
for an
overview of options, or check out the Rasa CLI docs on rasa export.
You can now log in to your Rasa X deployment and view the migrated conversations.
2. Connect a Live Rasa Open Source Deployment¶
This configuration allows Rasa X to monitor conversations taking place in the live Rasa Open Source deployment environment without modifying the deployment architecture.
These instructions assume Rasa Open Source and Rasa X are deployed and running on two separate systems.
Rasa X Configuration¶
Open the .env
file in your Rasa X installation directory (/etc/rasa
by
default) and make a note of the following values: RABBITMQ_PASSWORD
,
RABBITMQ_USERNAME
, RABBITMQ_QUEUE
. If you’ve deployed Rasa X in a cluster
using Helm, Kubernetes or OpenShift, check out Accessing Secrets. We
will need these when configuring the event broker on the Rasa Open Source server.
Read the section on Exposing the RabbitMQ Port in order to enable your RabbitMQ service to accept events.
Rasa Open Source Configuration¶
You need to configure your Rasa Open Source deployment to forward messages to the
Rasa X event broker. The configuration is done in the endpoints.yml
file
which can be found in the Rasa project directory. Configure the event_broker
section as described in Rasa Open Source Configuration (you do not need to modify the
tracker store section).
Once you’ve updated the endpoints.yml
file, restart the Rasa server.
If verbose logging is on using the --debug
option, you should see the
following messages in the Rasa logs indicating that messages are being forwarded to
Rasa X:
rasa-production_1 | 2020-01-13 13:18:17 DEBUG rasa.core.brokers.pika - RabbitMQ connection to 'rasax.mydomain.com' was established.
rasa-production_1 | 2020-01-13 13:20:52 DEBUG rasa.core.brokers.pika - Published Pika events to queue 'rasa_production_events' on host 'rasax.mydomain.com':
You can now log into Rasa X and view conversations from your users as they come in. For further information on what to do with them, check out Review Conversations and Improve Assistant.
Exposing the RabbitMQ Port¶
Before RabbitMQ can accept external events, you need to expose the port to the outside world. Depending on whether you’ve deployed Rasa X using the one-line deploy script or Docker Compose, read one of the following sections.
One-Line Deploy Script or Kubernetes/Openshift Deployment¶
Follow these instructions if you’ve deployed Rasa X using the one-line deploy script, or if you’ve taken the manual Kubernetes/Openshift deployment route.
First, find the namespace your deployment is running under. To list the available namespaces, run:
kubectl get namespaces
Now, find the name of your RabbitMQ service. Run the following command, looking for
an entry containing -rabbit
in the NAME
column:
kubectl get services -n <your namespace>
Expose the RabbitMQ service as a load balancer on port 5672 by running:
kubectl expose service <rabbit service> -n <namespace> --name rabbit-mq-load-balancer --type LoadBalancer --port 5672 --target-port 5672
Make sure the port was exposed by running the following command, checking for an
external IP address assigned to the rabbit-mq-load-balancer
service:
kubectl get services -n <your namespace>
Use the IP address listed under EXTERNAL-IP
in the event_broker
section of your
endpoints.yml
. Make sure that your cluster or VM firewall settings allow traffic
to port 5672.
Once you’re done importing historical conversations, or you no longer want to stream events to your Rasa X deployment, you can remove the RabbitMQ load balancer by running:
kubectl delete service rabbit-mq-load-balancer -n <namespace>
Docker Compose Deployment¶
If you’ve deployed Rasa X using Docker Compose, add the following block to
your docker-compose.override.yml
:
version: '3.4'
services:
rabbit:
ports:
- "5672:5672"
Now, restart the RabbitMQ service with the sudo docker-compose restart rabbit
command. Make sure you’ve allowed traffic to port 5672 in your VM firewall.
Exposing the Database Port¶
If you’re following the steps on importing historical conversations on a machine that’s different from where you’ve deployed Rasa Open Source, you need to make the database accessible from the outside world. How to open your database port depends highly on the way you deployed Rasa Open Source, but following similar steps as in Exposing the RabbitMQ Port is a good idea if you’ve deployed Rasa Open Source alongside a database container using Docker Compose or Kubernetes.