Comment l'autohébergement peut-être plus fiable que le Cloud™️
-------------------------------------------------
[19/11/2025] - ~7mins - #auto-hébergement #adminsys
-------------------------------------------------
Vous ne l'avez probablement pas manqué mais cette semaine, Cloudflare s'est pété la gueule.
Le mois dernier c'était AWS et à chaque fois ce n'est pas juste eux mais tout un large écosystème de sites ouaibs qu'ils entrainent dans leur chute.
Et dans les milieux de la techs ça me fait assez rire, *on entend souvent le discours qu'il faut absolument passer par eux pour avoir une bonne disponibilité*.
Pour scaler faut du cloud !
Pour les perfs faut du CDN !
Pour se protéger d'un DDOS faut un proxy !
Le pire c'est que c'est vrai.
- En entreprise, on ne blâmera pas la personne ayant fait le choix de dépendre à 100% de ces grands acteurs*.
Après tout, ça devient le choix de facto avec toute une nuée de conseils, retours d'expérience et d'états de l'art qui érigent ces solutions en évidence absolue.
Du coup comment blâmer quelqu'un qui n'a fait que suivre le discours majoritaire ?
Bref, *on se retrouve sur énorme dépendance qu'on ne remet pas en question*.
De toute façon, quand ça tombe en panne, tous les concurrents tombent aussi en panne donc personne pour nous en vouloir et pas de perte à la concurrence.
Et puis, il suffira d'indiquer au N+X que c'est pas nous, même la presse en parle !
Bon, je peux comprendre ce discours, après tout, en entreprise on est pas là pour se battre pour ses idées contre sa hiérarchie, on est là pour tirer du pognon pour survivre et assurer sa place.
Mais *ce qui m'énerve bien plus, c'est quand les ptits projets persos font ces mêmes choix*.
Là vraiment, ça m'attriste.
Quand une personne monte un ptit site et fait le choix de l'héberger chez github, derrière cloudflare, sur azure, avec du stockage s3 d'aws…
Arg, j'en vomis dans ma bouche en lâchant une ptite larme.
Réellement, se rendre dépendant de ces géants pour ses hobbies, son ptit projet passion, ça me froisse.
- Perpétuer la croyance qu'on ne peut pas faire du web en autonomie sans s'appuyer sur une infra américaine ultra-capitalistique et ayant tendance à traquer les faits et gestes est une hérésie*.
Ça me mine un peu à chaque fois.
Un *petit hébergement basique est à même d'encaisser un énorme trafic aujourd'hui*.
Et *un petit serveur est à même de tourner sans panne pendant des années*.
- Vous n'aurez pas un uptime de 100% mais vous atteindrez aisément les 99%* sans y consacrer tant de temps que ça.
Et puis **pour un blog, une galerie de photo, un portfolio, un site perso, avez-vous vraiment besoin d'un uptime si élevé que ça ?**
Je ne dis pas qu'il n'y a aucune plus-value à un hébergement cloud, un CDN ou ce genre de service.
Mais disons que pour du hobby c'est à mon sens très clairement dispensable.
Mais bon imaginons que l'on veuille rivaliser avec ces colosses (aux confs d'argile) que peut-on faire ?
- *Que pourrais-t-on faire pour rivaliser avec l'uptime des géants du web ?**
Redonder le domaine
Bon première étape, le nom de domaine.
- Le DNS a beau être l'un des plus vieux piliers du net, il a été pensé dès le début pour la redondance.*
Et d'ailleurs, il a toujours été recommandé d'avoir au moins 2 serveurs de noms sur des AS différents.
Dans la majorité des cas, les gens se contentent de l'hébergement de leur domaine par leur registrar.
Mais là, on va blinder un peu le truc.
- On héberge soi-même la zone sur son propre serveur DNS*.
Et pour redonder, on le fait deux fois (ou plus).
Une fois sur le serveur maître et une seconde fois sur une autre machine mais sur un tout autre réseau.
Bien entendu, on configure les deux serveurs pour que le maître pousse ses modifications vers l'esclave.
C'est relativement simple à faire.
- Héberger un serveur DNS ne nécessite quasiment aucune ressource : pas de cpu, pas de ram, pas de stockage.*
La plus petite des machines est à même de le faire.
C'est vraiment un service facile à héberger et souvent relégué au registrar.
Donc une machine à la maison et une autre chez un ami, la famille.
Et si vous n'avez personne, vous pouvez frapper à la porte de FediNS [1] pour trouver des gens prêt à vous épauler et fournir ce second serveur.
Redonder un site statique
La seconde étape c'est votre site.
C'est possible de le faire avec un site dynamique mais comme d'hab c'est bien plus chiant à faire.
- Avec un site statique, quasiment pas de dépendances* : pas de langage serveur, pas de base de donnée, pas de partie mouvante.
- Avec un site statique, vous avez tous vos fichiers et il ne faut qu'un serveur web pour les diffuser*.
Rien de plus, c'est plus simple, plus sécurisé, plus rapide, plus écologique en somme.
Et même les scrapers d'IA malgré leur insistance n'ont qu'un faible impact sur un site statique.
Bref, votre site est généré sur une machine, ça vous donne un tas de fichier, il ne vous reste plus qu'à uploader ça sur le serveur web.
Perso je recommande rsync, mais chacun sa tambouille.
Un scp, un coup de ftp, du webdav, envoi par mail (?!), pourquoi pas par torrent (comme facebook après tout).
Mais comme ici aussi, le but est de redonder, il faut envoyer ça sur deux (ou plus d'ailleurs) serveurs distincts.
Vous pouvez faire ça auprès de deux hébergeurs ou encore une fois, avoir ça chez vous et un proche.
Bon, voilà vous avez uploader votre site sur deux machines différentes, c'est bien gentil mais bon comment faire pour arriver sur l'un ou l'autre ?
Redonder les enregistrements DNS
C'est là toute la magie du DNS.
- Pour chaque enregistrement, vous pouvez avoir plusieurs réponses* !
Vous pouvez faire en sorte que www.votre.site pointe vers plusieurs adresses IP en ayant plusieurs enregistrements A (ou AAAA) :
- www.votre.site. 1800 IN A 1.2.3.4
- www.votre.site. 1800 IN A 2.3.4.5
- www.votre.site. 1800 IN A 3.4.5.6
C'est la répartition de charge du pauvre.
Ça existe depuis 107 ans, ça fonctionne mais il y a maintenant mieux.
Il y a des enregistrements optimisés pour ça qui permettent de spécifier une priorité (comme pour les enregistrements MX) : le **SVCB** et/ou **HTTPS**.
- www.votre.site. 1800 IN HTTPS 1 serveur1.votre.site. alpn="h2"
- www.votre.site. 1800 IN HTTPS 2 serveur2.votre.site. alpn="h2"
- www.votre.site. 1800 IN HTTPS 3 serveur3.votre.site. alpn="h2"
Et hop, en priorité ça tapera sur le premier serveur puis le second et en dernier recours le troisième.
C'est plus propre et fait pour.
Le soucis du TLS
Bon c'est cool vous avez trois machines sur trois réseaux différents prêt à servir le contenu mais nous ne sommes pas des sauvages, il va falloir du TLS.
Et bon, on ne va surtout pas s'amuser à trimballer les certifs d'une machine à l'autre (mauvaise pratique).
Non, on va *juste les générer sur chaque machine quand nécessaire*.
Pour cela, on va utiliser nos cher LetsEncrypt en utilisant le challenge DNS.
On va créer des certifs avec comme nom principal le nom du serveur et en nom supplémentaire le nom global.
En gros on va demander à créer un cert pour serveur1.votre.site en en nom alternatif www.votre.site .
- Sur chaque serveur on pose un ptit dehydrated ou autre client acme du genre, en challenge DNS*.
Chaque serveur a sa ptite clée privée/publique pour modifier les enregistrements DNS qui vont bien.
Et hop, tout automatisé dans un cron, chaque machine à son cert TLS tenu à jour.
Alors alors ?
- Voilà, vous avez une archi redondée pour à peu près pas un sou.*
Vous pouvez vous mutualiser avec un autre auto-hébergeur voir plusieurs pour avoir l'infra la plus redondée possible.
Et hop, **vous allez éclater l'uptime de Cloudflare/Azure/AWS avec un budget famélique**.
Le SPOF d'une telle infra reste le registrar et registry.
Malheureusement c'est assez impossible à outrepasser.
Bon je n'ai pas mis en place une telle infra, c'est plus hypothétique mais c'est techniquement pas si complexe.
Je n'ai pas encore fait mumuse avec les enregistrements DNS de type HTTPS et SVCB mais ça me titille pas mal.
Liens
------------------------------------
------------------------------------
[19/11/2025] - #auto-hébergement #adminsys
------------------------------------