Surveiller l'état du serveur

J’ai un peu compliqué l’installation de mon serveur en répartissant les services dans des conteneurs. J’ai un serveur HTTP NginX en frontal qui distribue les requêtes vers les bon conteneurs en fonction du nom DNS (un reverse proxy). Je me retrouve donc avec une dizaine de conteneurs, partageant un même plan d’adressage IP, et presque autant de serveurs HTTP. J’ai eu besoin d’un outil qui me donne une vision globale de l’état du serveur et soit capable de m’alerter en cas d’incident.

J’aurais pu m’orienter vers des solutions de supervision (Nagios et autres), surtout vu mon background sur le sujet, mais le besoin est simple et les ressources de mon serveur sont limitées. Je n’ai pas jugé utile de dégainer la grosse artillerie. J’avais noté l’existence de Cachet, utilisé, notamment, par Framasoft, qui fournit une page de statut et gère les notifications (e-mail ou abonnement RSS). Cachet, pour les intimes, se cantonne donc à la visualisation et la notification. On crée des composants, on les regroupe à sa guise, et une API Rest permet d’alimenter en événements : changer l’état d’un composant (opérationnel, hors service, partiellement défaillant), déclarer une maintenance planifiée. Il y a aussi des indicateurs mais je n’ai pas encore exploré cette possibilité.

Comme pleurniché dans Diaspora, le plus dur c’est de l’installer, surtout quand je rate la ligne importante du manuel qui précise que PHP 5 est requis (la version 7 n’est pas encore supportée). Je me retrouve avec des erreurs bizarres sans lien évident avec la version (du moins quand on n’est pas PHPiste confirmé). Après une relecture du guide d’installation, plutôt bien fait, et correction de mon déploiement, l’installation se déroule sans problème avec Composer qui télécharge et installe les dépendances. Cachet est prévu pour un grand nombre d’utilisateurs donc une base MySQL ou PostgreSQL est recommandée. Pour peu d’utilisateurs il peut fonctionner avec SQLite, mon choix de prédilection, quand c’est possible, pour ne pas multiplier les serveurs de base de données, ni partager un serveur de base de données entre mes conteneurs.

Une fois installé et la configuration HTTP mise en place, on accède à l’interface d’administration pour créer ses objets. J’ai créé un groupe Système avec tous mes conteneurs et un groupe Service avec mes services critiques.

Cachet Admin

Pour animer les statuts des composants c’est donc indépendant de Cachet. L’API REST de Cachet est bien pensée et bien documentée. Elle permet de créer / modifier des objets ou de les animer. Je me suis limité à cette dernière possibilité pour l’instant en développant un programme qui récupère l’état des conteneurs, des services et envoie les changements d’etat à Cachet. Ce programme est exécuté toutes les 5 minutes. C’est sans prétention et ça répond à mon besoin ; le code source est ici.

Ma page de statut est accessible ici : https://status.madyanne.fr

Pierrot - 2018-02-16 21:43:33

Bonjour,

Pourriez-vous détailler un peu plus ce passage “en frontal qui distribue les requêtes vers les bon conteneurs en fonction du nom DNS” & “ une dizaine de conteneurs, partageant un même plan d’adressage IP, et presque autant de serveurs HTTP” ? Un schéma suffirait probablement à faire comprendre au noob que je suis de quoi il retourne réellement, car par exemple sur mon serveur j’ai aussi Nginx en reverse proxy mais sans comprendre quel serait l’intérêt d’utiliser plutôt une architecture comme la vôtre… Merci !

Yax - 2018-02-17 19:14:49

Pas de noob ici, que des gens qui apprennent :-)

J’ai un conteneur par service DNS ( blogduyax.madyanne.fr, status.madyanne.fr, …), chaque conteneur est un Linux indépendant avec sa propre adresse IP et son NginX.

Au niveau du serveur hôte, celui qui porte l’adresse IP publique, un NginX principal joue le rôle de serveur HTTP principal en distribuant les requêtes en fonction du domaine DNS. Cet article détaille la configuration de NginX en reverse proxy : https://www.it-connect.fr/configurer-nginx-en-tant-que-reverse-proxy

Je ne sais pas si c’est plus clair… on n’a besoin de reverse proxy que si on a plusieurs serveurs Web derrière un accès Internet.

Pierrot - 2018-02-18 01:38:33

Si si maintenant c’est beaucoup plus clair, merci beaucoup ! Donc en fait appliqué à ce que je connais seul Apache se retrouve derrière et servi par Nginx ; auquel se pourraient donc voir adjoints d’autres services… Et par conteneurs, entendez-vous bien en arrière plan l’utilisation de Docker ? Et niveau performances ? Est-ce bien/beaucoup, logiquement, plus gourmant en ressources système ?

Yax - 2018-02-18 15:00:02

Oui derrière, ça peut être une installation à base de docker ou des machines virtuelles ou des conteneurs LXC ou plusieurs machines physiques.

Le coût en performance est peu élevé pour des conteneurs LXC ou Docker : un peu plus de mémoire et et de processeur pour faire tourner un serveur HTTP supplémentaire. Tout va dépendre du serveur principal, si on déploie sur un Raspberry, on ne va pas s’amuser à conteneuriser et probablement rester sur une installation monolithique comme décrit dans mon article précédent : https://blogduyax.madyanne.fr/2018/quel-systeme-serveur

Pierrot - 2018-02-22 19:18:05

Au top cet article merci tout plein, c’est maintenant beaucoup plus clair cette “~mode~déferlante” Docker ^^ !

Votre commentaire
Le site Web est optionel
Le message peut être rédigé au format Markdown