Architecture interactive Nabla
Plateforme IA, services homelab, dépendances fonctionnelles et intégrations observables.
La lecture commence par les fondations et composants à plus grand rayon d’impact, avant les applications feuilles. La vue détaillée conserve ensuite l’ensemble des relations déclarées dans nabla-compose.
Opérations et diagnostic
Un snapshot unique en lecture seule du runtime FastAPI, de la santé des dépendances et des preuves TrueNAS, pfSense et Cloudflare. Commencez ici pour identifier la couche en défaut avant de modifier la configuration.
Diagnostic d’impact et de cause racine
Sélectionne un service pour séparer sa santé locale, les causes observées via blocked_by et son rayon d’impact structurel dans la topologie requise.
État et filtres de l’architecture
Les filtres s’appliquent aux services déclarés du graphe ; la topologie complète reste utilisée pour calculer la criticité et le rayon d’impact.
72 services déclarés affichés sur 72
1 · Services et expérimentationsFinalité principale du homelab : disponibilité, erreurs, latence et trafic des services expérimentés.RED49 composants49 en alerte
Garage
InconnuGarage WebUI exposed through Cloudflare Tunnel directly to the LAN-bound :3909 origin without Traefik.
AnythingLLM - albandrieu
InconnuPrivate LLM workspace and RAG
LocalAI (GPU)
InconnuLocal AI models (GPU instance)
Ollama (GPU)
InconnuLarge language models (GPU instance)
Open SpeedTest
InconnuOpen SpeedTest - Network speed testing
PortTracker - albandrieu
InconnuPort tracking service
Reactive Resume - albandrieu
InconnuReactive Resume
Scrutiny Collector - albandrieu
InconnuWorkstation SMART collector posting disk telemetry to the Scrutiny Web/API hosted on TrueNAS.
2 · Socle critiqueFondations dont la panne peut retirer une couche entière : disponibilité, quorum/readiness, pression, capacité et erreurs.USE2 composants2 en alerte
3 · Contrôles de sécuritéDisponibilité des contrôles et posture sécurité restent deux dimensions distinctes.POSTURE4 composants4 en alerte
4 · Plateforme et données partagéesBackends partagés : disponibilité, latence, saturation et capacité sans confondre impact et dépendance requise.RED + USE9 composants9 en alerte
PostgreSQL
InconnuDatabase server (TCP — use a Postgres client, not a normal web browser tab)
Garage S3
InconnuGarage S3-compatible object-storage API exposed through the direct HAProxy/TLS re-encryption/Traefik path.
5 · Observabilité et supportObservabilité et outils auxiliaires : importants pour diagnostiquer, sans rendre automatiquement les services indisponibles.SUPPORT8 composants8 en alerte
Garage Admin
InconnuGarage Admin API exposed through Cloudflare Tunnel directly to the LAN-bound :3903 origin without Traefik.
Afficher la hiérarchie des dépendances critiquesLire les dépendances requises, le rayon d’impact et l’ordre lifecycle canonique (phase + priorité) issu de Nabla Compose. Chemin critique
Hiérarchie des dépendances critiques
Les fondations et l’état partagé sont présentés avant les applications selon les dépendances requises déclarées et leur rayon d’impact transitif.
Ordre lifecycle canonique de Nabla Compose : les dépendances requises restent prioritaires, puis la phase et la priorité numérique déterminent l’ordre opérationnel.1 · Fondations d’infrastructure
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
2 · Données et état partagés
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
3 · Services de plateforme partagés
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
4 · Applications et consommateurs
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
5 · Support et composants à faible impact
Inspecter l’impact des dépendances
Inspecter l’impact des dépendances
La criticité est dérivée des relations requises bloquantes (dependsOn, consumesApi, routesTo, storesIn, authenticatesVia et partOf structurel). Les bases, caches et stockages sont classés comme état partagé lorsqu’ils ont des dépendants requis. Les liens d’observabilité et d’exposition n’augmentent pas artificiellement la criticité de démarrage.
Hiérarchie compacte
Vue mobile des niveaux de criticité, états effectifs et relations directes. Le graphe interactif complet reste disponible plus bas.
Fondations d’infrastructure3 servicesinconnu
- Dockerrequise · hostedBy
Données et état partagés7 servicesinconnu
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
- Traefikrequise · exposedBy
- Dockerrequise · hostedBy
- Garage S3requise · consumesApi
- Cloudflare Tunnel Connectorrequise · exposedBy
- Garage S3requise · partOf
- Cloudflare Tunnel Connectorrequise · exposedBy
Services de plateforme partagés13 servicesinconnu
- Dockerrequise · hostedBy
- Mimirrequise · storesIn
- Dockerrequise · hostedBy
- InfluxDBrequise · storesIn
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
- PostgreSQLrequise · dependsOn
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
- PostgreSQLrequise · dependsOn
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
- MongoDBrequise · dependsOn
- OpenSearch Securityrequise · storesIn
- Dockerrequise · hostedBy
- Ollamarequise · routesTo
Applications et consommateurs2 servicesinconnu
- Dockerrequise · hostedBy
- ClickHouserequise · storesIn
- Dockerrequise · hostedBy
Topologie interactive des services
Utilisez la recherche et les contrôles du graphe pour basculer entre plateforme IA, services, chemin critique, catalogue complet et relations optionnelles. Sur mobile, la hiérarchie compacte ci-dessus fournit une lecture plus directe avant le graphe complet.
La molette fait défiler la page. Utilisez Ctrl/Cmd + molette ou les contrôles +/− pour zoomer dans le diagramme.
AI Platform est regroupé par couches fonctionnelles. Le flux principal descend des interfaces vers le control plane, l’inférence, les outils, l’orchestration et l’observabilité ; la sémantique des arêtes reste distincte de leur caractère requis ou optionnel.
Réseau homelab et chemins d’ingress
Ce diagramme React Flow est exactement le même composant que celui de la page TrueNAS. Les chemins ingress direct HAProxy/Traefik et Cloudflare Tunnel montrent désormais tous deux leur transit par le WAN avant pfSense, puis le tunnel rejoint TrueNAS/cloudflared via le switch LAN. OpenWebUI illustre une origine tunnel directe sur :31028 qui ne traverse jamais Traefik. Le filtre DNS sépare la résolution de noms du routage HTTP : les clients LAN utilisent pfSense/Unbound 172.17.0.1:53 ; les noms publics sont résolus récursivement avec Quad9/Cloudflare comme fallbacks publics uniquement, tandis que le Domain Override int.albandrieu.com délègue vers Pi-hole 172.17.0.24:53, alimenté par pihole-dns-sync à partir des labels Traefik éligibles. Le graphe documente aussi l’incident où une politique Unbound limitée au WAN faisait expirer le forwarder Pi-hole ; la configuration validée est Outgoing Network Interfaces = All avec Forwarding Mode désactivé. Garage conserve trois surfaces : s3.int.albandrieu.com via HAProxy → TLS ré-chiffré → Traefik → :3900, garage.albandrieu.com via Tunnel → cloudflared → :3909 et garage-admin.albandrieu.com via Tunnel → cloudflared → :3903.
La molette fait défiler la page. Utilisez Ctrl/Cmd + molette pour zoomer dans le diagramme.
Configuration déclarée, runtime observé et santé
L’architecture sépare volontairement ce qui devrait exister, ce qui tourne réellement et ce qui est effectivement utilisable. Cette séparation permet de détecter les dérives sans faire de l’interface Web ou de l’API TrueNAS une source de vérité de configuration.
1. nabla-compose
Source déclarative : services x-nabla, identité stable, binding runtime et relations de topologie. services.json et service-topology.json sont générés depuis le code.
2. TrueNAS API
Source runtime observée : le client officiel truenas_api_client interroge app.query pour les Apps, containers, états et versions. Il ne décide jamais qu’un service doit exister ou être public.
3. fastapi-sample
Couche de réconciliation : joint les bindings déclarés aux workloads TrueNAS, classe les écarts (in_sync, declared_only, observed_only, conflict) et garde les contrôles de santé séparés.
4. albanandrieu.com
Couche de présentation : visualise la topologie, le statut runtime et la santé sans devenir une source de données backend.
Declared ≠ Observed ≠ Healthy