Auto-hébergement – Page 2

Unicoda a brûlé !

Amis lecteurs bonsoir !

Étrange journée que cette journée du 10 mars 2021, car, s’il y a bien un risque qu’on envisage pas immédiatement pour son serveur, lorsqu’on fait la liste des périls qui le guettent, c’est celui de l’incendie. Eh oui, en ce mercredi 10 mars 2021, Unicoda, où plutôt son serveur de résidence, est parti en fumée avec le reste des serveurs et des sites hébergés dans le datacenter SBG2 d’OVH à Strasbourg.

Pour Unicoda, plus de peur que de mal, puisque si vous lisez ces lignes, c’est que nous sommes (déjà) de retour. C’est bien sûr un événement dont tout le monde se passerait. J’ai pu voir quelques annonces de données irrémédiablement perdues, par exemple, du côté des serveurs du jeu Rust. Un événement qui démontre encore une fois, l’importance des sauvegardes, et que, même en environnement contrôlé, personne n’est à l’abri.

Voici donc un petit retour pour décrire la façon dont nous avons réagi à cet incident.

Tout commence ce matin vers 10h, lorsque mon frère Mathieu m’appelle au téléphone, en me demandant où est hébergé Unicoda dans les infrastructures OVH. Il continue en m’annonçant qu’il vient de lire qu’un incendie s’est déclaré dans le datacenter SBG2, que tout SBG est à l’arrêt et que Unicoda ne répond plus. Je lui confirme qu’Unicoda est bien hébergé à Strasbourg dans SBG2 et vérifie rapidement la connexion au serveur (en échec bien sûr). Vérification dans mes mails, pas de rapport journalier de sauvegarde ce matin, le feu s’étant déclaré peu avant le processus de sauvegarde automatique.

Je prends ensuite un peu de temps pour réfléchir. Je suis à 80% sûr qu’Unicoda était hébergé dans SBG2, rien dans la console d’administration d’OVH ne permet de valider l’information, rien sur les factures. Le rapport de sauvegarde du 9 mars indique qu’il s’est terminé avec succès. Enfin, SBG est à l’arrêt pour plusieurs jours, voir semaine, il faut donc préparer le redéploiement d’Unicoda sur un nouveau serveur. Profitant d’une pause dans ma matinée de travail, je commande donc un nouveau VPS OVH dans le datacenter de Gravelines.

Arrive le temps de la pause méridienne. Le VPS n’étant toujours pas disponible, je commande un VPS chez Hetzner en Allemagne, VPS facturé à l’heure avec un plafond mensuel, extrêmement pratique pour effectuer des tests de courtes durées. Livraison en moins d’une minute. J’ouvre le dépôt contenant mon script de déploiement automatisé ansible, change les DNS pour pointer vers la nouvelle machine et démarre l’exécution. Quelques erreurs du fait d’une réorganisation récente de l’ensemble de mes rôles ansible (et dont les tests devaient avoir lieu dans les prochains mois) interrompront deux fois la réinstallation. Au troisième essai, après quelques dizaines de minutes, Unicoda est à nouveau accessible.

Quels enseignements retenir de cet incident ?

Comme énoncé déjà ici: sauvegarder, sauvegarder et sauvegarder !! Je suis une nouvelle fois très satisfait par la solution de sauvegarde et de déploiement automatique que j’ai mise en place pour Unicoda et qui est le résultat de plusieurs années d’améliorations. Néanmoins, il serait bon d’ajouter un deuxième emplacement distant de stockage des sauvegardes. En effet, si par un hasard extraordinaire, un problème similaire était arrivé au datacenter stockant la sauvegarde chiffrée, c’eût été retour à la sauvegarde enregistrée sur mon poste local et pouvant parfois remonter à plusieurs semaines. Un emplacement distant pour les sauvegardes, c’est bien, deux, c’est mieux.

Deuxième point à noter, en cas de réorganisation complexe des scripts de déploiement automatique, il aurait été utile de conserver une copie du dépôt avant réorganisation, lorsque les scripts fonctionnaient sans erreurs et avait été testé. Ainsi, on s’évite quelques corrections en état de stress et pressé par le temps. Cela est bien entendu variable en fonction du service affecté, dans le cas d’Unicoda, je ne suis pas à la minute près, bien que j’apprécie d’avoir le moins de temps d’indisponibilité possible.

