Rocket.Chat

Rocket.Chat is a lightweight collaboration tool similar to Slack. It is written in javascript and runs in a single node.js process, using mongodb as its data store. Each instance of Rocket.Chat is a single threaded application, but they are configured to enable multiple instances to run concurrently using the same database -- enabling practically infinite scalability for reliability or performance/capacity.

You can go to their website for the marketing drivel ...

Installation

There are multiple modes for installing rocket chat -- from a bare metal install to a kubernetes/helm deployment. The instructions in the Rocket.Chat Documentation are very detailed and complete -- I won't repeat them here -- just highlight some experiences.

SSL termination and proxying

By design, Rocket.Chat is not designed to directly terminate SSL connections. It can if needed, but the intended architecture is to have all the Rocket.Chat instances that form a cluster live behind a reverse proxy/load balancer, which does the termination of the SSL connection once for all the instances. If security requires the communications between Load Balancer and RocketChat to be encrypted (or if you will only be using one instance of Rocket.Chat), that is when you will set up Rocket.Chat to use SSL.

The Load Balancer/Reverse Proxy doesn't have to be anything complicated -- they provide a simple config for HA-Proxy and NGINX that works very well. If deploying in kubernetes, using the standard kubernetes service works well, but the standard Ingress doesn't handle the connection well due to the fact that Rocket.Chat requires the use of websockets. Fortunately the documentation discussed this enough that I figured out what was needed (see below).

Bare Metal Install

The documentation was very thorough on this topic -- nothing to add except to say that it works very well and is very resource-efficient.

Kubernetes/Helm Install

There is a helm chart for Rocket.Chat in the standard repository for helm that works well (mostly). See my rant on Helm elsewhere ...

The helm chart surfaces variables that are essential to a production instance of Rocket.Chat:

• mongodbUsername/mongodbPassword -- while the install process will generate random passwords and uses the standard 'rocketchat' user, you should specify them on the helm install command line to avoid having to dig them out and save/change them later ... it will also make upgrading easier
• mongodbDatabase/mongodbRootPassword -- again, defaults are available, but specifying the password will make upgrading easier.
• mongodb.persistence.size -- the size of the image that will be requested for the mongodb data store. Choose carefully, expansion may not be possible, requiring a rebuild of the deployment later.
• image.tag -- the docker container image tag to use ... the helm chart is significantly behind ... but this seems to be a workable way to use the current version
• host -- the public name of the Rocket.Chat server

For consistency and convenience in upgrading later, these variables are set in an install script that runs the helm install (and can be modified to run the upgrade later):

helm install rocketchat stable/rocketchat \
    --set mongodb.mongodbUsername=rocketchat \
    --set mongodb.mongodbPassword=menagerie \
    --set mongodb.mongodbDatabase=rocketchat \
    --set mongodb.mongodbRootPassword=menagerie \
    --set mongodb.persistence.size=20G \
    --set image.tag=3.5.2 \
    --set host=rocket.williams-net.org 

This is contained in a file in the rocketchat project in GitLab.

This helm chart will create the requisite service, deployment, persistent volumes and claims, etc. to get the RocketChat server running. Getting access to the server requires an Ingress controller; but as mentioned above, a normal ingress controller will not suffice. The Contour Project ( new CNCF project) provides an ingress controller based on the Envoy proxy, which is used as the foundation for many communications subsystems for kubernetes including the istio service mesh. One thing that they have done which we depend on here is to implement an improved Ingress called a 'HTTPProxy' -- in their words, what an Ingress really should have been from the beginning.

After the Contour Ingress Controller has been installed, it is a simple matter to deploy the HTTPProxy to enable outside access -- using cert-manager (as described in the Coutour page) to obtain and deploy the certificate for SSL encrypted traffic:

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  namespace: rocketchat
  name: rocket-chat
spec:
  virtualhost:
    fqdn: rocket.williams-net.org
    tls:
      secretName: rocket-chat-cert
  routes:
  - services:
    - name: rocketchat-rocketchat
      port: 80
    enableWebsockets: true
    requestHeadersPolicy:
      set:
      - name: Host
        value: external.dev
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  namespace: rocketchat
  name: rocket-chat
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    ingress.kubernetes.io/force-ssl-redirect: "true"
    kubernetes.io/tls-acme: "true"
spec:
  tls:
  - secretName: rocket-chat-cert
    hosts:
    - rocket.williams-net.org
  rules:
  - host: rocket.williams-net.org
    http:
      paths:
      - backend:
          serviceName: rocketchat-rocketchat
          servicePort: 80
        path: /

Note that the server hostnames in the HTTPProxy manifest above MUST MATCH ... and must match the 'host' parameter used to install Rocket.Chat using helm. Strange things happen if these names don't all match (speaking from experience ...)

This file is also in the rocketchat repository on Gitlab, and is deployed after the helm chart has been installed:

kubectl apply -f rocket-httpproxy.yaml

Operation

Most of the operation of the Rocket.Chat server is done from the server's administration panel ... but two points need to be made from the system level:

1. Updating the version of the Rocket.Chat server is easily done by editing the version of the docker image contained in the deployment manifest. This can be done through the 'k8dash' dashboard or by using 'kubectl edit' to change the container version and let Kubernetes do the hard work.
2. Increasing the number of instances is also easily done by using the 'scale' operation on the k8dash presentation of the deployment, or by using 'kubectl edit' to change the number of replicas -- again, kubernetes will do the hard work of launching new pods (or terminating pods if you scale down)