Wartung und Updates

1. Backend und Frontend getrennt aktualisieren

Backend und Frontend bilden gemeinsam Ephraim, werden aber nicht mit demselben Vorgang aktualisiert. Vor jeder Wartung muss deshalb zuerst feststehen, welcher Bereich betroffen ist. Die folgende Trennung gilt für den gesamten Artikel.

2. Backend auf der Spark: Umfang und Zuständigkeit

Ein Backend-Update bringt den Betriebsstack auf der Ephraim Spark auf einen freigegebenen Quellstand. Super-Admins starten den Vorgang im Webterminal des Frontends. Vorbereitung, Umschaltung, Prüfung und gegebenenfalls Rückfall werden jedoch auf der Spark ausgeführt. Das Webterminal ist dafür nur die Bedien- und Beobachtungsoberfläche.

3. Backend auf der Spark: vor dem Update

Vor einem Spark-Update prüft der Super-Admin die Statusseite. Inference, Embedding, Runtime, Observer, TTS, Logrotation und Supervisor sollen einen nachvollziehbaren Ausgangszustand zeigen. Ein bereits auf der Spark laufender Wartungsjob wird nicht durch einen zweiten ersetzt. Ephraim verweist stattdessen auf den aktiven Job.

Ein geeignetes Wartungsfenster vermeidet unnötige Unterbrechungen im Unterricht. Bei einem vollständigen Update ist mit mehr Dienstbewegung zu rechnen als bei einem gezielten Update. Der sichtbare Plan ist deshalb vor der Bestätigung zu lesen, auch wenn derselbe Ablauf zuvor bereits erfolgreich war.

4. Backend auf der Spark: Sicherheitsmodell des Releasewechsels

Ein Spark-Systemupdate ist ein gebundener Wechsel zwischen vollständigen Releasezuständen des lokalen Betriebsstacks. Das Webterminal liest zuerst den aktuellen Zustand der Spark und stoppt, wenn bereits ein Wartungsjob läuft oder eine sichere Fortsetzung nicht möglich ist.

5. Backend auf der Spark: Update vorbereiten und bestätigen

Ein supervisor update beginnt auf der Spark mit einer Vorbereitung. Ephraim löst den freigegebenen Quellstand auf, bereitet die benötigten Images und Release-Artefakte vor und prüft den Kandidaten. Währenddessen bleibt der laufende Spark-Stack unverändert.

Nach erfolgreicher Vorbereitung zeigt das Terminal Current, Target, Quellcommit, tatsächlich geänderte Dienste, aktive Profile, die genaue Schrittfolge und einen gekürzten Planhash. Erst danach fragt Ephraim das aktuelle Passwort ab. Der Start akzeptiert genau die vorbereitete Plan-ID und den zugehörigen Planhash. Hat sich der relevante Zustand inzwischen verändert, wird der Plan als veraltet abgelehnt, bevor der Stack umgeschaltet wird.

6. Backend auf der Spark: Lauf beobachten und prüfen

Nach dem Start zeigt das Webterminal Job- und Schrittzustände sowie begrenzte Fortschrittszeilen. Längere Wartungsphasen senden regelmäßig Lebenszeichen. Ein Verbindungsabbruch des Browserstreams beendet den Serverjob nicht. Ephraim fragt den auf der Spark gespeicherten Jobstatus erneut ab und verbindet sich wieder.

Besonders die Prüfung großer lokaler Modell- und Release-Artefakte kann mehrere Minuten dauern. Regelmäßige Lebenszeichen bedeuten in dieser Phase, dass die Prüfung weiterläuft. Auch beim geschützten Supervisor-Handoff kann sich der Terminalstream kurz neu verbinden. Maßgeblich ist der anschließend angezeigte Abschlusszustand des gespeicherten Jobs.

Abgeschlossen bedeutet, dass der vorgesehene Ablauf und seine Prüfungen erfolgreich beendet wurden. Danach folgt trotzdem der Betriebscheck: Statusseite neu laden, Releasezustand prüfen und die für den Updateumfang wichtigen Dienste kontrollieren. Logs sind erst dann nötig, wenn Status oder fachlicher Smoke von der Erwartung abweichen.

Der technische Postflight im Webterminal besteht aus drei festen Abfragen:

• supervisor release status für Modus, Jobannahme, Generationen, Current, Previous, Profil und TTS-Zustand.
• runtime status für Runtime-Verbindung und die Zahl bereiter Dienste.
• docker ps für den Zustand der erwarteten Stackdienste.

Stack- und Supervisor-Generation müssen übereinstimmen. Alle erwarteten Dienste sollen bereit sein. Das neue Current muss dem bestätigten Ziel entsprechen und Previous den vollständigen Zustand vor dem Update bezeichnen.

7. Backend auf der Spark: Baseline als einmaliger Übergang

Eine bestehende Spark-Installation braucht vor dem ersten kontrollierten Releasewechsel eine vertrauenswürdige Ausgangsbasis. Dafür wird der feste Hostkoordinator außerhalb des normalen beweglichen Supervisor-Images vorbereitet. Anschließend inventarisiert die einmalige Baseline den laufenden Spark-Stack, prüft die Dienste und bindet den ersten vollständigen Releasezustand.

