Panne d’internet, pas de site web

Jeudi dernier étant férié et les enfants n’ayant école que 4 jours par semaine, on finissait sereinement ce week-end a rallonge lorsque la connexion fibrée nous a lâché, dimanche vers 16h. Heureusement, la connexion de secours a pris le relais et nous sommes restés connecté au cyberespace.

Sur le coup, j’admet avoir ressenti une certaine fierté à voir les mécanismes de secours se déployer automatiquement et faire leur boulot comme prévu. Je me rappelle de toutes ces coupures réseaux qui m’ont pourri la vie en entreprise alors j’apprécie vraiment lorsque ça nous arrive aussi et qu’on reste connecté quand même.

Comme ces coupures sont généralement assez courtes (la plus longue a eu lieu en 2007 lorsque nous avions du éteindre germaine, notre pare-feu de l’époque, pour pouvoir faire une raclette), nous n’avions encore rien fait pour l’hébergement du site des arsouyes. On partait du principe que le site pouvait rester inaccessible une heure (ou une dizaine) et on était satisfait du statu quo.

Mais ce matin, on a du reconnaître que cette coupure serait plus longue que les précédentes et qu’on ne pouvait pas vous laisser, cher public, dans l’expectative. Et comme toujours, ce n’est pas les solutions qui manquent, il faut juste trouver la plus adaptée.

Nous avons d’abord pensé à basculer le site sur la connexion de secours. Les redirections de ports étant déjà faites, il suffirait d’une mise à jours des serveurs DNS. Le TTL n’étant que d’une heure, le délais est raisonnable. Le problème est que cette méthode est manuelle.

On s’est donc posé la question de l’automatisation des bascules DNS. Mettre plusieurs IP n’est pas adapté (c’est fait pour répartir la charge). Il faudrait donc faire nos propres scripts de monitoring puis ceux de mise à jours des DNS (i.e. via l’API de notre registraire - de registrar en anglais, d’après l’Office québécois de la langue française, on aime, on adopte). C’est de l’investissement et comme la plupart des coupures sont plus courtes que le TTL, le retour sur investissement n’est pas gagné.

Autre solution d’automatisation, mais sans toucher aux DNS, utiliser un reverse proxy en amont. Ce serait alors lui qui basculerait le trafic d’une connexion à l’autre (donc d’une adresse IP à l’autre) automatiquement. Pas besoin de scripter, il suffirait de configurer apache. Par contre, il faudrait un serveur externe avec sa propre IP (et à ce compte là, il faudrait aussi le redonder…). Pour un site web statique de 40 Mo, c’est peut être trop d’infrastructure.

Alors, quitte à utiliser un serveur externe, autant se tourner vers un hébergeur. En gestion des risques, on appelle ça de l’externalisation. Ça n’est plus notre problème. Pour moins de 2€/mois, c’est OVH qui s’occupera de ces histoires de disponibilité.

Nous avons donc passé une partie de la journée à cette migration : copie des fichiers, configuration des DNS puis SSL. Et une autre partie à adapter notre CI/CD pour déployer chez l’hébergeur automatiquement.

Ce soir, la fibre n’est toujours pas opérationnelle, nous sommes toujours sur la connexion de secours, mais le site est de retour pour votre plus grand bonheur.