Ce billet explique comment l'auteur utilise FrankenPHP en développement, mettant en avant son mode worker qui maintient une instance PHP active pour éviter les recharges coûteuses à chaque requête. Trois mécanismes de hot reload sont combinés : --watch pour les fichiers statiques, tailwind:build --watch pour les styles, et le worker lui-même, permettant un rechargement instantané du navigateur sans configuration complexe. L'article souligne aussi l'intégration d'un certificat HTTPS auto-signé, accessible via https://localhost:8443 sans modification du fichier hosts.

L'auteur détaille l'architecture de FrankenPHP, un binaire Go combinant le serveur Caddy et PHP-FPM, simplifiant l'infrastructure en un seul processus au lieu de Nginx + PHP-FPM. Le mode worker évite le redémarrage complet de l'application à chaque requête, améliorant les performances en développement comme en production. Le même fichier de configuration est utilisé pour les deux environnements, avec des variables d'environnement ajustant les comportements selon le contexte Docker.

FrankenPHP simplifie l’infrastructure PHP en remplaçant Nginx et PHP-FPM par un seul binaire, combinant serveur HTTP (Caddy) et exécution PHP. L’auteur partage son expérience en production depuis octobre 2025, où quatre sous-domaines sont servis depuis un unique processus, réduisant la complexité DevOps tout en maintenant Symfony. Le mode worker permet de charger l’application une seule fois au démarrage, améliorant les performances, mais impose une vigilance accrue sur les variables statiques ou états persistants, autrefois effacés à chaque requête sous PHP-FPM.

L’optimisation repose aussi sur opcache preload, qui précharge les classes Symfony en mémoire avant l’exécution du worker, accélérant ainsi le démarrage. La configuration se résume à quelques lignes, et l’absence de reverse proxy externe ou de pools FPM par site simplifie la maintenance. Cependant, cette approche déplace plutôt qu’elle n’élimine la complexité, notamment en matière de gestion des états applicatifs.

L’article détaille les gains concrets (un seul binaire, une seule configuration) tout en soulignant les pièges potentiels, comme les fuites de mémoire ou les variables globales persistantes, autrefois neutralisées par le redémarrage fréquent des workers PHP-FPM.

Cet article explique comment configurer un réseau interne pour des machines virtuelles (VM) sous Proxmox dans un homelab monoserveur. L'auteur détaille une solution adaptée aux petits budgets, sans équipement réseau intermédiaire comme des switchs gérant les VLAN. La configuration repose sur un routeur virtuel (conteneur LXC) et des VLAN dédiés directement gérés par Proxmox, simplifiant ainsi l'infrastructure.

La configuration réseau repose sur un schéma en étoile où le serveur Proxmox centralise les VLAN 121 (192.168.121.0/24) et 221 (192.168.221.0/24), connectés au LAN principal (192.168.21.0/24). Le routeur virtuel, intégré au serveur, gère les routes statiques pour permettre l'accès aux sous-réseaux depuis le réseau local ou externe via la box/FAI.

L'approche proposée est idéale pour un usage domestique et pédagogique, mais n'est pas conçue pour des environnements professionnels exigeants. L'auteur partage sa configuration complète, incluant les adresses IP et la topologie, pour faciliter la reproduction par d'autres utilisateurs.

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.

L’article explique comment structurer une architecture logicielle en trois couches (Domaine, Application, Infrastructure) en respectant la règle d’or centripète et le principe d’inversion de dépendance (DIP). L’idée centrale est que les dépendances doivent toujours aller du plus concret (infrastructure) vers le plus abstrait (domaine), jamais l’inverse, afin de préserver l’indépendance et la testabilité de la logique métier.

Le domaine concentre les règles métier, les agrégats (unités cohérentes comme un dossier de demande de subvention) et les value objects (objets immuables sans identité propre). Il définit des ports (interfaces) pour les besoins externes, sans jamais dépendre d’outils comme Doctrine ou Symfony. La couche applicative gère les cas d’usage via des handlers qui orchestrent les flux, tandis que l’infrastructure implémente concrètement ces ports (ex : adaptateurs pour Doctrine ou S3), sans jamais être importée par les couches supérieures.

Cette approche garantit que le métier reste isolé des détails techniques. Par exemple, un handler utilise DepositRequestRepositoryInterface (port défini dans le domaine) sans connaître son implémentation (DoctrineDepositRequestRepository en infrastructure). Ainsi, les changements d’outils n’affectent pas la logique métier, et les imports PHP respectent strictement la hiérarchie des couches.

Deuxième journée orientée vers des retours d’expérience concrets autour de l’IA et de son industrialisation, avec un fil conducteur clair : privilégier des approches pragmatiques, bien dimensionnées et intégrées à l’écosystème existant plutôt que des solutions “tout gros modèle”. Un exemple marquant est l’usage de petits modèles spécialisés (SLM/TLM) combinés à du RAG et une orchestration légère pour gérer un support client efficacement sans explosion des coûts.

Un autre point fort concerne l’“agentic coding” vu comme un sujet de platform engineering : son adoption à grande échelle impose de repenser workflows, gestion du contexte et standardisation via des outils ou marketplaces internes, avec une approche spec-driven (spécifications versionnées lisibles par humains et machines).

