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
116 lines
4.8 KiB
Markdown
116 lines
4.8 KiB
Markdown
# 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)
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
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
|
|
|
|
1. Kunde anlegen (Dashboard - Kunden)
|
|
2. Satellite anlegen - API-Key wird einmalig angezeigt
|
|
3. Satellite beim Kunden installieren (Binary + config.yaml + credentials.yaml)
|
|
4. Netzwerk-Scan starten - gefundene Hosts landen im Inventar
|
|
5. Updates triggern: einzeln, per Batch oder ganzer Kunde
|
|
6. Ergebnisse im Dashboard (nach Kunde sortiert) pruefen
|
|
|
|
## Production Deployment (monitoring.insight.local)
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
# 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
|