252 lines
4.3 KiB
Markdown
252 lines
4.3 KiB
Markdown
# 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.
|
||
|