Enfin, j’ai apporté des modifications sur le Time To Live (TLL) du champ A des DNS d’Unicoda, entrée DNS responsable de la redirection vers le serveur. J’avais jusqu’à présent laissé ce champ à la valeur par défaut dans l’interface à savoir 86400 secondes soit 1 jour. Si cela ne pose guère de problèmes dans le cas d’une migration programmée, où l’ancien serveur continue de fonctionner quelques jours, c’est plus embêtant dans le cas d’un incident comme celui d’aujourd’hui, où on voudra que la modification DNS soit propagée le plus rapidement possible une fois le serveur de remplacement opérationnel. J’ai donc choisi une valeur de 7200 secondes (2 heures) de TTL, ce qui me semble être un bon compromis.

En conclusion, Unicoda s’en sort bien, plus de peur que de mal. On a beau avoir un processus de sauvegarde, des scripts de déploiement automatique, un léger doute subsiste toujours. Cet incident a permis de vérifier, en dehors d’un événement programmé, que les processus mis en place fonctionnent: une très bonne chose. Il me reste à vérifier dans les prochains jours que la sauvegarde s’effectue correctement sur ce nouveau serveur et, dans les prochaines semaines, à migrer une nouvelle fois Unicoda pour un retour chez OVH. A tous mes camarades informaticiens ayant perdu un serveur dans cet incendie: courage !

P.S. Pour suivre l’avancement de la remise en service, voici les tickets liés à l’incident:

Si nut ne détecte pas l’onduleur

En redémarrant mon Pi connecté à l’onduleur, après avoir éteint l’onduleur et le Pi, débranché câbles et alimentations, et déplacé les deux appareils, j’ai constaté à plusieurs reprises que l’onduleur n’était pas détecté après un redémarrage du système.

Je n’ai pour l’instant pas trouvé de meilleur solution que de redémarrer manuellement les services nut-monitor et nut-server, ce qui suffit à résoudre le problème.

$ sudo service nut-monitor status
$ sudo service nut-monitor restart
$ sudo service nut-server status
$ sudo service nut-server start

Par ailleurs, en écrivant ces lignes, je me rends compte que cela pourrait provenir de l’ordre de branchement des câbles, avec un branchement du câble de connexion à l’onduleur, qui arriverait après la tentative d’initialisation des services, car généralement, l’extinction de la machine liée à l’onduleur s’accompagne d’un déplacement de cette dernière et donc d’un débranchement de tous les câbles connectés.

En tous cas, si vous avez trouvé une solution à un problème similaire, n’hésitez pas à la partager, sinon, la solution manuelle est placée ci-dessus pour référence.

Note: Suite à une migration récente, nut-monitor n’est pas installé et tout semble fonctionner. Redémarrer nut-server devrait donc suffire, ou à défaut, nut-client dans le cas d’une machine cliente.

acme.sh en mode test

Petite note, pour mettre en avant l’option test de acme.sh, qui permet d’envoyer toutes les requêtes d’obtention d’un certificat Let’s Encrypt vers les serveurs de test, et non vers ceux de production. Incontournable lorsque l’on teste l’exécution de scripts de déploiement automatique et que l’on se retrouve à demander plusieurs fois un certificat wildcard dans la même journée, pour un même domaine, et que l’on atteint de ce fait les limites en nombre de création/renouvellement du service.

--test

Une autre solution, si l’on se contente de relancer le script de déploiement plusieurs fois, après avoir corrigé les étapes en erreur et sans reprendre le déploiement sur une machine vierge, consiste à vérifier l’absence des fichiers de certificats avant de faire une nouvelle demande de certificat.

Source: Acme.sh supports ACME v2 wildcard now

Petit calcul de coût en électricité pour l’auto-hébergement

