April 20

Переезд из Slack в Mattermost

Не нашел живых примеров переездов на Mattermost в красках, чтобы с кровью и болью, поэтому опишу здесь несколько моментов, на которые стоит обратить внимание.

Установка

Страница инсталляции https://mattermost.com/deploy/ предлагает несколько вариантов, в нем есть вариант установки в Kubernetes – мой вариант, хотя есть описание установки через Docker, документация веред на страницу с 404 ошибкой, проекты из репозитория, которые подходят по смыслу:

Ладно. Установка в кластер Kubernetes по статье реализуется через 3 оператора – mysql-operator, minio-operator, mattermost-operator. Последний управляет двумя другими, вот такой вот подход. Ещё в документе есть таблица с тем сколько и на активное количество пользователей потребуется ресурсов.

Описание конфигурации Mattermost, для оператора, состоит из нескольких обязательных полей:

  • name;
  • size (!?);
  • ingress.

Мой интерес вызвал параметр "size", вот что о нем пишут:

The size of your installation.

Так-так-так, и что?

This can be ‘100users’, ‘1000users, ‘5000users’, ‘10000users’, or ‘25000users’.

Не очень понятно, открываем сам CustomResourceDefinition, там зловещая идея раскрывается более подробно:

Size defines the size of the ClusterInstallation. This is typically specified in number of users. This will override replica and resource requests/limits appropriately for the provided number of users. This is a write-only field - its value is erased after setting appropriate values of resources. Accepted values are: 100users, 1000users, 5000users, 10000users, 250000users. If replicas and resource requests/limits are not specified, and Size is not provided the configuration for 5000users will be applied. Setting 'Replicas', 'Resources', 'Minio.Replicas', 'Minio.Resource', 'Database.Replicas', or 'Database.Resources' will override the values set by Size. Setting new Size will override previous values regardless if set by Size or manually.

Другими словами – от параметра "size" зависит конфигурация инсталляции вашего сервера Mattemost, число его реплик и выделенных ресурсов. Шаманство какое-то, но на практике удалось выяснить следующее:

  • 100users – 1 реплика Mattermost, Master MySQL;
  • 1000users – 2 реплики Mattermost, Master/Slave MySQL.

Переопределение ресурсов и лимитов, которые упоминаются, невозможно, для каждого значения параметра "size" это свои цифры, а отсутствие значение "size" – это, как выше написано, – "5000users".

Тут следует отметить одно из ограничений бесплатной версии Mattermost – нет HA-режима, соответственно вариант работы в несколько реплик отпадает сам собой, при старте сервер ругается, что у него нет лицензии для работы в таком режиме, но вы всё ещё можете это попробовать. У Mattermost нет external кэша в виде какого-нибудь Redis, поддержка кластерного режима реализована внутри сервера, реплики обмениваются данными по gossip-протолоку, без этой связки можно ловить странные вещи – сохранение конфигурации через раз, некорректная загрузка файлов. Разработчики заботливо оставили интерфейс, по которому реализуется поддержка кластерного режима, да и вообще, поговаривают, до какого-то времени собрать Enterprise версию можно было самостоятельно. Поверим на слово.

Возвращаясь к теме конфигурации и тексту документа, с которого все начинается:

This document describes installing and deploying a production-ready Mattermost system on a Kubernetes cluster using the Mattermost Kubernetes operator.

Ниже можно заметить:

It is possible to manage MySQL database and MinIO file store using the Mattermost Operator, but it is not recommended for production usage.

После всех тестов мы решили перенести файловое хранилище в Yandex Object Storage, а MySQL в Managed Service for MySQL, всё в том же Yandex Cloud. Для хранилища создается отдельный секрет:

---
apiVersion: v1
kind: Secret
metadata:
  name: mattermost-filestore
type: Opaque
data:
  accesskey: ...
  secretkey: ...

