L'auteur décrit la refonte de son infrastructure DNS pour éliminer les points de défaillance uniques (SPOF) et améliorer la résilience. Son ancien setup, basé sur un seul conteneur LXC combinant AdGuard Home et NPM, souffrait d'un manque de redondance et d'une résolution inefficace des noms de domaine locaux, générant du trafic inutile via le NAT (hairpin). La nouvelle architecture sépare les rôles en quatre composants : Technitium DNS Server pour la gestion des zones DNS locales et la haute disponibilité, AdGuard Home pour le filtrage avancé des requêtes, NextDNS comme résolveur chiffré en amont, et NPM pour la gestion des proxy inverses.
Technitium assure la synchronisation automatique entre deux instances, permettant une continuité de service immédiate en cas de panne d'un nœud Proxmox. AdGuard Home, déployé dans un conteneur dédié, applique des règles de filtrage personnalisées par client ou groupe, tandis que NextDNS prend le relais pour les requêtes publiques et offre une protection renforcée hors réseau. NPM, isolé dans son propre conteneur, gère les redirections des noms de domaine locaux et publics sans conflit.
Cette refonte élimine les inefficacités du hairpin NAT et garantit un filtrage cohérent, que ce soit en local ou à distance, tout en assurant une haute disponibilité grâce à la redondance des composants.
Dans ce tutoriel DomoPi, l’auteur montre comment mettre en place une redondance simple pour un broker MQTT Mosquitto : en utilisant Keepalived pour une IP virtuelle partagée entre deux serveurs (un Mosquitto en Docker comme principal et un Mosquitto natif sur Raspberry Pi comme secondaire). Si le serveur principal tombe, l’IP virtuelle bascule automatiquement vers le secondaire, permettant aux clients MQTT de continuer à fonctionner sans interruption (bien que l’état ne soit pas synchronisé car Mosquitto n’a pas de clustering natif).
L'auteur de ce billet critique la dépendance excessive aux géants du cloud pour l'hébergement de sites web, y compris pour les projets personnels. Il argue que l'autohébergement peut offrir une fiabilité suffisante, surtout pour des sites à trafic modéré. Il propose des solutions pour améliorer la résilience, comme la redondance des serveurs DNS, et encourage à repenser la nécessité d'une disponibilité absolue pour les petits projets.
Cet article compare les architectures standalone et haute disponibilité (HA) pour Kubernetes on-premise, en expliquant comment concevoir et opérer un cluster HA. L’article détaille l’importance de redonder les composants critiques (comme l’API Kubernetes) pour éviter les points de défaillance uniques (SPOF), même si cela peut introduire de nouveaux défis (ex. : un load balancer devant les control planes peut lui-même devenir un SPOF). Il présente aussi une solution de stockage HA avec TrueNAS (exposant des volumes bloc via iSCSI) et Longhorn pour orchestrer la réplication, les snapshots et la reconstruction automatique en cas de panne d’un nœud. L’auteur insiste sur la nécessité de bien dimensionner chaque couche (stockage, réseau, contrôle) pour garantir la résilience du cluster, tout en soulignant que la haute disponibilité commence par la redondance du plan de contrôle et une gestion fine des volumes persistants. Le billet s’inscrit dans une série technique explorant les bonnes pratiques pour opérer Kubernetes en production.
Tout est dans le titre
Malgré le titre, l'article explique pourquoi Cozy a choisi de rester chez OVH
Tout est dans le titre