Partager sur Bluesky

Il y a un an et demi, j'ai ouvert mon propore serveur Mastodon pour pouvoir relayer mes publications Animint relayées sur l'ex-Twitter et désormais aussi sur Bluesky. Mon serveur est connecté sur le Fédiverse mais il présente un fort caractère privé étant donné qu'il n'y a que les comptes liés à ce site et que les inscriptions sont fermées.

 

La compilation et l'installation complète pas à pas ont été assez fastidieuses, avec les prérequis à préparer et les pièges des différents référentiels des différents composants soit pas assez à jour ou bien trop à jour par rapport à la compatibilité du code de Mastodon.

 

Heureusement, une fois la première installation effectuée, les mises à jour sont plus légères à appliquer. Les directives comportent cependant plus d'étapes que si mon serveur Mastodon avait été déployé via Docker. 

 

 

 

À l'époque, je connaissais trop peu Docker donc j'ai évité d'en dépendre et j'ai opté pour un déploiement de serveur Mastodon directement depuis le code source. 

 

Depuis 2022, le serveur a rempli son office – hormis une interruption prolongée pour circonstance exceptionnelle – mais s'il était largement dimensionné en terme de mémoire et d'espace disque, la bande passante disponible était très insuffisante. Le peu de posts arrivaient à passer et il y a peu de visites directes sur le serveur mais les publications mettaient du temps à se propager sur le réseau. 

 

J'ai finalement trouvé une solution d'hébergement alternative mais cela signifiait aussi réinstaller un serveur avec Mastodon dessus.     

 

Il y avait certes un déménagement à gérer mais d'un autre côté :

La documentation officielle de Mastodon comporte les instruction pour une installation depuis le code source mais explique comment utiliser Docker que pour le montage d'un environnement de développement. Le code officiel contient en revanche des fichiers de configuration Docker avec une version qui peut servir de base pour un serveur de production.

 

Dans l'installation directe depuis le code source, vous avez à installer une trentaine de paquets dont le serveur web Nginx, node.js, le serveur de dictionnaire redis, la base de donnée PostgreSQL ou encore Ruby. À la fin de la longue procédure, vous arrivez à avoir le serveur Nginx en proxy inverse devant les 3 services Mastodon : web, sidekit et streaming.

 

La dockerisation officielle de Mastodon rajoute juste une couche d'abstraction en isolant les 3 services Mastodon dans des containers, puis en mettant aussi redis et PostgreSQL à part. Le dernier container utile inactif par défaut est pour Elasticsearch qui sert à gérer les indexations et les recherches.

 

Le serveur web Nginx est conservé tel quel, et est configuré de la même manière que ce soit pour une installation depuis les sources ou via Docker. C'est une bonne pratique dans l'absolu de conserver ce serveur web en dehors de Docker car cela permet de gérer la maintenance quand il faut mettre à jour Docker. Si le proxy inverse est dans un container, il tombe en même temps que Docker.

 

 

Le fichier de configuration docker-compose.yml de Mastodon contient une instruction pour recompiler à partir des sources. C'est un peu étrange étant donné qu'on part des images déjà préparées et que cela ne se justifie que si le code a été retouché en local, ce qui ne doit pas être le cas en général pour une version de production. 

 

Le tutoriel que j'ai suivi indique de mettre ces directives en commentaires pour économiser la phase  de recompilation.

 

De plus, l'image 4.2.7 mentionnée à ce jour dans la configuration est obsolète alors que l'image en version 4.2.8 est disponible.  

 

Un autre tutoriel contient un container console qui est lancé à la demande avec les utilitaires en ligne de commande de Mastodon. Je l'utilise pour programmer la purge des différents fichiers obsolètes en restant au niveau de la crontab du serveur, sans être obligé de gérer une crontab à l'intérieur d'un container.

 

Avec tout cela, je me retrouve avec un fichier docker-compose.yml personnalisée, ne serait-ce que pour activer le container Elasticsearch. Il est possible de gérer deux fichiers de configuration à la fois, l'un écrasant l'autre mais il faudra penser à surveiller les changements apportés dans le fichier officiel docker-compose.yml au fil des versions et à éventuellement les reporter dans le fichier docker-compose.override.yml  s'il y a un conflit. Bizarrement les tutoriels oublient de signaler la possibilité d'avoir ce fichier override et touchent directement au fichier docker-compose.yml d'origine, en se prenant un peu la tête ensuite pour faire attention aux conflits depuis le dépôt du code source et fusionner les changements à chaque montée de version.

 

Un autre aspect à surveiller avec Docker est la place que consomment les containers sur le disque. La valeur ajoutée de Docker est de pouvoir isoler les containers mais cela se fait au prix de quelques duplications. Avant même d'avoir publié ou lu mon premier message, le serveur occupait déjà 10 Go. La limitation de la taille des logs Docker et la politique de rotation et de purge devraient garder l'ensemble sous contrôle d'autant plus que le serveur est programmé pour redémarrer régulièrement.

 

Là aussi, j'ai pu constater une différence entre l'installation directe sur la machine et la version via Docker. Sur l'ancien serveur avec une installation directe, le redémarrage s'effectuait souvent sans problème. Avec Docker, le restart complet de la nouvelle machine s'avère trop brusque et j'ai du rallonger explicitement le temps d'attente de l'arrêt des containers pour éviter qu'ils soient forcés de se terminer et qu'ils soient incapables de redémarrer après, notamment celui qui gère Elasticsearch. C'est un poil plus complexe à suivre mais au moins c'est correctement géré maintenant.

 

J'attends de voir comment cela se passera la première mise à jour mais pour l'instant, le serveur est stable et accessible.

 

Le nouveau compte Mastodon pour Animint est @animint@mastodon.animint.fr