Comment installer Matrix Synapse Homeserver à l'aide de Docker

Matrix est une norme open source (protocole) pour la VoIP, la messagerie instantanée et les appels vidéo, c'est-à-dire la communication en temps réel. Il fournit un cryptage de bout en bout ainsi que la prise en charge de ponts vers diverses autres alternatives de messagerie telles que Slack, IRC, Telegram ou tout autre client XMPP. Il peut également fonctionner avec des connexions à faible bande passante.

Dans ce didacticiel, je vais vous montrer comment installer le serveur domestique Matrix Synapse à l'aide de conteneurs Docker.

Qu'est-ce qu'un serveur domestique Matrix ?

Matrix en soi n'est qu'une spécification et il existe de nombreuses implémentations du protocole Matrix disponibles publiquement.

Les serveurs domestiques sont essentiellement toutes ces implémentations déployées sur un serveur, auxquelles vous pouvez accéder via n'importe quel client Matrix comme Element.

La question qui peut se poser est la suivante :pourquoi mettre en place des serveurs domestiques privés si certains sont déjà disponibles publiquement ?

Eh bien, pour commencer, vous pouvez partager votre serveur domestique privé avec vos amis, votre famille ou vos collègues et l'utiliser comme moyen de communication au quotidien. À moins que vous ne vous engagiez dans une conversation avec un utilisateur d'un autre serveur domestique, toutes les données seront en sécurité sur votre serveur.

Cela vous donne le contrôle sur tous les aspects de celui-ci que les serveurs domestiques publics ne sont pas en mesure de fournir.

Déploiement de l'implémentation de Synapse Matrix homserver à l'aide de conteneurs Docker

J'utiliserai Synapse, une implémentation de serveur domestique Matrix populaire dans ce tutoriel. Écrit en Python, Synapse est développé par l'équipe principale de Matrix.

Chez Linux Handbook, nous préférons docker au déploiement natif, donc les sections suivantes couvriront le déploiement de Synapse effectué à l'aide de Docker.

Prérequis

Un système/serveur Linux. Nous vous recommandons d'utiliser Linode pour déployer rapidement un serveur Linux dans le cloud.
Un domaine fonctionnel et un accès à ses enregistrements DNS (sauf si vous souhaitez le configurer sur localhost)
Vous devriez avoir à la fois docker et docker-compose installés. Vous pouvez suivre notre guide d'installation de Docker et Docker Compose sur CentOS.
Je pense que vous connaissez les commandes Linux essentielles et que vous n'avez pas peur d'utiliser le terminal pour modifier les fichiers de configuration.
Une connaissance de base de Docker vous aidera, mais vous pouvez également suivre le didacticiel sans cela.

Étape 1 :Configurer le proxy inverse

Avant de vous salir les mains avec Synapse, vous devez d'abord configurer votre conteneur de proxy inverse et son conteneur Let's Encrypt pour les certificats TLS (vous voulez https, faites-moi confiance).

Configuration du conteneur de proxy inverse

Dans un environnement de production, vous n'utilisez pas docker run ... , vous utilisez docker-compose . Alors, configurons le jwilder/nginx-proxy en tant que proxy inverse.

Créez un répertoire nommé reverse-proxy et basculez vers ce répertoire nouvellement créé :

mkdir reverse-proxy && cd reverse-proxy

Ouvrez maintenant votre éditeur de texte préféré, créez un fichier nommé docker-compose.yml , et ajoutez le contenu suivant :

version: "3.3"

services:
    proxy:
        image: "jwilder/nginx-proxy"
        container_name: "proxy"
        volumes:
            - "certs:/etc/nginx/certs"
            - "vhost:/etc/nginx/vhost.d"
            - "html:/usr/share/nginx/html"
            - "/run/docker.sock:/tmp/docker.sock:ro"
        networks: ["server"]
        restart: "always"
        ports:
            - "80:80"
            - "443:443"

Donc ici, vous définissez d'abord votre service, nommé proxy . Les principales caractéristiques à garder à l'esprit sont :

Les volumes certs, vhost et html vont être partagés entre jwilder/nginx-proxy et jrcs/letsencrypt-nginx-proxy-companion conteneurs.
Le socket docker est monté en lecture seule sur /tmp/docker.sock .
Il utilise un réseau autre que le réseau de pont par défaut.
Les ports 80 et 443 sont liés, respectivement pour http et https.