La journée aborde aussi des problématiques d’infrastructure à grande échelle (ex. gestion de centaines de millions d’emails) et des réflexions plus larges sur le rôle politique de la tech, tout en restant ancrée dans des retours terrain et des outils concrets pour les devs et ops.

Bearstech partage son retour d’expérience sur l’utilisation de Docker en production, recommandant son usage uniquement dans des cas précis : pour des applications legacy ou imposées par un éditeur (ex: PHP 5), ou pour des outils complexes comme GitLab qui nécessitent un environnement spécifique. En revanche, ils déconseillent fortement Docker pour les bases de données (sauf en développement), en raison des risques de corruption ou d’arrêts brutaux. L’article insiste aussi sur les bonnes pratiques : toujours placer un proxy devant les conteneurs et éviter de donner accès au socket Docker pour des raisons de sécurité. Une lecture utile pour évaluer l’adéquation de Docker à son infrastructure.

L’auteur partage son expérience de refonte de son homelab après une panne matérielle et une organisation chaotique des conteneurs LXC. Son infrastructure, basée sur un NUC Minisforum MS-01 sous Proxmox et un NAS Synology, hébergeait un LXC monolithique regroupant une trentaine de services Docker (dont des doublons comme SearXNG ou BentoPDF), rendant la maintenance complexe. Après une panne nocturne et une carte mère défectueuse, il a profité de la situation pour réorganiser ses conteneurs en appliquant le principe "un LXC, une responsabilité fonctionnelle", améliorant isolation, lisibilité et maintenabilité. Un retour d’expérience concret pour éviter la dérive des infrastructures.

Rackula est une application web open source qui permet de modéliser facilement vos baies serveurs (racks) via une interface intuitive en glisser-déposer. Accessible directement dans le navigateur, elle offre une alternative légère à des solutions comme Excel, Visio, GLPI ou NetBox. Vous pouvez créer des schémas détaillés (face avant/arrière), sauvegarder vos projets en YAML, exporter en PNG/PDF/SVG, et même partager un projet via QR code. Le tutoriel explique son déploiement avec Docker (ou un reverse proxy Traefik) et son utilisation, idéal pour documenter vos infrastructures HomeLab ou professionnelles. 🚀

L’auteur de Spirio.fr partage son expérience du déploiement d’IPv6 sur son infrastructure, une transition qu’il avait longtemps repoussée. Après une après-midi dédiée, il détaille les étapes clés : activation de l’adressage IPv6 sur le serveur, configuration du pare-feu, du reverse proxy HTTPD et des DNS, ainsi que l’adaptation d’AdGuardHome (avec des ajustements spécifiques pour Nftables). Malgré quelques défis, notamment autour d’AdGuardHome, l’auteur souligne la relative simplicité de la procédure pour la plupart des services. Un retour d’expérience pratique pour ceux qui hésitent encore à sauter le pas ! 🌐🔧

L'article explique comment obtenir un ASN (Autonomous System Number) personnel pour annoncer ses plages d'IP sur Internet via le protocole BGP (Border Gateway Protocol). Il commence par définir ce qu'est un ASN et son rôle dans la communication entre réseaux autonomes. L'auteur partage son expérience personnelle, détaillant les étapes pour obtenir un ASN sans se ruiner, comment annoncer ses routes, et comment configurer BGP dans un environnement Kubernetes avec MetalLB. L'article met en lumière l'importance des protocoles de routage dynamique comme BGP pour optimiser les chemins de réseau, surtout dans des infrastructures complexes.

Uncloud est une solution d’auto-hébergement hybride, légère et décentralisée, conçue pour simplifier la gestion d’infrastructures Docker sans la complexité de Kubernetes ou Nomad. Développé en Go et Rust, il utilise WireGuard pour le réseau VPN, Corrosion pour synchroniser les données entre nœuds via SQLite, et Caddy comme reverse proxy intégré. L’outil permet de déployer des services via des fichiers Docker Compose enrichis d’extensions spécifiques (comme x-ports ou x-machines), et gère automatiquement les certificats Let’s Encrypt et les DNS internes. Idéal pour les développeurs ou petites structures souhaitant une alternative simple et efficace à Kubernetes, Uncloud évite la surcharge de gestion tout en offrant une haute disponibilité basique via la redondance. Il est compatible avec les architectures x86_64 et ARM, et s’installe facilement via des commandes CLI, avec une intégration possible dans l’AUR pour Arch Linux. L’auteur, ancien utilisateur de Nomad, souligne sa simplicité et son efficacité pour remplacer des stacks complexes, tout en reconnaissant ses limites (pas de gestion avancée de haute disponibilité ou de secrets pour l’instant). Uncloud se positionne comme une solution pragmatique pour ceux qui veulent se concentrer sur le développement plutôt que sur l’infrastructure.