Im Webterminal zeigt supervisor baseline nur dann einen startbaren Plan, wenn die betrieblichen Voraussetzungen erfüllt sind. Der Super-Admin bestätigt auch diesen Vorgang mit dem aktuellen Passwort. Hostkoordinator-Installation oder Reparatur sind keine normalen Webterminalaktionen und gehören in eine gesondert geführte Systemwartung.

8. Backend auf der Spark: Kompensation und Rollback

Scheitert ein Spark-Update während der Umschaltung oder Qualifikation, versucht Ephraim anhand des auf der Spark persistierten Ablaufs den vollständigen Job-Ausgangszustand wiederherzustellen. Das ist die automatische Kompensation desselben Updates und keine freie Auswahl irgendeines früheren Images.

Der manuelle Befehl supervisor rollback ist davon getrennt. Er zeigt Current, das committed Previous, Profile, Schritte und den gebundenen Planhash. Nach erneuter Passwortbestätigung darf nur genau dieses Previous für Stack und Supervisor wiederhergestellt werden. Freie Image-IDs, Hostpfade oder Shellbefehle sind nicht Teil dieses Vertrags.

9. Backend auf der Spark: gezielte Dienste und Blocker

supervisor update <dienst> begrenzt den fachlichen Updateumfang auf einen erlaubten Dienst. Der Zielname wird gegen die bekannte Dienstliste geprüft. Ein gezieltes Update bedeutet trotzdem nicht, dass technische Abhängigkeiten ignoriert werden.

• Runtime und Observer werden gemeinsam behandelt, damit ihr interner Vertrag zusammenpasst.
• Inference wird so aktualisiert, dass der speicherintensive Start nicht unkontrolliert mit Embedding konkurriert.
• Ein deaktiviertes oder unbekanntes Ziel wird vor dem Jobstart abgelehnt.
• Der sichtbare Plan entscheidet, welche Dienste tatsächlich geändert oder neu gestartet werden.

Der Befehl supervisor release status zeigt den Releasezustand der Spark mit Jobbereitschaft, Generationen, Current, Previous, Profilen und einem sicheren Blocker-Code. Ein Blocker ist kein Anlass, Schutzprüfungen zu umgehen. Er zeigt, dass Zustand, Baseline, Hostkoordinator oder Recovery zuerst geordnet werden müssen.

Wenn Ephraim einen Zustand als manuelle Wiederherstellung erforderlich markiert, bleiben die zugehörigen Nachweise erhalten. Unbekannte Container, widersprüchliche Releasezustände oder ein nicht sicher auswertbarer Rückfall werden nicht automatisch überschrieben. In diesem Fall wird die Wartung gestoppt und technisch verantwortlich geklärt.

10. Frontend auf dem Webserver: kontrolliert aktualisieren

Ein Frontend-Update betrifft die PHP-Anwendung, die Browseroberfläche und die Admin-APIs auf dem Webserver. Es wird nicht mit supervisor update gestartet und verändert keine Container oder Releasezustände auf der Spark. Der Webserver-Deploy wird als eigener betrieblicher Vorgang geplant und geprüft.

1. Freigegebenen Frontend-Stand und enthaltene Datenbankmigrationen gemeinsam prüfen.
2. Anwendung auf dem Webserver kontrolliert aktualisieren.
3. Ausstehende Datenbankmigrationen einmalig über den getrackten Migrationsablauf anwenden.
4. Langlaufende Webserver-Worker neu starten, wenn ihre PHP-Logik geändert wurde.
5. Webanwendung, Anmeldung, Adminbereich und Verbindung vom Webserver zur Spark prüfen.

Die Pflege eingebundener Web-Bibliotheken gehört ebenfalls zum Frontend auf dem Webserver, nutzt aber ihren eigenen Freigabeablauf. Regelmäßige Datenpflege läuft über Cron und ist kein Code-Update des Frontends.

11. Getrennte Betriebschecklisten

Backend auf der Spark

1. Status der Spark und aktiven Supervisor-Job prüfen.
2. Passendes Wartungsfenster und Updateumfang wählen.
3. Plan vollständig lesen, insbesondere Dienste, Profile und Schritte.
4. Aktuelles Passwort erst nach der Planprüfung eingeben.
5. Job bis zum terminalen Zustand beobachten und einen Streamabbruch nicht mit einem Jobabbruch verwechseln.
6. Status, Releasezustand und betroffene Spark-Dienste nach dem Lauf erneut prüfen.
7. Bei Fehlern automatische Kompensation abwarten und Blocker nicht durch freie Eingriffe umgehen.

Frontend auf dem Webserver

1. Frontend-Stand, Migrationen und betroffene Worker bestimmen.
2. Webserver-Deploy und Migrationen als zusammengehörigen Vorgang ausführen.
3. Betroffene Worker neu starten und ihren Status prüfen.
4. Frontend-Funktionen und Verbindung zur Spark kontrollieren.