Infrastructure, 3ème itération
Je viens de mettre en production la 3ème itération de mon infrastructure personnelle, et j’en profite pour présenter ici un résumé des itérations précédentes, ainsi que de décrire son état actuel.
Première itération : 2020-2023
J’ai commencé à héberger mes propres services en avril 2020, pendant le premier confinement. J’avais à l’époque décidé d’acheter un nom de domaine et d’héberger une stack mail, en suivant le célèbre tutoriel de workaround.org, le tout sur le VPS OVH le moins cher possible (Didi).
J’ai ajouté en mars 2022 un deuxième VPS, Zii, celui-là chez Infomaniak, afin d’avoir un débit nettement plus élevé pour pouvoir m’en servir de serveur VPN, et d’avoir une ip de meilleure réputation (j’avais eu des problèmes avec Didi). Enfin, en octobre 2022, j’ai ajouté un troisième VPS, Izz, chez Contabo, avec pour intention de remplacer Zii. En effet, Infomaniak ne propose pas de contrôler le reverse DNS de l’ip de ses VPS, ce qui baissait la réputation des mails que j’envoyais. Elle me permettait également d’avoir beaucoup plus de stockage, pour un prix deux fois moins élevé. Elle n’a cependant jamais remplacé Zii.
Au fur et à mesure, j’ai ajouté plusieurs services sur ces serveurs : Dashy, bot Telegram, Icinga, Keycloak, et d’autres que j’oublie. Les 3 étaient reliées entre elles par un Wireguard, qui me servait également à faire sortir mon trafic par Zii en Suisse.
J’ai essayé au départ de gérer mon infrastructure avec Ansible, mais ce fut globalement un échec. Je n’arrivais pas à maintenir correctement les playbooks pour qu’ils continuent de correspondre à l’état réel des serveurs, et j’avais une tendance beaucoup trop grande à aller bidouiller dessus à la main pour résoudre les soucis. De plus, les 3 serveurs avaient des configurations assez hétérogènes, avec notamment Izz qui utilisait Traefik (dont je n’ai jamais vraiment été convaincue, mais que j’ai continué à utiliser dessus jusqu’au bout). Enfin, l’envie de jouer avec un serveur physique, et de pouvoir créer des VM ou des LXC à la demande sur un Proxmox, me faisait très envie.
Deuxième itération : 2023-2024
En février 2023, j’ai sauté le pas et j’ai acheté sur Leboncoin un Dell PowerEdge R710 (72Go de RAM, 2 CPU), Montreal, dans lequel j’ai mis 2 disques de 2To en RAID, et j’ai commencé à migrer mon infrastructure dessus. J’ai également pris un 4ème VPS, Amber, également chez Contabo, pour me servir d’ip externe, en la reliant avec un pont Wireguard vers mon infra.
+-----------+
| |
| Freebox |
| |
+-----+-----+ +------------+
| | |
+------------------+ Montreal |
| | |
| +------------+
| 192.168.1.0/24
| +------------+
| | |
+------------------+ Laptops |
| | |
+---------+ +-----+-----+ +------------+
| | VPN | |
| Amber +------------------+ Gateway |
| | 172.31.0.0/24 | |
+---------+ +-----+-----+
|
| 10.255.0.0/24
|
+-----+-----+
| |
| Servers |
| |
+-----------+
Le serveur gateway me servait de routeur, de DNS et de DHCP grace à dnsmasq. Afin d’éviter de faire du routage asymétrique, et de ne pas trop faire fuiter l’ip publique de ma Freebox, j’ai routé tout le trafic sortant des serveurs à travers le pont VPN. Mais parce que je ne voulais pas m’embêter à faire du source-based routing, j’ai simplement défini deux passerelles différentes pour mes deux réseaux : le réseau “client” utilisait la Freebox comme passerelle, et le réseau “serveur” le serveur gateway. Afin que les clients puisse quand même accéder aux serveurs, je poussais dessus une route statique en utilisant l’option 131 du protocol DHCP ; cependant, cette option n’est pas supportée par Android…
En terme d’automatisation d’infra, j’avais décidé d’utiliser une nouvelle approche, pour pallier aux soucis que j’avais eu avec Ansible sur l’itération précédente. Je suis partie d’un template LXC custom, généré grace à DAB, qui pré-installait et pré-configurait ce que j’aurais déployé par Ansible en tant que configuration initiale (paquets standard, mon compte et ma clé ssh…). Ensuite, je centralisais toutes mes configurations avec Stow dans un monorepo.
Sur chaque nouvelle machine, je commençais par cloner le monorepo à /usr/local/stow-files, puis créer dedans un dossier pour ma machine. Ensuite, je mettais tous les fichiers de configuration modifiés pour cette machine dans ce dossier, en respectant l’arborescence par rapport à /etc, pour pouvoir utiliser stow pour les déployer (ou plutôt, pour créer des liens symboliques aux bons endroits qui pointent vers ces fichiers). L’intérêt principal de cette approche était de pouvoir travailler sur les fichiers du serveur sans me poser de question au quotidien ; si j’avais besoin de rajouter une machine dans la configuration du DHCP, je modifiais directement /etc/dnsmasqs.d/leases.conf, qui était réellement /usr/local/stow-files/gateway/dnsmasq/dnsmasq.d/leases.conf. L’inconvénient était de n’avoir aucune visibilité sur si j’avais bien push toutes les machines…
Lors de cette itération, j’ai également commencé à m’intéresser à NixOS, que j’ai également utilisé sur mon PC principal pendant quelques mois. J’ai envisagé de me faire une infrastructure principalement basée dessus, pour au final rester sur une majorité de Debian. J’ai tout de même conservé quelques LXC sous NixOS, principalement pour gérer le reverse-proxy de mon infrastructure avec Nginx.
Enfin, l’infrastructure était monitorée grâce à une stack Grafana + Prometheus + Netdata, installé sur tous mes serveurs et LXC.
Malgré le but initial de ce serveur, qui était de remplacer tous mes VPS (sauf Amber), je ne les ai résiliées qu’en mai 2024, plus d’un an après la mise en production de Montreal.
Troisième itération : 2024-?
Le problème principal de ce serveur était très prévisible : il consomme beaucoup, et chauffe pas mal aussi (ou plutôt, devient très bruyant pour ne pas chauffer…). Pour réduire très fortement son bruit au repos, j’ai retiré dès le départ le contrôle automatique de la vitesse des ventilos, pour les mettre à 10% de leur vitesse maximale (contre 30% au minimum en automatique), ce qui suffisait largement à mes besoins. Mais en ayant retiré tout contrôle automatique de leur vitesse, je gardais un stress qu’il se mette à trop chauffer et à s’abimer, voire à abimer mon appartement… Et sa consommation était très loin d’être négligeable : 120W dans le BIOS, 150W avec mon infrastructure au repos (et facilement 180W avec une CI qui tournait), soit environ 35€/mois d’électricité… Soit le prix combiné de Zii, Didi et Izz.
J’ai donc décidé en août 2024 de le remplacer par un serveur monté moi-même, avec des composants de PC (plus de détails ici), Gandalf. J’en ai également profité pour acheter un routeur physique (un EdgeRouter X), Cirdan.
+-----------+
| |
| Freebox |
| |
+-----+-----+
|
|
|
|
| 192.168.1.0/24
| gw.chapo.li
|
|
|
+---------+ +-----+-----+
| | VPN | |
| Amber +------------------+ Cirdan |
| | 172.31.0.0/24 | |
+---------+ wg.chapo.li +--+--+--+--+
| | |
| | |
| | |
| | |
| | |
+---------------+ | +---------------+
| | |
| | |
+-----+-----+ +-----+-----+ +-----+-----+
| | | | | |
| Clients | | Hardware | | Servers |
| | | | | |
+-----------+ +-----------+ +-----------+
10.255.1.0/24 10.255.2.0/24 10.255.3.0/24
client.chapo.li hw.chapo.li vm.chapo.li
Plutôt que d’utiliser un nom de domaine unique pour toutes mes ip (en .home), j’ai décidé d’utiliser un sous-domaine d’un domaine public par sous-réseau, ce qui me permet également de générer des certificats TLS valides.
EdgeOS me permet également d’enfin faire du source-based routing sans effort, ce qui me permet enfin d’avoir proprement uniquement les serveurs qui sortent par le VPN, tout en pouvant facilement définir des exceptions (par exemple, mon runner Forgejo n’utilise pas le VPN, à cause d’un soucis que je n’ai jamais réussi à comprendre avec le pull de dépendences Ruby…).
En terme de gestion de la configuration des serveurs, je suis revenue sur Ansible, avec des playbooks plus simples et plus standards qu’à l’époque de la première itération. Au lieu de chercher à ansibliser tous mes services, je n’ansiblise que les structures récurrentes (déploiement des utilisateurs, installation de docker, configuration de cerbot avec challenge DNS…), ainsi que quelques services plus complexes (comme la stack mail). Pour les autres services, qui sont généralement un docker-compose.yml et un éventuel fichier de configuration, ainsi que pour le routeur, j’utilise un simple script bash qui scp les fichiers pertinents, puis je git le résultat. Peu élégant, mais efficace.
#!/bin/bash
echo -e "[cirdan.hw.chapo.li]"
scp ubnt@cirdan.hw.chapo.li:/config/config.boot cirdan.hw.chapo.li/config.boot
...
Oui, ce repo contient beaucoup de secrets en clair. Oui, il est privé et protégé. Oui, ce n’est pas très propre…
Afin de gérer l’accès à mes services depuis l’extérieur, j’utilise deux serveurs : Amber, mon VPS externe, qui utilise un firewalld pour gérer un NAT Masquerade et le port-forward vers les machines pertinentes à travers un pont Wireguard vers Cirdan, et Dillon, mon reverse-proxy Nginx sous NixOS. C’est lui qui s’occupe de distribuer les requêtes vers les services pertinents, et de faire la terminaison TLS pour mes services externes.
Enfin, pour gérer les mises à jour des machines, j’utilise, en plus de unattended-upgrades, apt-dater.
Apt-dater est très peu disponible sur d’autres plateformes que Debian et ses dérivés, et n’est plus vraiment maintenu par d’autres personnes que les mainteneurs de Debian… Pro tip si vous voulez l’utiliser depuis un Arch par exemple, il tourne très bien dans un Docker !
Je suis pour l’instant très satisfaite de cette nouvelle itération, qui me parait beaucoup plus robuste et facile à maintenir que les précédentes. À voir sur la longueur !