Microservices

Deploying Rocket.Chat using microservices enhances scalability and error handling in your workspace. By breaking down Rocket.Chat into targeted services, each component can efficiently manage its tasks, improving performance and ease of maintenance.

The official method for deploying Rocket.Chat microservices is with Kubernetes and Helm. Visit the Deploy with Kubernetes guide to gain essential background knowledge this deployment.

In this document, you'll learn:

• Key components of the Rocket.Chat microservice architecture

• How to configure microservices components in your Kubernetes deployment

• A step-by-step guide on deploying a workspace using Rocket.Chat microservices

Key components of Rocket.Chat microservices

Rocket.Chat’s microservices architecture consists of several components, each focusing on a specific feature. These components work together to form a fully operational Rocket.Chat workspace. Here are the key components:

• authorization (rocketchat/authorization-service): Manages role and permission validation, ensuring that users have the right access levels.

• nats (docker.io/nats): A messaging system that provides a scalable and highly available message bus for microservices communication. It acts as a message distributor, i.e., you point to the distributor instead of pointing to each component in the deployment resource. This determines the service to forward the requests.

  To learn more about NAT, see the official documentation.

• stream-hub ( rocketchat/stream-hub-service) : Functions as a message broker that provides a scalable and fault-tolerant message stream for Rocket.Chat. It receives real-time changes or data from MongoDB and sends it to all the services. The services can act on that change at their discretion.

• accounts (rocketchat/accounts-service): Manages user accounts and authentication.

• ddp-streamer (rocketchat/ddp-streamer-service): Handles all WebSocket connections using the Distributed Data Protocol (DDP).

• presence (rocketchat/presence-service): Manages user presence status.

• The central Rocket.Chat monolith (rocketchat/rocket.chat): Each component is disabled from this monolith, so each "service" can take over its respective functionalities.

Rocket.Chat's microservices deployment is illustrated in the diagram below. From a bare metal perspective, each component consists of one container.

Since each Rocket.Chat component is a container, you can pull them like any Docker image. While you can deploy Rocket.Chat with Docker or Docker Compose, this method is not officially supported. To deploy using Docker, you need to set up NATS and ensure you use a custom network to connect each related container. Refer to the official documentation to learn how to start NATS on your server.

Each container must be started with the MONGO_URL and TRANSPORTER environment variables set, pointing to the MongoDB database (using the full connection string) and the NATS gateway address, respectively. Additionally, all /sockjs and /websocket connections must be routed through a reverse proxy or load balancer, with the remainder going to the monolith.

It is essential to note that we do not support direct Docker/Compose microservices deployment. The only supported method currently is using Kubernetes with the official Helm chart.

Configuring the microservices component

The official supported method to deploy Rocket.Chat microservices is by using Kubernetes and Helm. Refer to the Deploy with Kubernetes guide for more details on our kubernetes deployment procedure.

To configure Rocket.Chat microservices in your Kubernetes deployment, enable microservices in the values.yaml configuration file.

microservices:
  enabled: true

By default, the Rocket.Chat Helm chart deploys a single monolith with a single instance. To deploy multiple replicas of the microservice, add the replicaCount as shown below:

replicaCount: 2

microservices:
  enabled: true

Alternatively, you can also set the desired number of replicas for any of the services as shown below:

microservices:
  enabled: true
  presence:
    replicas: 1
  ddpStreamer:
    replicas: 2
  account:
    replicas: 1
  authorization:
    replicas: 1
  streamHub:
    replicas: 1
  nats:
    replicas: 1

• ddp-streamer should be scaled from the beginning. Aim for one pod for every 500 concurrent users.

• stream-hub is the only service/component that can not be scaled and is limited to one pod for each deployment.

Set up ingress

This architecture requires an ingress controller. All WebSocket connections need to be sent directly to the ddp-streamer service. You can use any ingress controller, for example NGINX. To install an NGINX controller, follow this guide and update your values.yml file with the following configuration:

host: # the host to access your Rocket.Chat instance, omit the protocol

ingress:

  enabled: true

  ingressClassName: nginx

This configuration sets up the necessary ingress resource with the appropriate paths and backends. The ingressClassName is critical unless you have a default class set. Consult your ingress controller's documentation for specifics.

While NGINX is used as an example, any ingress controller can be employed. Ensure the ingressClassName is correctly configured or that the IngressClass resource is set to the default for your cluster, allowing the controller to manage Ingress resources without a specific class defined.

Deploying Rocket.Chat Microservices with Kubernetes and Helm

Before proceeding, refer to the Deploy with Kubernetes guide to set up the prerequisites and gain foundational knowledge on the Kubernetes deployment procedure.

Once you've confirmed that all prerequisites are met, continue with the following steps to deploy Rocket.Chat microservices using Kubernetes:

1. Add the chart repository

Add the Rocket.Chat helm chart repository by running the following command:

helm repo add rocketchat https://rocketchat.github.io/helm-charts

If successful, it returns a response that "rocketchat" has been added to your repositories.

2. Define the deployment configurations

To install the Rocket.Chat with the chart, define your configuration options in a values.yaml file. Kindly refer to the configuration section to learn more about the deployment configurations you can set in your values.yaml file. However, let’s create an example file to proceed with this guide:

• Create values.yaml file with the following content to define the configurations that Helm will use for your deployment:

image:
  pullPolicy: IfNotPresent
  repository: registry.rocket.chat/rocketchat/rocket.chat
  tag: <release>

mongodb:
  enabled: true  #For test purposes, a single mongodb pod is deployed, consider an external MongoDB cluster for production environments
  auth:
    passwords:
      - rocketchat
    rootPassword: rocketchatroot

microservices:
  enabled: true
  presence:
    replicas: 1
  ddpStreamer:
    replicas: 1
  account:
    replicas: 1
  authorization:
    replicas: 1
  streamHub:
    replicas: 1
  nats:
    replicas: 1

host: domain.xyz 
ingress:
  enabled: true
  ingressClassName: nginx  # State the ingress controller that is installed in the K8s cluster 
  annotations:
    cert-manager.io/cluster-issuer: production-cert-issuer # Replace with the name of your ClusterIssuer 
  tls:
    - secretName: rckube #This is the name of the secret - You can use a different name if needed 
      hosts:
        - domain.xyz #This is the domain for your Rocket.Chat server, Replace it with your own domain 

• Replace the <release> with the Rocket.Chat release tag you want to deploy.

• Update domain.xyz with your domain name

• Optionally, you can use a different secretName for tls.

• Ensure that the appropriate ingressclassName and cluster issuer are specified.

3. Install Rocket.Chat

Now that you’ve defined the configurations in values.yaml, install Rocket.Chat with the following command:

helm install rocketchat -f values.yaml rocketchat/rocketchat

If your deployment is successful, you’ll get a response similar to the following:

Verify that the corresponding certificates, secrets, and pods have been successfully created with the kubectl get pods command. The result is similar to the image below, depending on your configurations:

You can now access your workspace via the URL where Rocket.Chat was deployed (your domain), and complete the Rocket.Chat Setup Wizard.

Additionally, you can refer to this recording that explains how to deploy Rocket.Chat with microservices in a test environment.

To update your deployment or convert your monolith deployment, edit the values.yaml and use the helm upgrade command:

helm upgrade rocketchat -f values.yaml rocketchat/rocketchat

Visit the Deploy with Kubernetes guide to learn more about the Kubernetes deployment procedure.

For multi-workspace deployment, please contact support.