platform-docs/architecture/06-backend-api.md

2.8 KiB

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:

backends/
├── fedora/
│   ├── backend.sh
│   ├── kickstart.tpl
│   └── README.md
│
├── mint/
│   ├── backend.sh
│   ├── autoinstall.tpl
│   └── README.md

Lebenszyklus

Der Orchestrator arbeitet immer in derselben Reihenfolge:

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.