Accueil
Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
Nouvelle année, nouveau format - au programme une édition mensuelle mixant brèves et des choses plus construites/élaborées (j'espère le mois prochain)
logger
et de ansible.cfg
\watch
ou jsonb_pretty
pour respectivement surveiller le résultat d'une requête et affichrer proprement une donnée au format JSON.Bonnes fêtes de fin d'année à tous !
npm
, se voulant plus fiable et prédictive (voire idempotent ?) pour le contenu de node_modules
, plus rapide (parallélisation et cache hors ligne) et plus sûr avec des mécanismes de contrôle de signature de fichiers. yarn
reste compatible avec npm
et son registre.loose_
, alors au lancement, MySQL va ignorer cette option si elle ne la connait pas. Le billet donne pour cas d'exemple la mutualisation d'un fichier de configuration entre la version MySQL de Percona (qui a ses propres variables) et celle de MySQL ou encore l'anticipation de la mise à jour de MySQL qui permet de déployer un futur fichier de configuration sans craine l'arrêt du service.favicon
de leur site. L'exmple est connu mais bien expliqué. Il en est de même pour les polices (fonts) hébergées chez Google & co et plus généralement pour les ressources distantes. Toutes les ressources distantes ne vont pas donner le même volume d'information mais a minima, on a votre IP, la date et le site source... Dans la mesure du possible et pour protéger vos utilisateurs, pensez à rappatrier les ressources distantes sur votre site.Il y a de cela une dizaine de jours, la partition système d'un serveur d'un de nos clients est passé en lecture seule suite à un problème de consistence sur le disque. Pour les services en cours et ne dépendant pas de fichiers sur cette partition, les services continuaient de fonctionner. Pour les autres, ils étaients hors service ou dans une situation de dsyfonctionnement dès lors qu'ils avaient besoin d'écrire un fichier sur la partition système.
Pour rétablir le service dans les plus brefs délais et investiguer ce problème dans un second temps, nous avons décidé de créer un nouveau serveur, de lui attacher les données et l'IP du serveur hors-service. Cette opération a été grandement facilitée vu que nous utilisons dans ce cas l'offre IAAS de Gandi : en quelques clicks, un nouveau serveur a été provisionné, et les disques contenant les données et les backups ont été attachés au nouveau serveur.
Vient alors Ansible : grâce aux playbooks, préalablement rédigés par nos soins, pour installer l'ensemble des logiciels et le paramétrage associé des serveurs de notre client, le serveur était opérationnel dans les 15 minutes. Quelques tests plus tard, nous pouvions alors migrer l'IP de l'ancien serveur vers le nouveau et rendre le site à nouveau accessible au bout de 30 minutes environ.
Malheureusement, toutes les modifications et quelques actions n'étaient pas encore reportées ou rédigées dans nos playbooks. L'heure suivante a donc consisté à rattrapper ces informations et jouer les actions manquantes. Depuis lors, elles ont été réintégrées dans les playbooks .
Au final, en 1h30 après décision de reconstruire le serveur, le service était totalement rétabli et avec un retour partiel au bout de 30 minutes environ. Si nous avions du rejouer toute l'installation à la main, cela aurait durer bien plus de temps et avec des risques d'erreurs / oublis non négligeables et sans parler du doute persistent : a-t-on bien tout récupéré ?
Un crash serveur est une situation stressante pour tout le monde ; il est agréable de pouvoir compter sur un outil comme Ansible pour garantir l'état final d'un serveur (prédictibilité). Cela apporte une certaine sérénité et permet de rétablir le service au plus vite pour le bien de tous. Au-delà du premier déploiement, cela requiert une certaine hygiène de vie du serveur pour maintenir les playbooks à jour.