Cet article explique comment utiliser les CTE (Common Table Expressions) avec Doctrine ORM en PHP pour optimiser des requêtes SQL complexes. Les CTE permettent de structurer des requêtes récursives ou décomposées, évitant ainsi des traitements applicatifs coûteux comme le problème N+1. L’exemple illustre la récupération des catégories parentes d’une catégorie donnée via une CTE récursive, plus efficace qu’une approche PHP itérative.

Doctrine ne supportant pas nativement les CTE dans son QueryBuilder ou DQL, l’auteur propose une solution alternative en utilisant une requête SQL native avec un ResultSetMappingBuilder pour mapper les résultats sur des entités. La requête CTE commence par identifier la catégorie de départ, puis remonte récursivement via les relations parent_id, tout en triant les résultats par profondeur.

L’article souligne l’intérêt des CTE pour des cas comme les hiérarchies arborescentes, tout en reconnaissant leur rareté dans le code courant. La méthode proposée contourne les limitations de Doctrine pour exploiter pleinement les capacités des SGBD modernes.

Cette page présente l’infrastructure auto-hébergée de l’auteur, composée d’applications variées déployées via Ansible ou ArgoCD sur un cluster Kubernetes. L’idée principale est de partager ces outils, certains orientés usage quotidien (Nextcloud, Vaultwarden, Jellyfin) et d’autres plus techniques (Paperless-ngx, SignaturePDF), tout en soulignant leur caractère self-hosted pour préserver la confidentialité des données.

Parmi les applications détaillées, Nextcloud avec CollaboraCode et Vaultwarden se distinguent par leur utilité grand public, tandis que Paperless-ngx et SignaturePDF illustrent des solutions spécialisées pour la gestion documentaire. L’auteur met en avant des outils comme Ovumcy, axé sur la santé, ou Fittrackee pour le suivi sportif, reflétant une approche pragmatique mêlant praticité et respect de la vie privée.

L’infrastructure inclut aussi des services comme GoAuthentik pour l’authentification ou Kresus (malgré des limites liées aux changements d’API bancaire), démontrant une volonté d’autonomie technique. L’auteur invite à découvrir ou suggérer d’autres outils, via sa page de contact, tout en insistant sur l’évolution constante de son lab.

L’article relate l’expérience de l’auteur avec Varnish 9 et son support natif du TLS, combiné à Let’s Encrypt pour sécuriser les connexions. Il détaille le déploiement d’une machine virtuelle Debian 13 sur Hetzner Cloud, où Varnish a été installé via un dépôt APT officiel, simplifiant ainsi le processus. L’auteur souligne l’absence de complications avec IPv6 et l’utilisation d’un sous-domaine dédié pour les tests.

Pour les tests, une application FastAPI minimaliste a été créée, simulant une réponse lente (2 secondes) pour évaluer les performances de mise en cache de Varnish. Les résultats montrent une réduction significative du temps de réponse après le premier appel, passant de 2,4 secondes à 230 millisecondes, illustrant l’efficacité du cache.

Enfin, l’auteur évoque brièvement le fichier de configuration VCL par défaut de Varnish, qui nécessite des ajustements pour une utilisation optimale, notamment pour la gestion du TLS et des certificats Let’s Encrypt, dont la configuration sera abordée dans un futur billet.

Uptime Kuma est un outil open source de surveillance de services web, présenté comme une alternative gratuite et auto-hébergée à Uptime Robot. Contrairement à ce dernier, limité à 50 moniteurs dans sa version gratuite, Uptime Kuma permet un nombre illimité de sondes sans abonnement, tout en offrant des fonctionnalités avancées comme la surveillance SSL/TLS, des alertes personnalisables (email, Telegram, Discord, etc.) et une interface moderne. Il prend en charge divers protocoles (HTTP, TCP, DNS, etc.) et propose une page de statut publique pour informer les utilisateurs.

L’article explique comment installer Uptime Kuma via Docker sur un VPS, en détaillant les étapes de configuration avec Traefik comme reverse proxy. Il souligne que, bien que l’outil soit auto-hébergé et respectueux de la vie privée, ses vérifications dépendent du serveur local, contrairement à des solutions comme Uptime Robot qui testent depuis plusieurs zones géographiques. Les prérequis incluent un VPS, Docker, un nom de domaine et un reverse proxy configuré.

Enfin, le guide met en avant la flexibilité d’Uptime Kuma, avec des options de personnalisation poussées (intervalles de vérification, notifications multi-services) et une sécurité renforcée (authentification, 2FA). Il convient particulièrement aux particuliers ou PME souhaitant surveiller des services critiques sans dépendre d’un tiers, tout en évitant les coûts récurrents des solutions payantes.

L’article explique comment intégrer CrowdSec Manager dans l’architecture Pangolin sans exposer directement son interface sensible sur Internet. L’auteur détaille une solution sécurisée en utilisant le SSO de Pangolin et le service Newt, évitant ainsi l’ouverture d’un port externe. L’objectif est de centraliser la gestion des alertes et des décisions de CrowdSec via une interface protégée, tout en maintenant une architecture Zero Trust.

L’auteur souligne les risques liés à l’exposition directe de l’interface (port 8080) et propose une configuration où CrowdSec Manager est accessible uniquement via le réseau Docker interne, protégé par le SSO. Cette approche limite les surfaces d’attaque tout en permettant une administration centralisée. L’article inclut des détails techniques sur la configuration Docker et les bonnes pratiques pour gérer les secrets via Gitea Actions.

Enfin, l’auteur compare les fonctionnalités de CrowdSec Manager (dashboard, gestion des alertes, bouncers) à ses limites, notamment l’absence de remplacement complet des outils de sécurité traditionnels. L’article s’inscrit dans une série dédiée à Pangolin, avec une approche pragmatique pour renforcer la sécurité d’une stack auto-hébergée.