Quelle stack supporte DryCat ?

De plus en plus de personnes me demandent quelle est la base logiciel qui supporte DryCat. Alors pourquoi ne pas la partager avec tout le monde ?

DryCat c'était un peu mon bac à sable qui a pris de l'ampleur et envers lequel je met un point d'honneur àa ce que la plateforme soit stable et professionnelle. Alors, certe professionnelle dans un contexte où je suis seul à gérer une infrastructure de 23 serveurs (VPS et dédié confondus) ce n'est pas la même chose qu'une infrastructure gérée par 15 personnes pour 700 serveurs. Mais chaque outil choisi l'a été après beaucoup de tests. C'est pour cela qu'après presque 2 ans j'ai pu ressortir un cahier des besoins complets.

Avant même que je commence, je vais éclaircir une confusion pour bon nombre de personnes (moi y compris au début) : « La supervision n'est pas de la métrologie et vice versa ». Oui, je sais, ça choque, mais ces deux concepts sont totalement différents !
La métrologie permet de voir des tendances, l'évolution d'une certaine valeur (par exemple l'utilisation de l'espace disque ou l'augmentation de la charge CPU), le tout dans le temps. Ça permet d'alerter en cas de dépassement de seuil d'un calcul. Par exemple « si l'espace disque utilisé augmente de 70% en 4h c'est qu'il y a un problème, donc il faut alerter ».
La supervision permet d'analyser au moyen d'une sonde une valeur à l'instant T (par exemple l'espace disque) et alerter au besoin. Par exemple « l'espace disque de mon serveur est occupé à 95% alors il faut alerter ».

Quels sont les contraintes ?

Au vu du financement de DryCat (dons), il me fallait une solution :

• économique
• libre
• respectueuse de la vie privée (donc loin des GAFAM)
• qui permet de pouvoir exporter et importer une machine d'une infrastructure à une autre en cas de migration avec le moins de temps possible
• fiable
• évolutive

Donc déjà, exit des solutions Cloud types AWS, Azure et autre truc, car en plus du côté GAFAM le prix est super élevé !
Ce qui répondait au côté économique c'était les VPS. Pas cher, pas de ressource inutile. Mais par contre l'espace disque on oublie. Et avec Mastodon et ses 400Go de fichiers sur à peine 3 mois, les VPS c'est mort.
Mais les VPS ont leurs avantages. Une limitation des ressources et une isolation des applications. On peut aussi noter que lors d'une mise à jour c'était pas toute l'infrastructure qui était par coupée mais un seul VPS. De plus une migration de VPS (enfin VM au final) se fait plus facilement qu'avec un serveur dédié.

J'ai donc pris comme base Proxmox. Comme ça je peux ajouter d'autres serveurs au cluster assez facilement. Je peux importer et exporter des VMs facilement également. Et c'est fiable et puissant (à condition de bien lire la documentation).

Autre point positif de Proxmox, c'est la gestion de cloud-init. Avec le bon template ça facilite la création de la machine. Et c'est pratique aussi lorsqu'on a besoin de couper une machine, celle-ci se met à jour au démarrage.

Vous avez d'ailleurs peut-être pu le lire, j'ai modifié la configuration des disques des VMs pour réduire l'IOwait et écrire de façon asynchrone sur les disques (écriture d'abord en RAM, puis sur le disque). J'utilise unsafe pour les serveurs dont la perte de données est négligeable (par exemple le serveur hébergeant les applications statiques, ou qui n'ont aucune donnée sur le disque, tout est sur le serveur MySQL). J'utilise writethrough pour les services dont la perte de données peux être critique (par exemple perdre une transaction MySQL peut poser de grave problème ensuite). Et writeback pour les services dont la perte des données n'est pas critique mais dommageable, c'est le mode équilibré entre cache RAM et écriture disque.

Mais DryCat ce n'est pas que Proxmox

DryCat ce n'est pas que des VMs avec des applications sur un serveur Proxmox. C'est aussi tout un écosystème qui vise à prévenir les pannes, les réparer ou déployer les mises à jour ainsi que les configurations.

Pour prévenir les pannes, rien de mieux que de la métrologie ! Et il fallait que celle-ci soit fonctionnelle, peu gourmande en ressources et facilement maintenable.

J'ai essayé, il fut un temps, une stack TICK (Telegraf, InfluxDB, Chronograf et Kapacitor). Le soucis est que chaque mise à jour de Telegraf demandait d'écrasait le fichier de configuration de ce dernier. Et puis la gestion des graphiques dans Chronograf ce n'était pas ça.
Les conseils de @Valère et avec un article de @Dada m'ont dirigé vers la solution Prometheus (pour le serveur de metrologie) et Grafana (pour le front-end (sans lui, pas de joli graphique)).
Simple à installer, simple à maintenir, beaucoup de plugin, très pointu. Bref, les outils de métrologie parfait.

