Editing Rocket.Chat (section)

== Installation ==
There are multiple modes for installing rocket chat -- from a bare metal install to a kubernetes/helm deployment.  The instructions in the [https://docs.rocket.chat 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 installation|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):

<pre>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 </pre>

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:

<pre>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: /</pre>

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