Configurer letencrypt-nginx-proxy-companion

Ajoutez ce qui suit à la fin du même fichier de composition

letsencrypt:
        image: "jrcs/letsencrypt-nginx-proxy-companion"
        container_name: "letsencrypt"
        volumes:
            - "certs:/etc/nginx/certs"
            - "vhost:/etc/nginx/vhost.d"
            - "html:/usr/share/nginx/html"
            - "/run/docker.sock:/var/run/docker.sock:ro"
        environment:
            NGINX_PROXY_CONTAINER: "proxy"
        networks: ["server"]
        restart: "always"
        depends_on: ["proxy"]

Ici, vous avez un autre service défini, nommé letsencrypt. Passons également en revue celui-ci :

Tous les volumes du service précédent sont également montés aux mêmes emplacements ici.
Le socket docker est lié en lecture seule à /var/run/docker.sock .
La variable d'environnement NGINX_PROXY_CONTAINER est défini sur le nom du conteneur du proxy inverse, qui dans notre cas est "proxy".
Il partage le même réseau "serveur".

À la fin de ces deux descriptions de service, ajoutez les définitions des volumes et la définition du réseau, comme ci-dessous :

networks:
    server:
        external: true

volumes:
    certs:
    vhost:
    html:

Deux choses importantes à noter ici :

Vous allez utiliser un fichier de composition distinct pour Synapse. De cette façon, vous aurez un déploiement modulaire et vous pourrez facilement arrêter un service, sans affecter les autres, en déployant le proxy inverse et son compagnon à l'aide d'un fichier YAML différent.
Le réseau est externe. C'est pour éviter tout problème avec d'autres conteneurs ne partageant pas le même réseau en raison de la façon dont docker-compose nomme ses volumes et réseaux lorsqu'il est laissé être créé automatiquement. Cela nous amène à créer le réseau. Utilisez la commande docker network create server pour créer le réseau.

Maintenant que tout est fait, enregistrez le fichier et quittez l'éditeur.

Il est maintenant temps de démarrer votre serveur proxy inverse.

docker-compose up -d

Étape 2 :Configurer Synapse

Il est maintenant temps que vous commenciez enfin à vous concentrer sur la bonne partie. Le déploiement de synapse est donc un processus en deux étapes.

Tout d'abord, vous en avez besoin pour générer une configuration, ensuite, vous nettoyez la configuration et déployez notre serveur domestique.

Commençons par obtenir le fichier de composition.

Générer la configuration

Créez un répertoire séparé nommé "synapse" et basculez-y.

mkdir synapse && cd synapse

Créez un fichier nommé docker-compose.yml et ouvrez-le, vous connaissez l'exercice, n'est-ce pas ?

Assurez-vous d'utiliser les valeurs correctes pour sub.domain.com dans le fichier yml ici :

version: "3.3"

services:
    synapse:
        image: "matrixdotorg/synapse:latest"
        container_name: "synapse"
        volumes:
            - "./data:/data"
        environment:
            VIRTUAL_HOST: "sub.domain.com"
            VIRTUAL_PORT: 8008
            LETSENCRYPT_HOST: "sub.domain.com"
            SYNAPSE_SERVER_NAME: "sub.domain.com"
            SYNAPSE_REPORT_STATS: "yes"
        networks: ["server"]


networks:
    server:
        external: true

Il s'agit d'un fichier de composition standard à première vue, mais quelques options remarquables sont expliquées ci-dessous :

Vous utilisez un montage lié au lieu d'un volume, c'est parce que le fichier de configuration va y être généré et que vous devez le modifier. Vous pouvez sûrement utiliser des volumes, mais vous devrez ensuite éditer le fichier situé dans /var/lib/docker/volumes/<name>/_data .
Les variables d'environnement VIRTUAL_HOST &LETSENCRYPT_HOST sont pour les conteneurs letsencrypt et reverse proxy, qui généreront les changements de configuration nécessaires avec les certificats, sans que vous n'interveniez manuellement.
Assurez-vous que SYNAPSE_SERVER_NAME pointe vers le FQDN de votre serveur Synapse (avec le sous-domaine).
Définir VIRUAL_PORT à 8008. Le conteneur synapse expose le port HTTP 8008 pour que ses clients puissent communiquer avec lui.
Enfin, assurez-vous que ce conteneur utilise le même réseau que le conteneur de proxy inverse, sinon les conteneurs ne pourront pas communiquer, ce qui interrompra l'ensemble du processus.

