server

Un dépôt homelab personnel qui traite l'ensemble du cluster comme de l'infrastructure-as-code. La pile s'exécute sur k3s, avec des playbooks, des rôles et un inventaire Ansible comme source de vérité éditable ; un répertoire Docker Compose rendu existe uniquement sur l'hôte Raspberry Pi. Le dépôt documente qu'une migration de Docker Compose vers k3s a été achevée le 14-08-2026, lorsque Docker a été désinstallé du nœud serveur principal, et l'enregistrement étape par étape est conservé dans un dossier d'archive à titre d'historique. Trois hôtes sont décrits. daniel-box est le plan de contrôle k3s et exécute presque toutes les charges de travail, y compris l'edge Traefik, le SSO Authelia et l'émetteur OIDC, le DNS Pi-hole, le stockage Longhorn, CrowdSec et un point de terminaison WireGuard public ; Ansible s'y exécute. daniel-server est un nœud agent k3s avec un iGPU Intel utilisé pour le transcodage Jellyfin/Tdarr, le stockage LVM et la gestion de l'arrêt UPS/NUT. daniel-pi est le seul hôte Docker restant, maintenu uniquement sur le LAN, exécutant une seconde instance WireGuard ainsi qu'une petite pile d'utilitaires. L'ingress est centralisé sur Traefik, routant via des CRD IngressRoute, avec Authelia filtrant les routes protégées via un middleware forward-auth et émettant des jetons OIDC pour les applications qui les supportent. Cloudflare proxye les noms d'hôte publics, tandis que les noms locaux sont résolus par Pi-hole sur le LAN. Le README note que la segmentation du réseau n'est pas appliquée globalement : seuls quelques rôles définissent des NetworkPolicies, et là où des politiques existent, seules les règles d'ingress sont appliquées par le CNI du cluster. Le déploiement est divisé en un play Docker et un play k8s, tous deux pilotés par la containers_list de chaque hôte. Le play Docker résout un graphe de dépendances à l'aide de filtres toposort personnalisés et de déclarations upstream meta/deps.yml par rôle, de sorte que les dépendances démarrent en premier et que les exécutions taguées récupèrent les dépendances non satisfaites. Le play k8s effectue un toposort des rôles et dérive des arêtes vers Traefik (pour l'installation des CRD) et Authelia (pour le middleware) à partir des modèles de rôles eux-mêmes, avec un depends_on explicite pour les arêtes qu'aucun modèle ne porte. Les filtres sont testés unitairement via pytest dans un hook pre-commit. Les commandes sont documentées pour déployer un seul service, un dry run, l'ensemble, ou la cible Pi, avec des playbooks de mise en service et de bootstrap séparés. Les préoccupations transversales incluent des secrets chiffrés SOPS/age déchiffrés au moment de l'exécution, avec gitleaks dans le pre-commit et une sauvegarde de clé hors bande ; l'observabilité Prometheus, Grafana, Loki et Tempo avec des tableaux de bord provisionnés en tant que code ; des sauvegardes Longhorn planifiées vers Backblaze B2 avec un tiering par volume documenté et des procédures de reprise après sinistre ; des pull requests pilotées par Renovate pour les versions d'images épinglées et les révisions de hooks ; et des outils de sécurité incluant Authelia TOTP/OIDC, CrowdSec avec des agents par nœud, fail2ban et un UFW default-deny entrant. Les portes de qualité passent par un outil pre-commit couvrant le lint YAML/JSON, ansible-lint, gitleaks, la validation des modèles rendus, la synchronisation du registre de rotation des secrets, ruff et pytest. Des conseils sont inclus pour ajouter de nouveaux services, soit comme rôles k8s rendant des manifestes Deployment/Service/IngressRoute/PVC, soit comme rôles Docker pour le Pi.