Avec une bonne métrologie, il faut une supervision. Et là le choix fut difficile.
Il fallait une supervision :

• Scalable (afin de pouvoir ajouter plein de serveur)
• Qui ne spam pas la boite mail
• Facilement maintenable
• Facilement paramétrable
• Avec des sondes facile à créer
• Qui peut effectuer des actions basique avant de m'alerter

J'ai tenté Shinken qui fonctionnait mais pas d'action en cas d'alerte, Icinga et Alignak semblaient être des purges à installer, et donc à maintenir.
Au final je me suis souvenu que Olympe Network utilisait Zabbix. Après quelques tests je l'adopte. La création de machine est simple, les sondes pareil. Il y a 7 niveaux d'alerte (pratique pour savoir si ça attend ce soir ou si je dépanne ça d'urgence depuis mon téléphone). Et bien sûr, Zabbix exécute des actions avant de me prévenir (par exemple crash de Lutim, il va le redémarrer).
(Photo prise sur Wikipedia vu que j'ai pas d'alerte de mon côté).

Le sujet critique : les backups.
Il me fallait un outil gérant les sauvegardes, faisant de l'incrémental car un disque coûte cher, pouvant synchroniser via SSH.
Au final j'ai utilisé Borgbackup, capable de gérer les sauvegardes incrémentales, synchronise tout sur mon serveur de stockage à la maison. C'est pas compliqué à installer, à configurer. J'ai même pu déployer les sauvegardes via un script Ansible. Seul inconvénient je n'ai pas d'interface graphique mais ce n'est pas dérangeant.
Cependant les sauvegardes via Borg ne sont que des sauvegardes fichiers. La base de données PostgreSQL est sauvegardée via pgbarman qui est certe complexe à gérer mais il n'y a plus besoin de faire un pg_dumall qui va prendre de la place inutilement sur le disque. Et restaurer un backup en cas de crash du serveur PostgreSQL est plus simplifié à mon sens.
Je n'ai malheureusement pas trouvé de telle solution pour MySQL.

Le déploiement des applicatifs et les mises à jour étaient mon dernier gros chantier. Fini en février dernier (mais en amélioration constante), cela me permet de déployer des applications rapidement et surtout de gérer les mises à jour. Globalement Ansible me permet de créer rapidement des machines, d'installer tout un tas d'applicatif, et de les mettre à jour en passant le moins de temps possible.
Par exemple la mise à jour de 4 blogs Ghost c'est une commande :

ansible-playbook -i hosts ghost.yml

L'audit des configurations ainsi que le maintient en conformité de ces dernières sont gérés par Rudder.
Déjà qu'est ce que c'est qu'un outil « d'audit de configuration et de maintient en conformité des configurations » ? C'est tout simplement un outil qui possède plusieurs règles (par exemple les utilisateurs devant être impérativement présents, ainsi que leurs clés SSH, la gestion de la configuration SSH, la liste des paquets qui doivent être installés, la liste des utilisateurs sudo, etc...). En mode audit, Rudder signale les divergences des serveurs. En mode enforce, il écrase les divergences et fait en sorte que la configuration demandée soit la même sur chaque serveur. De ce fait aucun serveur n'a une configuration système différente.

Mais DryCat c'est aussi des mails gérés par l'image de Hardware. C'est également deux serveurs DNS authoritaires (NSD) master-slave (désolé, c'est encore le nom technique donné), dont l'un est hébergé sur le cluster Proxmox, l'autre sur un VPS chez Scaleway. C'est en plus un serveur DNS resolver (Unbound), utilisé par toutes les VM, qui valide DNSSEC (mais qui ne modifie pas le minimum TTL (à mon plus grand regret) pour éviter de créer des problèmes de communication entre les instances Mastodon). Et pour finir c'est goaccess pour lire les logs et un Nginx compilé à la main, configuré aux petits oignons pour virer plein de choses inutiles (comme tls 1.0) en utilisant openssl 1.1.1c (donc TLS 1.3).

Pour résumer DryCat c'est :

• Deux serveurs dédiés tournants sous Proxmox qui héberge 18 machines
• Un serveur de sauvegarde et de supervision chez moi (un vieux PC recyclé avec un RAID 5)
• Un VPS qui s'occupe des mails
• Un VPS qui sert de serveur DNS secondaire
• Zabbix pour la supervision
• Prometheus + Grafana pour la métrologie
• Ansible pour le déploiement et les mises à jour
• BorgBackup pour les sauvegardes
• Rudder pour l'audit et certaines configurations ainsi que le maintient en conformité de ces dernières.

Couverture par Stef Westheim sur Unsplash
Correction par Von