В переменных окружения сервера задается следующее (все эти настройки можно так же определить в Системной консоли):

  • MM_FILESETTINGS_DRIVERNAME – amazons3
  • MM_FILESETTINGS_AMAZONS3BUCKET – имя бакета
  • MM_FILESETTINGS_AMAZONS3ENDPOINT – storage.yandexcloud.net
  • MM_FILESETTINGS_AMAZONS3SSL – true
  • MM_FILESETTINGS_AMAZONS3SSE – true
  • MM_FILESETTINGS_AMAZONS3TRACE – true (если нужны отладочные логи)
  • MM_FILESETTINGS_AMAZONS3REGION – ru-central1

Для базы, по статье, следует создать секрет и задать в нем некоторые параметры, все они содержать реквизиты подключения к базе, но используются в разных частях системы, поэтому записываются немного по-разному, такой вот поворот:

  • DB_CONNECTION_CHECK_URL – http-ссылка, в формате http://hostname:3306, резвизиты не передаются, используется в init-container'е, чтобы определить, что база доступна;
  • DB_CONNECTION_STRING – строка подключения в формате mysql://user:password@tcp(hostname:3306)/mattermost?charset=utf8mb4,utf8&writeTimeout=30s, в переменных передается серверу как MM_CONFIG;
  • MM_SQLSETTINGS_DATASOURCEREPLICAS – строка подключения в формате user:password@tcp(hostname:3306)/mattermost?readTimeout=30s&writeTimeout=30s.

Последнее, предположительно, используется в кластерном режиме, в документации упоминаний об этом нет, но если запускать сервер в 1 реплику с внешней базой – init container успешно отработает, а дальше начинается проверка соединения внутри сервера Mattermost, который пытается подключиться куда-то не туда, куда нам нужно. Опытным путем выяснилось, что нужно задать еще один параметр:

  • MM_SQLSETTINGS_DATASOURCE – строка подключения в формате user:password@tcp(hostname:3306)/mattermost?readTimeout=30s&writeTimeout=30s.

Настройка

Треды

В настройщее время (я все эксперименты проводил на Mattermost 6.5, хотя уже вышла 6.6), треды как вложенные обсуждения – это экспериментальная фитча:

Чтобы включить этот функционал, нужно включить Automatically Follow Threads, сделать это можно через переменную окружения:

- name: MM_SERVICESETTINGS_THREADAUTOFOLLOW
  value: "true"

После того, как значение будет задано, тип тредов можно будет переключить.

Пуши

По умолчанию, это отключено, можно включить публичный сервис для пушей Mattermost, насколько стабилен и какие ограничения – не выяснялось.

Звонки

Функционал звонков реализован в виде плагина, который ставится из маркетплейса Mattermost:

Больши информации можно найти здесь, функционал в бете, но нам удалось даже созвониться.

Интеграции

Если вы использовали Slack для получения каких-то простых уведомления, то всё нормально, этот функционал сохранен, если только вы не используете какие-то диковиные штуки внутри:

Для создания типово Slack Webhook ссылки, переходите из меню в Интеграции, далее нажимаете на здоровенную кнопку Входящие вебхуки, создаете вебхук, копируете ссылку, используете вместо то, что была раньше.

По умолчанию сообщения будут создаваться от имени человека, который эту интеграцию создал, аватарка так же будет от него, чтобы поменять подобное поведение переходим в Системную консоль и в разделе настроек интеграции задаете:

По итогу получается что-то такое:

SAML, LDAP, OpenID

Ничего этого нет, есть только аутентификация через Gitlab.

Полнотекстовый поиск

Поддержка ElasticSearch есть только в Enterprise версии, в бесплатной по умолчанию используется полнотекстовый поиск по базе, либо предлагается альтернатива в виде поискового движка Bleve, который встроен в сервер (пару раз работа этого движка приводила к падению Mattermost).

Заключение

Да, в Mattermost многое работает странно, да, часть интеграций отвалилась и нужно переделывать, да, там все выглядеть страшно, но всё же меня радует, что людям предоставлен функционал плагинов, а значит ждем от всех поуехавших функционал, который доведет Mattermost до готового решения коммуникации в компании.

P.S.

В Mattermost есть плагин – генератор мемов...