Alexandre Vandemoortèle partage sa troisième version de HomeLab, un cluster silencieux, économe et performant, avec 150 Go de RAM, 3,64 To de stockage NVMe en RAID 5 et une gestion d'énergie optimisée. Il explique sa philosophie axée sur le silence, la performance par watt et le rapport qualité/prix, tout en détaillant les évolutions depuis ses versions précédentes. Le cœur de cette version repose sur trois mini-PC formant un cluster, avec des spécifications techniques précises et un refroidissement silencieux. Il aborde également les équipements annexes et le coût annuel estimé de son infrastructure.

Ce projet, Rofim, a consisté en une migration et une refonte complète d'infrastructure pour passer chez un hébergeur cloud (AWS) et automatiser les processus grâce à Terraform. La mission, s'étalant sur 2 ans et demi, a inclus la migration en direct de l'application (NodeJS, Angular, MongoDB) avec un downtime minimal, la mise en place de services spécifiques comme un outil d'IA et un stockage d'imagerie médicale, et l'obtention de la certification HDS pour la sécurité des données. L'infrastructure a été automatisée via des services managés comme CodePipeline, CodeBuild, ECS, et API Gateway.

Cet article remet en question l'idée reçue que Kubernetes est uniquement utile pour les grandes entreprises comme Netflix ou Google. Il rappelle que les problématiques d'infrastructure (tolérance aux pannes, déploiements fréquents, flexibilité, etc.) existent dès qu'une équipe gère plusieurs applications en production, indépendamment de la taille de l'entreprise. L'auteur décrit les solutions utilisées avant Kubernetes, comme le load balancing avec HAProxy et Keepalived, et les défis liés au service discovery et aux rollouts, soulignant la complexité de ces tâches sans un outil comme Kubernetes.

Découvrez comment l’outil libre Ansible peut transformer la gestion de votre infrastructure : plutôt que d’intervenir manuellement sur chaque machine, Ansible vous permet, depuis un point central, de piloter des milliers de serveurs simultanément — installer des paquets, déployer des configurations, redémarrer des services, effectuer des mises à jour — le tout de façon automatisée, reproductible et sans agent sur les serveurs cibles. Simple, fiable et très efficace, c’est un incontournable pour quiconque gère un parc multiple de serveurs.

Dans cet article, Dryusdan explique comment automatiser la création et la gestion de passerelles pour ses réseaux privés dans son infrastructure. Il décrit l'utilisation de Packer pour créer des images de machines virtuelles configurées avec un script bash et des fichiers de configuration, permettant ainsi aux instances de ses réseaux privés d'accéder à Internet et d'être accessibles. Il aborde également la gestion des adresses IP via un serveur DHCP personnalisé et le stockage des images avec Incus, tout en partageant son expérience et les défis rencontrés avec Ansible.

L'auteur décrit son infrastructure autohébergée basée sur un cluster Proxmox composé de trois machines identiques, choisies pour leur facilité de maintenance, leur faible coût et leur faible consommation électrique. Il explique les raisons de ce choix, notamment la gestion des pannes et la tolérance aux pannes réseau. Il mentionne également un nœud de test et un serveur de sauvegarde, ainsi qu'un NAS Synology utilisé pour les sauvegardes hors ligne. L'auteur souligne l'importance de documenter et de partager ce type d'infrastructure, qui est rarement décrit en détail.

Nubank, confrontée à une croissance exponentielle et à des coûts élevés liés à une solution externe de logging, a décidé de construire sa propre plateforme interne pour gérer plus d’1 trillion d’entrées de log par jour. L’ancienne architecture, dépendante d’un fournisseur tiers, souffrait de manque de visibilité, de coûts imprévisibles et de rigidité, rendant difficile la résolution des incidents et l’optimisation des ressources.

La nouvelle plateforme a été conçue en deux phases :

1. Observability Stream : ingestion et traitement des logs, utilisant Fluent Bit pour la collecte, un service de buffer interne pour lisser les pics de trafic, et un service de filtrage/transformation extensible.
2. Query and Storage Platform : stockage et requêtage, avec Trino comme moteur SQL distribué (optimisé pour le partitionnement), AWS S3 pour un stockage scalable et économique, et Parquet pour une compression efficace (95 %) et des requêtes rapides.

Résultats :

• 1 Po de données traitées/jour, 45 Po stockés (rétention 45 jours), 15 000 requêtes/jour.
• Réduction de 50 % des coûts par rapport à la solution précédente.
• Fiabilité, scalabilité et contrôle total sur l’infrastructure, permettant une meilleure observabilité et une réponse plus rapide aux incidents.

Cette approche, combinant outils open source et services internes, illustre comment une architecture découplée, modulaire et optimisée pour le cloud peut répondre aux défis de l’échelle tout en maîtrisant les coûts.

Ce billet détaille l’expérience de passage à FrankenPHP en production, comparant l’ancienne stack Nginx/PHP-FPM à une technologie dépassée comme le Minitel. L’auteur explique comment il a déployé FrankenPHP sur un VPS à l’aide d’un Makefile optimisé, en abordant la création d’un Dockerfile de production, l’intégration CI/CD, et une astuce de multiplexing SSH pour éviter les blocages par fail2ban. Une lecture utile pour ceux qui veulent moderniser leur infrastructure PHP avec simplicité et efficacité.