Réorganisation de l'infrastructure de mon VPS

Comment j'ai réinstallé mon serveur et pourquoi j'ai quitté le tout Docker ?

Dans cet article, je vais vous exposer la réorganisation de l'infrastructure de mon VPS. Pourquoi ? Car c'est un beau bazar lourd et complexe à maintenir.

Infrastructure précédente

Tous les services utilisés sont dans Docker, bien isolés de tout. Cette approche est lourde en performance : je me retrouve avec plusieurs databases PostgreSQL tournant en même temps. De plus, de nombreux services n'ont pas besoin d'avoir un environnement isolé pour fonctionner correctement, comme pour mes bots Discord.

Un autre problème, c'est que j'ai organisé tout ça n'importe comment. Déjà, la distribution Linux utilisée est CentOS Stream 9, ce qui est inadaptée pour du serveur à cause de sa durée de vie trop courte (6 ans, c'est court : je n'ai pas envie de devoir refaire toute l'infrastructure aussi souvent). Ensuite, les fichiers de configuration sont organisés d'une manière... aléatoire et peu rigoureuse. Bref, c'est un enfer à maintenir.

Mon serveur est actuellement le VPS 4vCore, 12GB de RAM et 250GB de stockage d'Infomaniak. Je dois choisir où monter le stockage de 250GB (j'ai 20GB pour mon système). Il est monté sur /opt, car tous les fichiers de configuration et de données sont dans ce dossier, ce qui est loin d'être idéal.

Objectifs de la nouvelle infrastructure

Mon objectif pour cette nouvelle infrastructure est d'avoir une organisation plus propre, plus fiable et qui dépend moins de Docker.

Mais pourquoi quitter Docker ?

Docker est très pertinent quand on a besoin d'avoir un environnement isolé pour des raisons de sécurité et de facilité. En effet, quand on héberge un bot Discord compilant à la volée du LaTeX, on préfère l'avoir dans un environnement isolé pour éviter toute intrusion sur le système hôte. De plus, cela permet d'éviter de devoir installer tout le toolset de LaTeX sur l'hôte, ce qui serait inutile.

Si on n'a pas besoin de ces avantages, utiliser Docker est une perte de temps, d'énergies et de performances : un container sera toujours plus lourd à gérer qu'une application native. Par exemple, si on a deux containers demandant une base de donnée PostgreSQL, il est recommandé d'avoir deux containers PostgreSQL, ce qui consomme plus de RAM. C'est pour ça que je n'aime plus le tout Docker.

Un autre problème de Docker est la dépendance aux fichiers docker-compose.yml pour gérer les déploiments. Je trouve ces fichiers peu pratique par rapport aux fichiers services de systemd. De plus, dans l'écosystème RHEL (dont fait partie CentOS Stream, Rocky Linux, Alma Linux...), Podman est conseillé et permet d'utiliser systemd — avec Quadlet — pour gérer les containers.

La nouvelle infrastructure

Le stockage de 250GB sera monté sur /var. Il s'agit du répertoire contenant toutes les données du système comme les logs, les fichiers des bases de données ou encore les mails. Les configurations seront dans /etc et le stockage de 20GB est largement suffisant pour les contenir (en plus des dossiers home).

L'OS utilisé sera AlmaLinux, car l'objectif de cette distribution est d'être 100% binaire compatible avec RHEL, la distribution Linux la plus adaptée pour serveurs. De plus, elle propose des outils permettant de réaliser des montées en version majeure (comme passer d'AlmaLinux 9 à 10), ce qui n'est pas possible avec Rocky Linux.(Autre avantage dans mon cas : AlmaLinux est directement disponible en version 10 chez Infomaniak, ce qui n'est pas le cas pour Rocky Linux.)

Concernant les services, la base de donnée PostgreSQL ne sera pas dans un container et sera géré par dnf. Elle sera accessible aux containers via un socket Unix. Le reverse-proxy Caddy sera lui-aussi géré par dnf. Toutes les applications compilées possédant une version officielle dans les dépôts de RHEL seront installées en dehors d'un container, sauf si elles ont besoin d'être isolé pour des raisons de sécurités. Toutes les applications node, php et autres langages interprétés seront dans un container pour être isolé du système.

Avant de se lancer dans le déploiement du nouveau serveur, il est essentiel de réaliser une backup de toutes les données et de savoir les transférer sur le nouveau serveur. Pour les DB PostgreSQL, les outils pg_dump et pgsql -X correspondent parfaitement à ce besoin. Pour MySQL, l'utilitaire mysqldump est là. Concernant les autres fichiers, ça sera un simple transfer à la main.

Retour d'expérience

Si on omet les galères de déploiement lié à mon absence d'expertise dans Quadlet (logiciel gérant les containers Podman avec systemd), le changement fut au début agréable.

Point négatif : j'ai dû me connecter à mon compte docker.io pour pouvoir continuer l'installation. Je trouve ça aberrant de mettre une limite aussi basse pour un service aussi essentiel alors que je n'utilise que deux images provenant de ces dépôts ! (Les images intermédiaires proviennent en majorité de leurs dépôts, c'est pour ça que j'ai atteint la rate-limit en étant déconnecté.) Ça me réconforte dans mon choix d'abandonner Docker pour Podman et d'éviter le tout container.

Plus je comprends le fonctionnement de Linux et de la philosophie UNIX, plus je trouve que cette approche est extrêmement pertinente seule. Les technologies comme les containers sont pratiques, mais loin d'être aussi nécessaire comme je le pensais avant. De plus, si on suit toutes les bonnes pratiques, le système est simple et évident à maintenir.

PostgreSQL en bare-bone est peu intuitif, car il faut configurer beaucoup de chose avant que ça marche, à l'inverse de Docker. Je ne comprends pas pourquoi c'est aussi compliqué et pourquoi ça ne marche juste pas par défaut.

Utiliser le file server de Caddy avec SELinux est peu pratique. J'ai remplacé mon CDN par copyparty, un serveur de fichier étonnement puissant. Il m'a aussi permis de me libérer du très lourd Nextcloud. J'utilise Radicale dans un container comme remplaçant CalDAV et DardDAV.

Avoir tout ça, il faut que je finisse de mettre en place mon serveur email (toujours un enfer ça) et que je m'occupe du système de backup automatisé. Je tente d'installer le SMTP et l'IMAP en barebone en suivant la documentation de Red Hat, mais j'ai peur que rien ne fonctionne et que je retourne sur ma solution dans les containers...