This deployment architecture consists of several "micro" services or smaller components, each focusing on one feature of Rocket.Chat. Imagine that each component provides a service, and they are all combined to form your fully operational Rocket.Chat workspace.
The components include the following:
- authorization (
rocketchat/authorization-service):This provides authorization capabilities like role/permission validation. It differs from authentication, which primarily deals with login systems.
- 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.
- stream-hub (
rocketchat/stream-hub-service): 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): The accounts component is responsible for managing user accounts and authentication -
- ddp-streamer (
rocketchat/ddp-streamer-service): It deals with all web socket connections. All web socket connections must be forwarded directly to this service. It uses the Distributed Data Protocol (DDP).
- presence (
rocketchat/presence-service): The presence component is responsible for managing 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 microservices deployment looks like the diagram below. Each component is comprised of one container from a bare metal perspective.
Rocket.Chat deployment with multiple microservices
Since each component is a container, you can pull them the same way as any docker image. Consequently, you can also deploy Rocket.Chat with all these components via docker directly or with docker-compose; however, it is not officially supported. To deploy using docker directly, you are required to set up nats. Ensure that you're using a custom network to connect each related container.
Bare minimum, each container must be started with
TRANSPORTERenvironment variables set, pointing to the MongoDB database (using full connection string) and the nats gateway address, respectively. At the very least, each container must be started with
TRANSPORTERenvironment variables set, pointing to the MongoDB database (using full connection string) and the NATS gateway address, respectively. All
/websocketconnections must be routed through a reverse proxy or load balancer (LB), with the remainder going to the monolith.
Again, it is essential to note that we do not support direct docker/compose microservices deployment. The only supported method currently is using Kubernetes with our official helm chart.
Rocket.Chat's microservices architecture allows for greater scalability, flexibility, resilience, and fault tolerance in the functioning of your workspace. This makes it possible for your workspace to manage large user volumes and adapt to changing business needs. This guide shows how to deploy Rocket.Chat and archive microservices using Kubernetes and Helm, our officially supported method.
To use Helm for deploying microservices, here are certain prerequisites that need to be met:
- A Kubernetes cluster is set up and configured.
- A working installation of Helm 3.
- Basic understanding of Kubernetes and Helm.
- Add the RocketChat helm repository to your system by running the following command:
helm repo add rocketchat https://rocketchat.github.io/helm-charts
- Configure the Rocket.Chat deployment. By default, the Rocket.Chat Helm chart deploys a single monolith with a single instance. To enable microservices, edit your
Values.yamlfile and include these commands:
Each component has its section inside the
Values.ymlfile. The top level is for the monolith configuration.
To set the desired number of replicas for any of the services, set the
replicasvalue for the respective service.
ddp-streamershould be scaled from the beginning. Aim for one pod for every 500 concurrent users.
For monolith replicas, set the top-level
stream-hubis 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 needs to be sent directly to the
ddp-streamerservice as mentioned earlier. For example, install an nginx controller in your cluster following this guide, then edit the
values.ymlfile and add the following values:
host: # the host to access your rocket.chat instance from, omit the protocol
This adds the necessary ingress resource with all the expected paths and backends configured. The
ingressClassNameis essential unless you have a default class set; depending on the type of controller you're using, refer to the respective documentation.
Nginx controller is used as an example and not an official recommendation. Any ingress controller can be used, with the
ingressClassNameproperty set correctly or the
IngressClassresource set to the default one for the cluster or the controller watches for
Ingressresources with no specific class defined.
- Apply the changes and install. Once you have made the necessary changes to the values file, run the following command to upgrade the deployment:
helm install rocketchat -f Values.yaml rocketchat/rocketchat
- Once deployed, you should be able to access the Rocket.Chat using the configured host. You can convert your existing monolith deployment to using microservices by making the same changes mentioned in this document and running
helm upgradewith the values file and the current deployment name instead of
A complete guide on how to deploy with helm can be found in Kubernetes with Helm. For multi-workspace deployment, please contact support.