En recevant ma dernière facture d’électricité, je me suis demandé quelle proportion, quel montant de la facture, provenait de la consommation électrique du Pi que j’utilise pour m’auto-héberger. Le but du calcul était également d’estimer le nouveau coût en cas de changement pour une machine assemblée pour l’occasion, plus puissante, et qui consommerait en moyenne 32Wh. Cette valeur de consommation s’appuie sur celle mesurée sur une ancienne machine que j’avais assemblé, à base de Core 2 duo et de RAM en DDR2. Pour la consommation du Pi (Modèle 3 B), j’utilise la valeur de 5Wh, mesurée sur un intervalle de presque deux mois. À noter qu’un maximum de modules sont désactivés du côté du Pi, comme la sortie HDMI entre autres, afin de réduire l’énergie utilisée. Passons maintenant au calcul.

J’effectue le calcul de coût pour une durée d’un mois de fonctionnement. Je choisis de me baser sur des mois de 30 jours et demi, soit 24 × 30,5 = 732 heures. J’obtiens donc pour le Pi, 3660 Wh, soit une consommation sur un mois de 3,66 kWh. Pour l’autre machine imaginaire, 23 424 Wh, soit 23,424 kWh.

Posons maintenant le prix de l’électricité en ce début d’année 2020.

kWh : 0,0965 €
TCCFE : 0,006545 €
TDCFE : 0,003273 €
CSPE : 0,0225 €

Soit un total par kWh de 0,128818 euros. Continuons le calcul pour obtenir le prix hors taxe.

Pour le Pi : 3,66 * 0,128818 = 0,47147388 € HT, soit après application de la TVA à 20% (* 1,20), nous donne le chiffre de 0,565768656 €.
Pour la machine imaginaire : 23,424 * 0,128818 = 3,017432832 € HT, soit après application de la TVA à 20% (* 1,20), nous donne le chiffre de 3,620919398 €.

Après calcul, j’aurais pu m’épargner le deuxième calcul et appliquer un facteur de 6 environ entre la consommation des deux machines, au coût obtenu pour le Pi.

Quel constat pouvons-nous maintenant effectuer ?

Tout d’abord, je trouve le coût en consommation électrique du Pi plus que correct, puisque nous restons en dessous d’un euro. En passant à une machine plus puissante, la facture augmente et la pertinence de conserver une telle machine à domicile, plutôt que de louer un serveur chez un hébergeur entre davantage en ligne de compte, si on ne considère que la question du prix (Chez OVH, premier prix VPS 3,60€ TTC, premier prix serveur Kimsufi 4,79€ TTC au 2 juillet 2020).

Rien de bien surprenant quand on y pense, mais ces quelques chiffres permettent d’affiner l’architecture cible de la solution d’auto-hébergement vers laquelle on souhaite se tourner. Je ne suis pas certain que le coût électrique soit parmi les facteurs principaux pris en compte au moment du choix, mais c’est indéniablement une composante du coût mensuel de l’hébergement à domicile. De mon côté, les facteurs principaux restent, entre autres, l’indépendance et l’assurance de la propriété de mes données; avec tous les risques que cela comporte.

Auto-hébergement, le retour

Au détour d’un coin de web, je suis tombé par hasard sur un article sur serveur410 demandant des retours d’expérience autour de l’auto-hébergement. L’article de synthèse ayant été publié quelques jours après que j’ai pris connaissance du premier et avant que j’aie eu le temps de commencer à écrire, j’en profite donc pour produire ici un article dédié au sujet et qui me permettra, par la même occasion, de faire un bilan de ses quelques années d’auto-hébergement. Entrons dans le vif du sujet.

Mon aventure de l’auto-hébergement commence en même temps que les prémices d’Unicoda, durant les rencontres mondiales du logiciel libre 2011 à Strasbourg. C’est à ce moment-là que, conférence après conférence, discussion après discussion, atelier après atelier, je prends la décision de me lancer dans l’aventure pour créer mon bout d’internet. Les motivations sont variées, mais le premier objectif est de disposer d’un espace de publication que je contrôle et où les données m’appartiennent. L’autre élément clé de l’histoire: ma soif d’apprendre. Après deux années de classes préparatoires, pendant lesquelles j’ai laissé de côté mon apprentissage de la programmation et mes expériences avec PHP et MySQL, commencés au lycée en autodidacte (l’option informatique en CPGE étant plutôt dédié à la résolution ou l’analyse de problèmes mathématiques avec l’outil informatique, que de la technique informatique), j’ai décidé de m’engager dans un cursus d’ingénieur en informatique, et enfin, plus simplement, le sujet m’intéresse et me passionne.