Confirmez que l'adresse IP du serveur est ajoutée à l'enregistrement A de votre DNS et qu'un enregistrement CNAME pointe vers le sous-domaine exact.

Créer une data répertoire et exécutez la commande suivante

docker-compose run --rm synapse generate

Cela générera le fichier de configuration dans ./data, nommé "homeserver.yaml".

Configurer synapse

Il y a beaucoup d'options configurables dans le homeserver.yaml fichier, qui sont hors de la portée de ce didacticiel. Je vous suggère de parcourir les commentaires de ce fichier et de lire ici.

Pour l'instant, assurez-vous simplement des modifications suivantes :

Le server_name est définie sur le sous-domaine de votre choix, comme défini dans la variable d'environnement SYNAPSE_SERVER_NAME .
TLS est défini sur faux. Vous utilisez un proxy inverse, donc TLS est géré via votre serveur Web. Laissez le port tranquille.
Assurez-vous que enable_registration est défini sur true, afin que vous puissiez vous inscrire et utiliser votre serveur domestique.

Enregistrez le fichier et quittez.

Déployer le serveur domestique Synapse Matrix

Maintenant que tout est en place, vous pouvez démarrer synapse en utilisant une commande aussi simple que

docker-compose up -d

Votre serveur domestique est maintenant prêt à être utilisé. Si vous visitez le sous-domaine dans un navigateur Web, vous devriez voir un message comme celui-ci :

Utilisation de PostgreSQL pour la base de données [facultatif]

Par défaut, synapse utilise SQLite pour sa base de données. C'est bon pour les tests et une utilisation occasionnelle, mais pour un cas d'utilisation plus important, je recommande d'utiliser PostgreSQL.

Ajouter PostgreSQL au fichier de composition synapse

Allez dans le répertoire synapse si vous n'y êtes pas déjà et ouvrez docker-compose.yml . Ajoutez les lignes suivantes à ce fichier de composition.

postgresql:
        image: postgres:latest
        restart: always
        environment:
            POSTGRES_PASSWORD: somepassword
            POSTGRES_USER: synapse
            POSTGRES_DB: synapse
            POSTGRES_INITDB_ARGS: "--encoding='UTF8' --lc-collate='C' --lc-ctype='C'"
        volumes:
            - "postgresdata:/var/lib/postgresql/"
        networks: ["server"]

Le POSTGRES_INITDB_ARGS variable est très nécessaire. Il définit le classement, le ctype et l'encodage utilisés pour la base de données postgres. Ce sont une nécessité absolue pour que la synapse fonctionne. Ajoutez le volume à la section des volumes :

volumes:
    postgresdata:

Configurer Synapse

Maintenant, vous devez informer synapse de la base de données postgresql. Vous faites cela en éditant l'ancien homeserver.yaml dossier. Ouvrez ce fichier et découvrez les lignes suivantes :

database:
    name: sqlite3
    args:
        database: /path/to/homeserver.db

Supprimez-les car nous n'en avons plus besoin. Ajoutez plutôt ce qui suit :

database:
    name: psycopg2
    args:
        user: synapse
        password: somepassword
        host: postgresql
        database: synapse
        cp_min: 5
        cp_max: 10

Le nom de la base de données est psycopg2, qui est un adaptateur PostgreSQL pour python.

Regardez attentivement, vous verrez les similitudes entre cela et les variables d'environnement que vous avez configurées pour le conteneur postgresql.

En ce qui concerne l'hôte, car vous utilisez docker-compose et un réseau personnalisé, synapse pourra résoudre automatiquement le nom du service. Vous n'avez pas à vous en soucier.

Enregistrez le fichier et quittez.

Déployer

Bon, que reste-t-il vraiment à faire ? Déployez-le.

docker-compose up -d

Tester le déploiement du serveur domestique Synapse Matrix

