Define layered provisioning architecture and backend API
This commit is contained in:
parent
5b4fb3cf6a
commit
8590f9a8a8
251
01-layered-provisioning.md
Normal file
251
01-layered-provisioning.md
Normal file
@ -0,0 +1,251 @@
|
||||
# Tuxflotte – Architekturentscheidung: Layered Provisioning
|
||||
|
||||
**Status:** Beschlossen
|
||||
**Datum:** 07.07.2026
|
||||
|
||||
## Ausgangspunkt
|
||||
|
||||
Während der Entwicklung des Tuxflotte-Installers entstand die grundlegende Frage:
|
||||
|
||||
> Soll Tuxflotte selbst Betriebssysteme installieren oder die nativen Installer der jeweiligen Distribution orchestrieren?
|
||||
|
||||
Nach der Analyse der Projektziele fiel die Entscheidung eindeutig zugunsten der zweiten Variante.
|
||||
|
||||
---
|
||||
|
||||
# Architekturentscheidung
|
||||
|
||||
Tuxflotte ist **kein eigener Linux-Installer**.
|
||||
|
||||
Tuxflotte ist eine **distributionsunabhängige Workspace-Provisioning-Plattform**, die den nativen Installer der jeweiligen Distribution steuert und mit den notwendigen Informationen versorgt.
|
||||
|
||||
Die eigentliche Installation erfolgt immer mit den offiziellen Installationsmechanismen der Distribution.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Fedora → Anaconda / Kickstart
|
||||
* Debian → Debian Installer / Preseed
|
||||
* Ubuntu → Subiquity / Autoinstall
|
||||
* Linux Mint → entsprechendes Installer-Backend
|
||||
|
||||
Dadurch bleibt Tuxflotte distributionsneutral und muss keine distributionsspezifischen Installationslogiken nachbilden.
|
||||
|
||||
---
|
||||
|
||||
# Grundidee
|
||||
|
||||
Der Administrator denkt nicht mehr in Distributionen.
|
||||
|
||||
Er denkt in Arbeitsplätzen.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Office Workspace
|
||||
* Developer Workspace
|
||||
* Kiosk Workspace
|
||||
* Schulungsraum
|
||||
* Labor
|
||||
* CAD-Arbeitsplatz
|
||||
|
||||
Die verwendete Linux-Distribution ist dabei eine Implementierungsentscheidung und kein Bestandteil des eigentlichen Arbeitsplatzes.
|
||||
|
||||
---
|
||||
|
||||
# Layered Provisioning
|
||||
|
||||
Die Architektur besteht aus mehreren Schichten.
|
||||
|
||||
```text
|
||||
Distribution
|
||||
│
|
||||
▼
|
||||
Backend
|
||||
│
|
||||
▼
|
||||
Organisation
|
||||
│
|
||||
▼
|
||||
Workspace
|
||||
│
|
||||
▼
|
||||
Benutzer (optional)
|
||||
│
|
||||
▼
|
||||
Runtime Blueprint
|
||||
│
|
||||
▼
|
||||
Nativer Installer
|
||||
│
|
||||
▼
|
||||
Provisioning Agent
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Verantwortlichkeiten
|
||||
|
||||
## Backend
|
||||
|
||||
Beschreibt, **wie** eine bestimmte Distribution installiert wird.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Fedora
|
||||
* Linux Mint
|
||||
* Debian
|
||||
* Ubuntu
|
||||
|
||||
Ein Backend enthält ausschließlich distributionsspezifische Logik.
|
||||
|
||||
---
|
||||
|
||||
## Organisation
|
||||
|
||||
Beschreibt unternehmens- oder organisationsweite Vorgaben.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Zertifikate
|
||||
* Paketquellen
|
||||
* Proxy
|
||||
* LDAP
|
||||
* Keycloak
|
||||
* Branding
|
||||
* VPN
|
||||
* Monitoring
|
||||
* Compliance
|
||||
|
||||
Diese Einstellungen gelten unabhängig vom jeweiligen Workspace.
|
||||
|
||||
---
|
||||
|
||||
## Workspace
|
||||
|
||||
Ein Workspace beschreibt den gewünschten Arbeitsplatz.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Office Workspace
|
||||
* Developer Workspace
|
||||
* Secure Workspace
|
||||
* Schulungsraum
|
||||
* Kiosk
|
||||
|
||||
Ein Workspace beschreibt den fachlichen Zielzustand.
|
||||
|
||||
Nicht die Distribution.
|
||||
|
||||
---
|
||||
|
||||
## Benutzer
|
||||
|
||||
Optional können benutzerspezifische Einstellungen ergänzt werden.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Sprache
|
||||
* SSH-Schlüssel
|
||||
* persönliche Zertifikate
|
||||
* individuelle Software
|
||||
* Drucker
|
||||
|
||||
---
|
||||
|
||||
## Runtime Blueprint
|
||||
|
||||
Während der Installation erzeugt Tuxflotte automatisch ein vollständiges Runtime Blueprint.
|
||||
|
||||
Dieses entsteht aus:
|
||||
|
||||
Backend
|
||||
|
||||
*
|
||||
|
||||
Organisation
|
||||
|
||||
*
|
||||
|
||||
Workspace
|
||||
|
||||
*
|
||||
|
||||
Benutzer
|
||||
|
||||
Das Runtime Blueprint beschreibt den vollständigen Zielzustand der Installation.
|
||||
|
||||
Dieses Blueprint wird anschließend vom Backend in distributionsspezifische Installationsdaten übersetzt.
|
||||
|
||||
---
|
||||
|
||||
# Trennung von Fachlichkeit und Technik
|
||||
|
||||
Die Architektur trennt bewusst:
|
||||
|
||||
**Was soll entstehen?**
|
||||
|
||||
↓
|
||||
|
||||
Workspace
|
||||
|
||||
von
|
||||
|
||||
**Wie wird es umgesetzt?**
|
||||
|
||||
↓
|
||||
|
||||
Backend
|
||||
|
||||
Dadurch bleibt der gewünschte Arbeitsplatz unabhängig von der verwendeten Linux-Distribution.
|
||||
|
||||
---
|
||||
|
||||
# Erweiterbarkeit
|
||||
|
||||
Neue Distributionen werden ausschließlich durch neue Backends ergänzt.
|
||||
|
||||
Neue Kunden werden ausschließlich durch neue Organisationen ergänzt.
|
||||
|
||||
Neue Arbeitsplatztypen werden ausschließlich durch neue Workspaces ergänzt.
|
||||
|
||||
Der Kern von Tuxflotte bleibt unverändert.
|
||||
|
||||
---
|
||||
|
||||
# Langfristige Vision
|
||||
|
||||
Ein Administrator arbeitet ausschließlich mit Workspaces.
|
||||
|
||||
Beispiel:
|
||||
|
||||
Workspace:
|
||||
|
||||
Developer Workspace
|
||||
|
||||
Backend:
|
||||
|
||||
Fedora 42
|
||||
|
||||
Organisation:
|
||||
|
||||
Muster GmbH
|
||||
|
||||
Benutzer:
|
||||
|
||||
Max Mustermann
|
||||
|
||||
Tuxflotte erzeugt daraus automatisch das Runtime Blueprint und startet anschließend den nativen Installer der ausgewählten Distribution.
|
||||
|
||||
---
|
||||
|
||||
# Leitprinzip
|
||||
|
||||
> Administratoren verwalten Workspaces.
|
||||
>
|
||||
> Organisationen definieren Standards.
|
||||
>
|
||||
> Backends implementieren Distributionen.
|
||||
>
|
||||
> Tuxflotte orchestriert den gesamten Prozess.
|
||||
|
||||
Die Linux-Distribution wird dadurch zu einem austauschbaren technischen Detail, während der gewünschte Arbeitsplatz dauerhaft erhalten bleibt.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Stallinux Provisioning Platform
|
||||
# Tuxflotte Provisioning
|
||||
|
||||
Repositories:
|
||||
|
||||
|
||||
263
architecture-v2.md
Normal file
263
architecture-v2.md
Normal file
@ -0,0 +1,263 @@
|
||||
# Tuxflotte – Architektur v2
|
||||
|
||||
## Vision
|
||||
|
||||
Tuxflotte ist eine distributionsunabhängige Provisionierungsplattform für Linux-Systeme.
|
||||
|
||||
Tuxflotte installiert **keine Betriebssysteme selbst**, sondern orchestriert den Installationsprozess, indem die nativen Installer der jeweiligen Distribution genutzt werden.
|
||||
|
||||
Dadurch bleibt Tuxflotte unabhängig von distributionsspezifischen Installationsdetails und profitiert von den offiziellen Installationsmechanismen.
|
||||
|
||||
---
|
||||
|
||||
# Architekturprinzipien
|
||||
|
||||
## 1. Klare Verantwortlichkeiten
|
||||
|
||||
### Provisioning-ISO
|
||||
|
||||
Verantwortlich für:
|
||||
|
||||
* Hardware erkennen
|
||||
* Netzwerk initialisieren
|
||||
* Provisioning-Server kontaktieren
|
||||
* Profile laden
|
||||
* Zielsystem auswählen
|
||||
* Installationsparameter erzeugen
|
||||
* nativen Installer starten
|
||||
|
||||
Nicht verantwortlich für:
|
||||
|
||||
* Partitionierung
|
||||
* Dateisysteme
|
||||
* Paketinstallation
|
||||
* Bootloader-Konfiguration
|
||||
|
||||
Diese Aufgaben übernimmt der Installer der jeweiligen Distribution.
|
||||
|
||||
---
|
||||
|
||||
### Distribution-Installer
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Fedora → Anaconda (Kickstart)
|
||||
* Linux Mint → abhängig von der verwendeten Installer-Technologie
|
||||
* Debian → Debian Installer (Preseed)
|
||||
* Ubuntu → Subiquity (Autoinstall)
|
||||
|
||||
Verantwortlich für:
|
||||
|
||||
* Partitionierung
|
||||
* Dateisysteme
|
||||
* Betriebssysteminstallation
|
||||
* Bootloader
|
||||
* Benutzeranlage
|
||||
* Erstkonfiguration des Systems
|
||||
|
||||
---
|
||||
|
||||
### Provisioning-Agent
|
||||
|
||||
Nach dem ersten Systemstart übernimmt der Agent:
|
||||
|
||||
* Registrierung am Provisioning-Server
|
||||
* Inventarisierung
|
||||
* Nachinstallation
|
||||
* Konfigurationsmanagement
|
||||
* Softwareverteilung
|
||||
* Statusmeldungen
|
||||
|
||||
---
|
||||
|
||||
### Provisioning-Server
|
||||
|
||||
Der Server verwaltet:
|
||||
|
||||
* Profile
|
||||
* Geräte
|
||||
* Installationsvorlagen
|
||||
* Richtlinien
|
||||
* Inventar
|
||||
* Provisioning-Aufträge
|
||||
|
||||
---
|
||||
|
||||
# Komponenten
|
||||
|
||||
```text
|
||||
Provisioning Server
|
||||
│
|
||||
▼
|
||||
Provisioning-Profile
|
||||
│
|
||||
▼
|
||||
Provisioning-ISO
|
||||
│
|
||||
▼
|
||||
Distribution-Installer
|
||||
│
|
||||
▼
|
||||
Installiertes System
|
||||
│
|
||||
▼
|
||||
Provisioning-Agent
|
||||
│
|
||||
▼
|
||||
Provisioning-Server
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Installer-Workflow
|
||||
|
||||
## Phase 1
|
||||
|
||||
Preflight
|
||||
|
||||
* Hardware prüfen
|
||||
* RAM
|
||||
* CPU
|
||||
* Firmware
|
||||
* Netzwerk
|
||||
|
||||
---
|
||||
|
||||
## Phase 2
|
||||
|
||||
Inventarisierung
|
||||
|
||||
* Datenträger erkennen
|
||||
* Netzwerkkarten
|
||||
* Firmware
|
||||
* Seriennummern
|
||||
* Systeminformationen
|
||||
|
||||
---
|
||||
|
||||
## Phase 3
|
||||
|
||||
Profil
|
||||
|
||||
* Benutzer wählt Profil
|
||||
|
||||
oder
|
||||
|
||||
* Profil wird automatisch vom Server geliefert
|
||||
|
||||
---
|
||||
|
||||
## Phase 4
|
||||
|
||||
Backend
|
||||
|
||||
Passendes Backend wird geladen.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Fedora
|
||||
* Mint
|
||||
* Debian
|
||||
* Ubuntu
|
||||
|
||||
---
|
||||
|
||||
## Phase 5
|
||||
|
||||
Installationsparameter erzeugen
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Kickstart
|
||||
* Autoinstall
|
||||
* Preseed
|
||||
|
||||
---
|
||||
|
||||
## Phase 6
|
||||
|
||||
Nativen Installer starten
|
||||
|
||||
Ab diesem Zeitpunkt übernimmt die Distribution die eigentliche Installation.
|
||||
|
||||
---
|
||||
|
||||
## Phase 7
|
||||
|
||||
Erster Start
|
||||
|
||||
Provisioning-Agent startet automatisch.
|
||||
|
||||
---
|
||||
|
||||
# Profile
|
||||
|
||||
Jedes Profil beschreibt:
|
||||
|
||||
* Distribution
|
||||
* Version
|
||||
* Desktop
|
||||
* Softwarepakete
|
||||
* Benutzer
|
||||
* Netzwerkeinstellungen
|
||||
* Provisioning-Richtlinien
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
profiles/
|
||||
fedora-workstation/
|
||||
profile.json
|
||||
|
||||
mint-desktop/
|
||||
profile.json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Backend-Konzept
|
||||
|
||||
Jede Distribution besitzt ein eigenes Backend.
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
profiles/
|
||||
|
||||
fedora-workstation/
|
||||
profile.json
|
||||
installer.sh
|
||||
kickstart.tpl
|
||||
|
||||
mint-desktop/
|
||||
profile.json
|
||||
installer.sh
|
||||
autoinstall.tpl
|
||||
```
|
||||
|
||||
Der Kern von Tuxflotte kennt keine distributionsspezifischen Details.
|
||||
|
||||
Er lädt ausschließlich das gewählte Profil und übergibt die Kontrolle an das passende Backend.
|
||||
|
||||
Dadurch kann Tuxflotte jederzeit um weitere Distributionen erweitert werden, ohne den Kern ändern zu müssen.
|
||||
|
||||
---
|
||||
|
||||
# Ziele
|
||||
|
||||
* distributionsunabhängig
|
||||
* modular
|
||||
* erweiterbar
|
||||
* reproduzierbar
|
||||
* automatisierbar
|
||||
* servergesteuert
|
||||
* Zero-Touch-fähig
|
||||
* sowohl interaktiv als auch unbeaufsichtigt nutzbar
|
||||
|
||||
---
|
||||
|
||||
# Grundsatz
|
||||
|
||||
**Tuxflotte ist eine Provisionierungsplattform und kein eigener Linux-Installer.**
|
||||
|
||||
Die Installation erfolgt grundsätzlich mit den offiziellen Installationsmechanismen der jeweiligen Linux-Distribution.
|
||||
196
tuxflotte-backend-api-v1.md
Normal file
196
tuxflotte-backend-api-v1.md
Normal file
@ -0,0 +1,196 @@
|
||||
# Tuxflotte Backend API v1
|
||||
|
||||
## Zweck
|
||||
|
||||
Die Backend-API definiert die Schnittstelle zwischen dem Tuxflotte-Orchestrator und den distributionsspezifischen Backends.
|
||||
|
||||
Der Orchestrator kennt keine distributionsabhängigen Details. Er ruft ausschließlich die in diesem Dokument definierten Funktionen auf.
|
||||
|
||||
Jedes Backend muss diese Schnittstelle implementieren.
|
||||
|
||||
---
|
||||
|
||||
# Backend-Verzeichnis
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
backends/
|
||||
├── fedora/
|
||||
│ ├── backend.sh
|
||||
│ ├── kickstart.tpl
|
||||
│ └── README.md
|
||||
│
|
||||
├── mint/
|
||||
│ ├── backend.sh
|
||||
│ ├── autoinstall.tpl
|
||||
│ └── README.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Lebenszyklus
|
||||
|
||||
Der Orchestrator arbeitet immer in derselben Reihenfolge:
|
||||
|
||||
```text
|
||||
backend_init()
|
||||
|
||||
↓
|
||||
|
||||
backend_validate()
|
||||
|
||||
↓
|
||||
|
||||
backend_generate_config()
|
||||
|
||||
↓
|
||||
|
||||
backend_launch()
|
||||
|
||||
↓
|
||||
|
||||
backend_postinstall()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Pflichtfunktionen
|
||||
|
||||
## backend_init()
|
||||
|
||||
Initialisiert das Backend.
|
||||
|
||||
Aufgaben:
|
||||
|
||||
* Backend-Version prüfen
|
||||
* benötigte Werkzeuge prüfen
|
||||
* Templates laden
|
||||
* interne Variablen initialisieren
|
||||
|
||||
Rückgabe:
|
||||
|
||||
* 0 = erfolgreich
|
||||
* ungleich 0 = Fehler
|
||||
|
||||
---
|
||||
|
||||
## backend_validate()
|
||||
|
||||
Prüft, ob das Profil mit diesem Backend kompatibel ist.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* unterstützte Distribution
|
||||
* unterstützte Version
|
||||
* unterstützte Architektur
|
||||
|
||||
Rückgabe:
|
||||
|
||||
* 0 = Profil gültig
|
||||
* ungleich 0 = Profil ungültig
|
||||
|
||||
---
|
||||
|
||||
## backend_generate_config()
|
||||
|
||||
Erzeugt die installationsspezifischen Konfigurationsdateien.
|
||||
|
||||
Beispiele:
|
||||
|
||||
Fedora:
|
||||
|
||||
* Kickstart-Datei
|
||||
|
||||
Ubuntu:
|
||||
|
||||
* Autoinstall-Konfiguration
|
||||
|
||||
Debian:
|
||||
|
||||
* Preseed-Datei
|
||||
|
||||
Mint:
|
||||
|
||||
* distributionsabhängige Antwortdatei
|
||||
|
||||
Ausgabe:
|
||||
|
||||
Konfigurationsdateien im Laufzeitverzeichnis.
|
||||
|
||||
---
|
||||
|
||||
## backend_launch()
|
||||
|
||||
Startet den nativen Installer.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Anaconda
|
||||
* Calamares
|
||||
* Debian Installer
|
||||
* Subiquity
|
||||
|
||||
Ab diesem Zeitpunkt übernimmt der Installer der Distribution die eigentliche Installation.
|
||||
|
||||
---
|
||||
|
||||
## backend_postinstall()
|
||||
|
||||
Vorbereitung für den ersten Start.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* Provisioning-Agent installieren oder aktivieren
|
||||
* Erststart-Konfiguration vorbereiten
|
||||
* Registrierung am Provisioning-Server vorbereiten
|
||||
|
||||
---
|
||||
|
||||
# Optionale Funktionen
|
||||
|
||||
Ein Backend kann zusätzliche Funktionen bereitstellen.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* backend_upgrade()
|
||||
* backend_cleanup()
|
||||
* backend_debug()
|
||||
|
||||
Der Orchestrator verwendet ausschließlich die Pflichtfunktionen.
|
||||
|
||||
---
|
||||
|
||||
# Laufzeitdaten
|
||||
|
||||
Der Orchestrator stellt dem Backend alle benötigten Informationen bereit.
|
||||
|
||||
Beispiele:
|
||||
|
||||
* ausgewähltes Profil
|
||||
* Zielsystem
|
||||
* Hardwareinformationen
|
||||
* Netzwerk
|
||||
* Laufzeitverzeichnis
|
||||
|
||||
Backends greifen nicht direkt auf andere Module zu.
|
||||
|
||||
---
|
||||
|
||||
# Fehlerbehandlung
|
||||
|
||||
Jede Backend-Funktion liefert einen Rückgabecode.
|
||||
|
||||
Der Orchestrator entscheidet, ob:
|
||||
|
||||
* erneut versucht wird,
|
||||
* abgebrochen wird,
|
||||
* oder der Benutzer eingreifen muss.
|
||||
|
||||
---
|
||||
|
||||
# Grundsatz
|
||||
|
||||
Backends enthalten ausschließlich distributionsspezifische Logik.
|
||||
|
||||
Der Tuxflotte-Kern bleibt distributionsneutral.
|
||||
@ -1,8 +1,8 @@
|
||||
# Stallinux Provisioning Platform
|
||||
# Tuxflotte Provisioning
|
||||
|
||||
## Vision
|
||||
|
||||
Die Stallinux Provisioning Platform soll die automatisierte Bereitstellung und Konfiguration von Linux-Systemen vereinfachen.
|
||||
Die Tuxflotte Provisioning soll die automatisierte Bereitstellung und Konfiguration von Linux-Systemen vereinfachen.
|
||||
|
||||
Das Ziel ist eine distributionsübergreifende Plattform, die Linux Mint, Fedora und zukünftig weitere Distributionen über denselben Provisionierungsprozess installieren und konfigurieren kann.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user