Il faudra néanmoins attendre début 2012, pour que je pose les premières pierres d’Unicoda. Achat du nom de domaine, location d’un serveur chez RedHerberg (association qui proposait à des formules d’hébergement très accessible financièrement pour débuter), installation et déploiement de WordPress, configuration d’un serveur web, modification de zone DNS, autant d’éléments à apprendre au fur et à mesure.

Dans les années qui suivront, Unicoda migrera vers OVH sur un serveur Kimsufi avec davantage de puissance et de mémoire. Ce serveur me permettra de continuer mes expérimentations: sous-domaines, installation d’Owncloud, mise en place de certificats HTTPS sur l’ensemble des domaines avec StartSSL et test de nombreux services pour construire ce que je désigne comme mon nuage de services auto-hébergés. De nombreux articles témoignent de ces essais et de cet apprentissage progressif et des évolutions de l’ensemble au fil des ans.

Avance rapide quelques années plus tard, je décide de pousser l’expérience plus loin et d’héberger l’ensemble des services chez moi, à l’exception d’Unicoda, qui reste comme service unique sur une machine virtuelle chez OVH, afin de garantir une certaine disponibilité de service et de disposer d’une généreuse bande passante (bien davantage que l’upload de ma connexion ADSL à ce moment là). Je recycle une machine assemblée pendant mes années de lycée et qui sans être très performante, permet de faire fonctionner convenablement les services que j’utilise.

Peu après, je m’intéresse à l’énergie consommée par cette machine et décide que 35 Watts minimum pour une machine majoritairement en mode idle est un peu trop élevé à mon goût (bien que ridicule par rapport à la consommation de mon PC fixe en utilisation). Je migre donc l’ensemble vers un Pi 3, ordinateur de poche consommant 4 à 5 Watts en mode idle, avec des pics de consommation mesurés à 7 Watts sur une période d’un mois. La facture d’électricité s’allège un peu. Je profite de la migration pour mettre en place un Pi 1 remplissant le rôle de passerelle et permettant de faire cohabiter les deux machines, le temps de migrer chaque service l’un après l’autre.

En parallèle, s’ajoute la mise en place d’une sauvegarde automatique, pour éviter d’effectuer le tout à la main périodiquement, d’abord avec duplicity vers hubic, puis duplicity vers Backblaze B2 et enfin, restic vers Backblaze, avec duplicity version allégé en complément de secours. Une fois la sauvegarde en place, j’ai pu me concentrer sur l’écriture de script de déploiement automatique pour être en mesure de redéployer l’ensemble de mes services rapidement et avec peu d’intervention humaine à partir de la sauvegarde journalière. Plus récemment, cette quête de stabilité a vu l’ajout d’un onduleur au système, pour parer aux éventuels problèmes d’alimentation électrique.

Il est clair que décider de s’auto-héberger, c’est faire le choix de passer plusieurs heures par semaines et parfois par jour, pour installer les services, puis les maintenir, les mettre à jour, les protéger et parfois investiguer les problèmes de fonctionnement. Est-ce que cela en vaut la peine… oui ! Et d’autant plus si vous exercez, ou voulez exercer un métier dans le domaine de l’informatique, ou simplement par intérêt ou passion pour le domaine. L’élément le plus chronophage restant la montée de version des services, surtout lorsque celle-ci est effectuée peu après la sortie de la mise à jour. Pour l’anecdote, j’ai en mémoire une soirée complète passée à mettre à jour Gitlab et déboguer la configuration, alors que le but principal était d’écrire quelques lignes de code sur l’un de mes programmes du moment.

En conclusion, il ne faut pas hésiter à se lancer dans l’aventure de l’auto-hébergement, à condition d’être conscient des enjeux et des responsabilités qui viennent avec. Faire simple, commencer petit et surtout disposer du temps et de l’envie d’apprendre !