About four months ago, Canonical moved its internal communications from IRC to Mattermost. As part of this project I wrote a Juju charm to deploy Mattermost on Kubernetes using the operator framework.
The charm is simply named mattermost and is available directly from the Juju charm store. The source code is hosted on Launchpad.
To get started, deploy the charm to a Juju Kubernetes model as follows:
juju deploy cs:~mattermost-charmers/mattermost
The charm will need a database to finish deploying, which is done by connecting via a Juju relation to PostgreSQL. For now, this must be deployed to an IAAS model and a relation offer created for the user that owns the CAAS model. (The same user could own both models, in which case there is no need to worry about ownership, but an offer must still be created for the CAAS model to consume.) See the README for a worked example of deploying with LXD and microk8s.
Our production deployment uses Charmed Kubernetes and OpenStack but apart from the different substrates the deployment is essentially done in the same way.
The charm manages reverse-proxying by creating Kubernetes ingress resources and will enable TLS when the configured site URL demands it. There is no direct integration with Let’s Encrypt, but the charm works with any client that stores the key and certificate in a standard Kubernetes secret. Use the charm’s tls_secret_name setting to tell it the name of the resource to use.
Clustering requires an Enterprise Edition licence from Mattermost, but once this is enabled, the application can be scaled to multiple pods simply by using Juju’s scale-application command. Mattermost will use the database to register and discover cluster members; no additional service or infrastructure is needed.
The charm can make use of the following extra services:
-
Storage for images and attachments. Mattermost defaults to local storage, but S3 is strongly recommended, especially when clustering is enabled. Mattermost proxies images and files, so the S3 bucket itself can be made private and locked down completely.
-
Push notifications. In our deployment these are sent via Mattermost’s HPNS (hosted push notification service). The charm also supports self-hosted push notification servers, but please note the caveats to doing so.
The charm supports some additional features that require an Enterprise Edition licence: clustering (as mentioned), a Prometheus exporter for performance monitoring, and user authentication via SAML.
Should you wish to use Team Edition (the charm deploys Enterprise Edition by default) the Dockerfile is available from its repository on Launchpad. Once the image is built and pushed to a registry that your Kubernetes cluster can access, set mattermost_image_path.
Plugins are also managed via the image build. The image builder does not enable any additional plugins by default, but examples of enabling prepackaged and downloaded plugins via the image_flavour build argument can be found in the Dockerfile.
To deploy changes to the Mattermost webapp itself (for example, we wrote a patch to add branded themes to our deployment) the Dockerfile shows how to replace it.
Upgrades are done by building a new image and updating mattermost_image_path. Juju, Kubernetes, and Mattermost then work together to ensure that one pod is upgraded to the new version and makes any database schema changes before the rest of the pods are upgraded in their turn.
Since June 2020, we’ve seamlessly upgraded our production Mattermost cluster a number of times by this method without interruption to the business.
Many thanks to my colleagues in IS and to the folks on the Juju and Charmcraft teams who variously supplied advice, fixes, and workarounds for my questions and bug reports!
We would welcome any feedback, suggestions, bug reports, or merge proposals.