B0rbor4d
cc4c3fcecb
- Backend: Customer/Satellite Models, customer_id auf Server/Job/Audit - Satellite-API: heartbeat, poll (atomares Claiming), logs, result, scan-result, health-report - Auth via X-Api-Key (SHA-256 gehasht) - Job-Queue: pending/claimed/running/success/failed + Stale-Janitor - Batch-Trigger: ein Job pro Server, Satellite arbeitet sequenziell ab - Credentials bleiben lokal: nur symbolische credential_ref zentral - Neues Paket satellite/: Pull-Loop, WinRM/SSH/CAU/Scanner, PyInstaller-tauglich - Frontend: Kunden-Switcher, Satelliten-View, Polling statt WebSocket - Entfernt: WebSocket/Socket.io, Redis, zentrale Credentials, JobRunner - Docs: README/AGENTS/PROMPT auf neue Architektur aktualisiert
4.8 KiB
4.8 KiB
Insight Updater
Zentrale, mandantenfaehige Update-Orchestrierung fuer Kundennetzwerke. Hub-and-Spoke: eine zentrale Instanz (Docker) plus schlanke Satelliten beim Kunden (einzelne Binary, kein Docker noetig). Satelliten pollen Jobs von der Zentrale, fuehren Updates lokal im Kundennetz aus (WinRM / SSH / CAU) und melden Ergebnisse zurueck.
Architektur
Kundennetz A Kundennetz B Zentrale
┌──────────────┐ ┌──────────────┐ ┌───────────────┐
│ Satellite 1 │ │ Satellite 1 │ outbound │ Backend │
│ (Binary) │───┐ │ (Binary) │───┐ HTTPS │ (FastAPI) │
└──────────────┘ │ └──────────────┘ │────────────▶│ + DB │
┌──────────────┐ │ ┌──────────────┐ │ │ + Frontend │
│ Satellite 2 │───┘ │ Satellite 2 │───┘ │ (Dashboard, │
└──────────────┘ WinRM/SSH └──────────────┘ │ nach Kunde) │
lokal └───────────────┘
- Pull-Modell: Satelliten fragen alle N Sekunden nach Jobs - keine eingehenden Verbindungen beim Kunden noetig
- Multi-Tenant: jede Entitaet (Server, Jobs, Satelliten, Audit) haengt an einem Kunden
- Credentials bleiben lokal: WinRM/SSH-Zugangsdaten liegen nur auf dem Satellite (
credentials.yaml), niemals zentral - Netz-Orchestrierung: 1-2 Satelliten pro Kunde steuern das ganze Netz, aehnlich CAU im Cluster
Komponenten
| Teil | Pfad | Technologie |
|---|---|---|
| Zentrale (Backend) | backend/ |
FastAPI, SQLAlchemy 2.0, SQLite/PostgreSQL |
| Zentrale (Frontend) | frontend/ |
Vue 3, TypeScript, Vite, Pinia, Tailwind |
| Satellite (Agent) | satellite/ |
Python, pywinrm, asyncssh, httpx, PyInstaller |
Features
- Kunden-Verwaltung mit Satelliten pro Kunde (API-Key, einmalig angezeigt)
- Server-Inventar pro Kunde, inkl. Auto-Discovery per Netzwerk-Scan
- Job-Queue: pending - claimed - running - success/failed, mit Stale-Janitor
- Batch-Trigger: Update-Jobs fuer alle Server eines Kunden auf einmal
- Netzwerk-Scan: Ping + Port-Probe (5985/22), legt gefundene Hosts zentral an
- Log-Upload in Batches (kein Live-Stream noetig, 10s Dashboard-Refresh)
- Audit-Log: strukturiert, pro Kunde filterbar
- Auth: JWT (RS256) fuer Dashboard-User, API-Key (SHA-256 gehasht) fuer Satelliten
Quick Start (Zentrale, Development)
git clone ssh://git@gitea.insight-it.de:2222/b0rbor4d/insight-updater.git
cd insight-updater
cp .env.example .env
docker compose up -d --build
# Frontend: http://localhost:3000
# Backend API: http://localhost:8000/docs
# Login: admin / admin (bzw. ADMIN_INITIAL_PASSWORD)
Satellite beim Kunden
cd satellite
pip install -e .
cp config.example.yaml config.yaml # central_url + api_key eintragen
cp credentials.example.yaml credentials.yaml # lokale Zugangsdaten
insight-satellite
Produktiv als Windows-Binary: pyinstaller --onefile satellite/runner.py, Details in satellite/README.md.
Workflow
- Kunde anlegen (Dashboard - Kunden)
- Satellite anlegen - API-Key wird einmalig angezeigt
- Satellite beim Kunden installieren (Binary + config.yaml + credentials.yaml)
- Netzwerk-Scan starten - gefundene Hosts landen im Inventar
- Updates triggern: einzeln, per Batch oder ganzer Kunde
- Ergebnisse im Dashboard (nach Kunde sortiert) pruefen
Production Deployment (monitoring.insight.local)
git clone ssh://git@gitea.insight-it.de:2222/b0rbor4d/insight-updater.git
cd insight-updater
cp .env.example .env # Secrets fuellen
mkdir -p keys
openssl genrsa -out keys/private.pem 2048
openssl rsa -in keys/private.pem -pubout -out keys/public.pem
docker compose -f docker-compose.prod.yml up -d --build
Wichtig: die Zentrale muss per HTTPS von den Kunden-Standorten aus erreichbar sein (ausgehend 443 reicht). Traefik-Labels sind vorbereitet.
Umgebungsvariablen
Siehe .env.example. Zentrale braucht nur noch: SECRET_KEY, DATABASE_URL, JWT-Keys,
optional LDAP. WinRM/SSH-Config ist in den Satellite gewandert (dessen config.yaml).
Development
# Backend
cd backend && pip install -e . && uvicorn app.main:app --reload
# Frontend
cd frontend && npm install && npm run dev
# Satellite (lokaler Test gegen Dev-Zentrale)
cd satellite && pip install -e . && insight-satellite
License
MIT - Insight IT