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:
|
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
|
## 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.
|
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