Votre serveur domestique est prêt. Testons-le. Matrix n'est qu'un protocole, Synapse n'est qu'une implémentation. Vous avez besoin d'un client Matrix pour pouvoir l'utiliser comme un outil de messagerie.

Voici une liste des différents clients Matrix disponibles. Element est probablement l'un des clients Matrix les plus populaires que vous puissiez utiliser.

Une fois le client Matrix installé, exécutez-le. Créez un compte ici.

Sur la page d'enregistrement, remplissez tous les détails et sur le serveur domestique, entrez le sous-domaine que vous aviez utilisé précédemment. Cliquez sur s'inscrire.

Vous avez maintenant un déploiement Synapse parfaitement fonctionnel que vous pouvez utiliser avec votre famille ou vos amis sans avoir à vous soucier de l'endroit où vos données sont stockées ou quoi que ce soit du genre.

Configurer la fédération dans Synapse avec Docker [facultatif]

La fédération est essentiellement la capacité de communiquer avec des utilisateurs sur un serveur domestique différent.

Par exemple, si votre ID utilisateur est @coolguy:coolserver.me, vous pourrez inviter quelqu'un comme @Greatme:awesome.us dans une salle de votre serveur domestique.

De même, vous pouvez également rejoindre des salles hébergées sur d'autres serveurs domestiques.

Si vous avez déjà synapse en cours d'exécution, il n'est pas nécessaire d'arrêter le(s) conteneur(s). Vous n'avez qu'à apporter des modifications à votre conteneur de proxy NGINX. Cela ne comprend pas plus de trois étapes courtes et faciles.

Il existe plusieurs façons de faire fonctionner la Fédération, mais parmi celles-ci, celle que j'ai trouvée extrêmement facile à suivre et qui nécessite des modifications minimes de votre configuration existante, s'appelle la délégation de port.

Par défaut, chaque serveur matriciel essaie d'atteindre un autre serveur matriciel via le port 8443. Le processus suivant indique essentiellement aux autres serveurs d'utiliser un port différent. Étant donné que https fonctionne déjà sur le port 443, vous allez simplement déléguer le port de communication matriciel par défaut à 443.

Étape 1 :Créer un fichier de configuration pour notre proxy inverse

Entrez dans le répertoire du proxy inverse Nginx. Créez un fichier nommé synapse-federation . Ajoutez le texte suivant à ce fichier :

location /.well-known/matrix/server {
    return 200 '{"m.server": "$VIRTUAL_HOST:443"}';
}

Modifier $VIRTUAL_HOST à sa valeur appropriée, qui est essentiellement le domaine auquel votre instance de matrice est servie (définie en fonction du fichier docker-compose de synapse).

Étape 2 :Modifier docker-compose.yml

Ouvrez votre docker-compose.yml fichier et ajoutez une autre entrée au tableau des volumes :

 - ./synapse-federation:/etc/nginx/vhost.d/$VIRTUAL_HOST

Encore une fois, modifiez $VIRTUAL_HOST à sa valeur appropriée.

Étape 3 :Redémarrez le serveur proxy

Vous devez maintenant redémarrer le serveur proxy.

docker-compose up -d proxy

Cela recréera le conteneur de proxy inverse. Vous n'avez pas à vous soucier de la perte d'une configuration précédente, à moins que vous n'ayez modifié quoi que ce soit manuellement après le déploiement. La configuration est dynamique, donc tout ira bien.

Tester les modifications

Vous pouvez tester les modifications de deux manières.

Essayez de rejoindre une salle comme #servers:matrix.org . Exécutez la commande suivante, si vous avez jq installé :

curl https://federationtester.matrix.org/api/report?server_name=$VIRTUAL_HOST --silent | jq -r '.FederationOK'

Ou utilisez celui-ci plus hack-y :

curl https://federationtester.matrix.org/api/report?server_name=$VIRTUAL_HOST --silent | awk '/FederationOK/ {print $2}'

Cela devrait afficher 'true'. Et évidemment changer $VIRTUAL_HOST au domaine desservant votre instance synapse.

Cela vous a-t-il été utile ?

J'espère que cela vous a été utile autant que l'expérience l'a été pour moi. Si vous voulez plus d'articles comme celui-ci, n'hésitez pas à commenter ci-dessous. Si vous rencontrez un problème, laissez un commentaire et j'essaierai de vous aider.