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.
70 services déclarés affichés sur 70
1 · Services et expérimentationsFinalité principale du homelab : disponibilité, erreurs, latence et trafic des services expérimentés.RED52 composants52 en alerte
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
InconnuHard drive health monitoring
2 · Socle critiqueFondations dont la panne peut retirer une couche entière : disponibilité, quorum/readiness, pression, capacité et erreurs.USE2 composants2 en alerte
4 · Plateforme et données partagéesBackends partagés : disponibilité, latence, saturation et capacité sans confondre impact et dépendance requise.RED + USE11 composants11 en alerte
PostgreSQL
InconnuDatabase server (TCP — use a Postgres client, not a normal web browser tab)
5 · Observabilité et supportObservabilité et outils auxiliaires : importants pour diagnostiquer, sans rendre automatiquement les services indisponibles.SUPPORT5 composants5 en alerte
Afficher la hiérarchie des dépendances critiques
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.
1 · Fondations d’infrastructure
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
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’infrastructure2 servicesinconnu
Données et état partagés4 servicesinconnu
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
Services de plateforme partagés7 servicesinconnu
- Dockerrequise · hostedBy
- InfluxDBrequise · storesIn
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
- Dockerrequise · hostedBy
- Ollamarequise · routesTo
Applications et consommateurs4 servicesinconnu
- Dockerrequise · hostedBy
- Mimirrequise · storesIn
- Dockerrequise · hostedBy
- PostgreSQLrequise · dependsOn
- Dockerrequise · hostedBy
- MongoDBrequise · dependsOn
- OpenSearch Securityrequise · storesIn
- 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.
Vue mobile compacte : ouvrez une couche puis un service pour afficher ses relations visibles.
Interfaces & agentsClients utilisateurs et points d’entrée des agents/coding agents.5 nœuds · flux principal ↓
- Codexinterfaces · coding-agent
1 relation
- requise · flux API/données · model requestsLiteLLM
- Cursorinterfaces · coding-agent
1 relation
- requise · flux API/données · model requestsLiteLLM
- Open WebUIinterfaces · interfaceapplication · blast radius 0
3 relations
- requise · flux API/données · model requestsLiteLLM
- optionnelle · flux API/données · tool callsFastAPI MCP
- optionnelle · flux API/données · RAGOpenRAG
- OpenClawinterfaces · agent
1 relation
- requise · flux API/données · model requestsLiteLLM
- OpenCodeinterfaces · coding-agent
1 relation
- requise · flux API/données · model requestsLiteLLM
Plan de contrôleGateway de modèles, politiques de routage et état partagé à chaud.2 nœuds · flux principal ↓
- LiteLLMcontrol-plane · model-gatewayshared platform · blast radius 1
5 relations
- optionnelle · dépendance · cacheRedis
- requise · flux API/données · routesToOllama
- optionnelle · flux API/données · routesToOpenAI API
- optionnelle · observabilité · telemetryLangfuse
- optionnelle · observabilité · metricsPrometheus
- Rediscontrol-plane · cacheshared data · blast radius 6
InférenceCibles d’exécution locales et distantes des modèles.2 nœuds · flux principal ↓
- Ollamainference · local-inferenceshared platform · blast radius 2
- OpenAI APIinference · remote-inferenceOuvrir ↗
Outils & connaissancesOutils MCP, recherche, RAG et sources documentaires.5 nœuds · flux principal ↓
- FastAPI MCPtools · mcp-serverOuvrir ↗
2 relations
- optionnelle · flux API/données · tool boundaryOpen Terminal
- optionnelle · flux API/données · searchSearXNG
- Open Terminaltools · agent-toolsupport · blast radius 0
- OpenRAGtools · ragOuvrir ↗
2 relations
- optionnelle · observabilité · tracesLangfuse
- optionnelle · observabilité · evaluationOpik
- Paperless-ngxtools · knowledgeOuvrir ↗
1 relation
- optionnelle · flux API/données · knowledge flowOpenRAG
- SearXNGtools · searchsupport · blast radius 0
OrchestrationMoteurs de workflow coordonnant automatisations et traitements longs.3 nœuds · flux principal ↓
- Langfloworchestration · workflowshared platform · blast radius 2
1 relation
- requise · flux API/données · workflowOpenRAG
- n8norchestration · workflowapplication · blast radius 0
1 relation
- optionnelle · automatisation · automatesFastAPI MCP
- Temporalorchestration · workflowOuvrir ↗
1 relation
- optionnelle · automatisation · document workflowPaperless-ngx
Observabilité & évaluationTracing, métriques, qualité et boucles d’évaluation.3 nœuds · flux principal ↓
- Langfuseobservability · llm-observabilityshared platform · blast radius 2
- Opikobservability · evaluationOuvrir ↗
- Prometheusobservability · metricsapplication · blast radius 0
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. Il distingue le chemin HAProxy direct, le DNS Cloudflare sans Tunnel pour Garage et le Cloudflare Tunnel terminé par le conteneur Docker cloudflared pour OpenWebUI.
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