Zum Inhalt

Updates

Vesana aktualisiert sich über die Admin-UI (Admin → System → Updates). Ein Updater-Dienst im Hintergrund führt das Update aus: Platzprüfung, Backup, Pull, Migration, Neustart. Entweder stößt du das Update selbst an, oder du lässt Vesana das per automatischem Update erledigen.

Niemals manuell docker compose pull auf einer produktiven Instanz

Der GUI-Updater prüft vor jedem Update den freien Platz, erstellt automatisch ein Backup und prüft eine eigene Override-Datei, bevor er etwas stoppt. Manuelle Updates umgehen diese Schutzmaßnahmen.

Update-Arten und Versionsnummern

Vesana-Versionen folgen dem Schema 1.<Linie>.<Patch>, z. B. 1.902.0, 1.902.1:

  • Eine neue zweite Stelle ist ein Feature-Update: neue Funktionen, gebündelt und vorher getestet.
  • Eine neue dritte Stelle ist ein Patch: ein Sicherheitsupdate oder eine schnelle Fehlerbehebung auf der installierten Version. Ein Patch ändert nichts am Verhalten und bringt keine Datenbank-Änderung mit.

Eine neue Linie (1.<Linie>.0) geht zuerst nur an Instanzen mit Tester-Lizenz und wird erst danach für alle freigegeben — als dieselbe Version, nicht neu gebaut. Eine normale Instanz sieht deshalb nur freigegebene Versionen und deren Patches; Tester-Linien, die zwischen zwei Freigaben lagen, überspringt sie in einem Schritt. Ein Patch erscheint auf der freigegebenen Linie und, falls anders, auf der neuesten Tester-Linie. Auf der Updates-Seite ist ein Patch als „Sicherheitsupdate / Fehlerbehebung" gekennzeichnet, ein als kritisch markiertes Release als „Kritisch"; steht ein kritisches Update bereit, zeigen alle Seiten Super-Admins oben einen roten Hinweis.

Mit Lizenzschlüssel bietet die Updates-Seite nur Versionen an, die bis zum Ende des Update-Zeitraums erschienen sind; eine neuere steht dort als „Verlängerung nötig" und wird auch automatisch nie installiert. Patches einer abgedeckten Linie kommen immer an.

Neuinstallationen (setup.sh, Docker-Tag :latest) bekommen immer die aktuell freigegebene Version.

Online-Update (manuell)

Voraussetzungen: ausgehender Zugriff auf das Lizenzportal (Update-Check) und die Container-Registry (Image-Pull) sowie rund 4 GB freier Platz. Ist weniger frei, sagt die Updates-Seite das schon vor dem Start — mit freiem und nötigem Platz und dem Hinweis, die Festplatte der VM bzw. des Containers zu vergrößern.

  1. Admin → System → Updates öffnen (ein automatischer Check läuft schon beim Öffnen; „Nach Updates suchen" erzwingt einen frischen)
  2. Verfügbare Version + Änderungsprotokoll prüfen
  3. „Jetzt updaten" klicken

Was im Hintergrund passiert

  1. Platzprüfung — es müssen rund 4 GB frei sein, denn der Image-Pull lädt die neuen Images zusätzlich zu den alten. Reicht der Platz nicht, räumt der Updater zuerst alte Vesana-Images ab und prüft erneut; erst wenn es dann noch nicht reicht, bricht das Update ab, bevor etwas verändert wurde
  2. Pre-Update-Backup — immer ein Konfigurations-Backup (kein Voll-Dump; landet im selben Backup-Katalog wie geplante/manuelle Backups, siehe Backup & Disaster-Recovery). Lässt sich kein Backup anlegen, bricht das Update ab — ohne Backup wird nicht aktualisiert
  3. Bei Online-Updates: aktuelle Compose-Datei vom Lizenzportal laden (alte Version wird als Sicherung behalten). Liegt eine eigene docker-compose.override.yml daneben, prüft der Updater sie jetzt gegen die neue Compose-Datei. Passt sie nicht, bricht das Update hier ab, bevor etwas gestoppt wird, und die alte Compose-Datei kommt zurück — siehe Eigene Anpassungen am Stack
  4. Alte Vesana-Images werden aufgeräumt — nur Images mit exakt dem Vesana-Namen und einem Versions-Tag; fremde Images auf demselben Server, deren Name zufällig „vesana" enthält, bleiben unangetastet
  5. Neue Images pullen
  6. Migrationen über den Init-Container ausführen
  7. Version in der Konfiguration aktualisieren, Stack neu starten

Scheitert ein Update, nennt die Updates-Seite den Grund (z. B. zu wenig freier Platz, Lizenzportal nicht erreichbar, Migration abgebrochen); der Update-Verlauf zeigt ihn in einer eigenen Zeile. Bricht eine Migration ab, sagt die Meldung, wie viele Migrationen schon eingespielt sind, dass die Instanz auf der bisherigen Version weiterläuft und dass das Update wiederholt werden kann.

Der Neustart der Dienste läuft in einem eigenen Hilfscontainer, der das Neuanlegen der Container überlebt — auch wenn der Updater selbst dabei neu erstellt wird, bleibt die Instanz nicht mit „502 Bad Gateway" liegen.

Fortschritts-Anzeige

Die UI zeigt den Update-Lauf als Fortschrittsbalken mit klaren Stationen: Prüfen → Backup → Herunterladen → Migrationen → Neustart → Abgeschlossen (oder Fehlgeschlagen).

Der Balken misst dabei wirklich: der Download in Bytes (z. B. „Image 3/7 · 812 MB / 2.1 GB"), Migrationen als Zähler, das Backup nach Dateigröße. Klappt eine Messung nicht, läuft das Update unverändert weiter und zeigt grobe Stufen statt abzubrechen.

Während der Neustart-Phase ist die Oberfläche für kurze Zeit nicht erreichbar. Ein Overlay überbrückt diese Lücke: es pollt gezielt, bis wirklich die neue Version antwortet (nicht nur irgendeine Antwort) — dadurch erscheint kein verfrühter Erfolg, während im Hintergrund noch die alte Version läuft. Bis dahin siehst du einen „Vesana wird gestartet …"-Splash. Danach wartet die Oberfläche, bis die API vollständig zurück ist — du bleibst mit deinen Rechten angemeldet, ein Ab- und Anmelden ist nicht nötig.

Sitzungen überleben Updates

Ein Vesana-Update — manuell wie automatisch — meldet niemanden ab: der angekündigte Neustart übernimmt die laufenden Sitzungen. Nur echte Neustarts bleiben streng: Server-Reboot, ein manueller Neustart des Stacks oder ein Absturz verlangen weiterhin eine neue Anmeldung.

Automatische Updates

Vesana kann sich selbst aktualisieren. Der Schalter sitzt direkt auf der Update-Seite in der Karte „Automatische Updates"; die Einstellungen darunter werden beim Ändern sofort gespeichert.

Einstellung Optionen Bedeutung
Wartezeit nach Release Sofort · 24 Stunden · 3 Tage (Vorgabe) · 1 Woche · 2 Wochen · Benutzerdefiniert (1 Stunde bis 90 Tage) Neue Versionen reifen erst. Installiert wird immer die neueste Version, die mindestens so alt ist — taucht in der Wartezeit eine Korrektur auf, wird direkt die korrigierte Version installiert; ein fehlerhaftes Release geht an der Instanz vorbei.
Kritische Updates sofort installieren an (Vorgabe) / aus Als kritisch markierte Releases (z. B. Sicherheitskorrekturen) überspringen die Wartezeit.
Installationszeitfenster Jederzeit · Nachts (01–06 Uhr) · Eigenes Fenster (von–bis) Ein fälliges Update wartet auf das nächste Fenster. Die Zeitzone wird angezeigt; während der Installation ist Vesana kurz nicht erreichbar.

Nur Sicherheitsupdates und Fehlerbehebungen automatisch

Ist das automatische Update insgesamt ausgeschaltet, zeigt die Karte einen eigenen Schalter „Sicherheitsupdates automatisch installieren". Er installiert ausschließlich Patches der bereits installierten Version (z. B. 1.902.0 → 1.902.1) — ein Feature-Update (neue zweite Stelle) bleibt weiterhin manuell. Ein Patch wird ohne Wartezeit installiert; darunter wählst du das Installationszeitfenster (Jederzeit · Nachts · Eigenes Fenster), in dem er eingespielt wird. Arbeitet gerade jemand, kommt vorher der Hinweis-Dialog mit Countdown.

Bei einer Neuinstallation ist der Schalter an; bestehende Installationen behalten ihr bisheriges Verhalten (aus), bis du ihn selbst einschaltest. Ausschalten geht nur nach einer Warnung in der Karte; solange er aus ist, steht dort „Sicherheitsupdates sind abgeschaltet".

Auch mit einer Tester-Lizenz entscheidest du selbst: Auto-Update, Wartezeit, Zeitfenster und Ablehnen gelten wie bei jeder anderen Instanz.

Tester-Instanz auf Stable umstellen

Mit einer Tester-Lizenz zeigt die Karte die Zeile „Update-Kanal: Tester" und den Knopf „Auf Stable wechseln". Danach bekommt die Instanz nur noch freigegebene Versionen und deren Patches, keine Tester-Versionen mehr. Der Wechsel geht nur in diese Richtung: zurück auf den Tester-Kanal stellt das Vesana-Team.

Was die Automatik sonst noch beachtet:

  • Release-Züge: Bringt ein Tag mehrere Releases, gibt es ein einziges Update auf die letzte Version des Zugs. Ein Release, das binnen weniger Stunden durch einen Nachfolger ersetzt wurde, wird nie installiert.
  • Mindestabstand: Zwischen zwei automatischen Updates liegt mindestens die eingestellte Wartezeit — kein tägliches Update-Geknatter. Ein als kritisch markiertes Release wartet bei „Kritische Updates sofort installieren" auch nicht auf den Mindestabstand.
  • „Sofort" heißt sofort: Steht die Wartezeit auf „Sofort", bemerkt Vesana ein neues Release binnen etwa zwei Minuten; mit Wartezeit prüft sie seltener, weil ohnehin Stunden bis Tage vergehen.
  • Fehlschlag: Scheitert ein automatischer Versuch, versucht Vesana dieselbe Zielversion frühestens nach 6 Stunden erneut. Scheiterte es schon vor dem Eingriff (Lizenzportal kurz nicht erreichbar, zu wenig Platz), reicht eine Pause von 15 Minuten. Ein kurzer DNS-/Netz-Aussetzer lässt ein laufendes Update nicht mehr scheitern: der Abgleich mit dem Portal wird wiederholt und fällt notfalls auf die zuletzt bekannten Release-Daten zurück.
  • Nachvollziehbar: Automatische Updates tragen im Update-Verlauf das Kennzeichen „Auto" und erscheinen im Diagnose-Log.

Die Karte sagt jederzeit, was als Nächstes passiert — „Alles aktuell", „v… reift noch 2 Tage", „Installation im nächsten Zeitfenster (…)" oder „v… wurde abgelehnt". Ein laufendes automatisches Update ist überall sichtbar, auch auf anderen Seiten und im Admin-Bereich.

Ankündigung mit Countdown

Ist ein Update fällig und arbeitet gerade jemand in Vesana, erscheint zuerst ein Hinweis-Dialog „Automatisches Update" mit Countdown von fünf Minuten; er nennt den festen Installationstermin und wann angekündigt wurde. Der Countdown läuft nach der Uhr des Servers, nicht nach der des Browsers, und erscheint auch in einem Hintergrund-Tab. Arbeitet niemand, startet das Update ohne Ankündigung.

Im Dialog stehen — je nach Rechten — drei Wege offen:

Aktion Wirkung Recht
Verschieben (+15 Min · +1 Std · +4 Std) Schiebt den Termin hinaus, insgesamt höchstens 24 Stunden ab dem ursprünglichen Termin updates.defer — Operator, Admin, Super-Admin
Dieses Update ablehnen Genau diese Zielversion wird nie automatisch installiert (nur noch manuell); ein neueres Release wird wieder normal behandelt updates.decline — Admin, Super-Admin
Jetzt installieren Startet das Update sofort, ohne den Countdown abzuwarten updates.install_now — Admin, Super-Admin

Diese Rechte wirken auf die ganze Instanz: sie zählen nur, wenn die Rolle für „alle Tenants" zugewiesen ist (oder als Super-Admin) — ein Recht aus einem einzelnen Mandanten genügt nicht.

Schlägt das angekündigte Update fehl, meldet der Hinweis das im Klartext und bietet „Erneut versuchen" an.

Benachrichtigung bei neuer Version

Unter Admin → System → Updates → „Bei neuer Version benachrichtigen" wählst du einen oder mehrere Benachrichtigungs-Kanäle (E-Mail, Push, Teams, … — angelegt unter Alerting → Kanäle). Jede neue Version, die für diese Instanz verfügbar wird, meldet sich dort genau einmal — mit den wichtigsten Punkten aus den Release-Notes und einem Link zur Update-Seite. Es zählt der Update-Kanal deiner Instanz: eine Instanz mit Tester-Lizenz hört von Tester-Versionen, alle anderen von freigegebenen Versionen; ein Sicherheits- oder Fehlerbehebungs-Patch meldet sich ebenfalls.

Beim Einschalten merkt sich Vesana den heutigen Stand — gemeldet wird, was danach neu erscheint. Ist mit der neuen Version Feedback erledigt, das jemand über diesen Kanal verfolgt, steht es in derselben Nachricht (siehe Feedback-Button).

Kein automatisches Rollback

Es gibt keinen automatischen Rollback-Mechanismus. Schlägt ein Update fehl, bleibt der Stack in dem Zustand, in dem der Fehler auftrat — die Recovery-Strategie ist das Pre-Update-Backup, das der Updater vor jedem Lauf automatisch angelegt hat:

  1. Admin → System → Backup & DR öffnen
  2. Das jüngste „Pre-Update"-Backup suchen
  3. Restore auslösen (Hostname eintippen + Identitätsbestätigung, siehe Backup & Disaster-Recovery)

Das bringt die Datenbank auf den Stand unmittelbar vor dem Update zurück — die Konfiguration, nicht den Messwert-Verlauf, denn das Pre-Update-Backup ist eine Konfigurations-Sicherung. Die Compose-Datei-Sicherung, die der Updater vor Online-Updates anlegt, hilft zusätzlich, falls du auch die Compose-Konfiguration zurückdrehen musst.

Offline-Update

Für Air-gapped-Umgebungen oder wenn der Server keinen direkten Zugriff auf die Container-Registry hat.

Paket holen

Auf einem Rechner mit Internet: Lizenzportal → Releases → Offline-Paket. Datei: vesana-update-vX.Y.Z.tar.gz. Inhalt: Docker-Image-Tarballs, Compose-File, Manifest, Migrations.

Paket einspielen

In der Admin-UI: Admin → System → Updates → „Offline-Update hochladen" → Datei auswählen. Der Upload wird direkt an den Updater durchgereicht, ohne Zwischenkopie auf dem Server; Pakete bis 8 GB sind möglich (ab v1.9.437 — vorher scheiterte der Upload ab 50 MB mit „413 Request Entity Too Large"). Steht ein eigener Reverse-Proxy vor Vesana, gilt dessen Upload-Limit zusätzlich.

Der Updater behandelt das Offline-Paket genauso wie ein Online-Update: Prüfsummen des Pakets prüfen, Platzprüfung, Pre-Update-Backup, Images aus dem Paket laden, Compose-Datei aus dem Paket übernehmen (samt Prüfung einer eigenen Override-Datei), Migrationen, Neustart über den Hilfscontainer. Das Einspielen steht im Audit-Log (update_apply_offline, bei Fehlschlag update_apply_offline_failed).

Versionsverlauf

Zwei getrennte Ansichten unter Admin → System → Updates:

  • Versionsverlauf — die verfügbaren Releases mit Release-Notes (nur Versionen mit Notizen; die letzten fünf sichtbar, „Ältere Versionen anzeigen" für den Rest). Oben steht das Wichtige, alle weiteren Änderungen sind aufklappbar
  • Update-Verlauf — die auf dieser Instanz tatsächlich durchgeführten Updates: Zielversion, Ausgangsversion, Online/Offline, Erfolgreich/Fehlgeschlagen, Zeitpunkt, Kennzeichen „Auto" bei automatischen Updates. Auch fehlgeschlagene Versuche nennen die Zielversion.

Der Updater trifft nur die eigene Instanz

Der Updater erkennt sein Compose-Projekt am eigenen Container. Laufen zwei Vesana-Instanzen auf einem Host, aktualisiert jede nur sich selbst. Liegt die Installation nicht unter /opt/vesana (Installer-Variable VESANA_DIR), trägt der Installer das Verzeichnis als COMPOSE_PROJECT_DIR in die .env ein — genau diese Installation wird dann aktualisiert.

Reverse-Proxy vor Vesana

Die Wartungs-Komponente, die Updates einspielt, ist von außen nicht erreichbar (ab v1.9.437 — vorher war sie unter /updater/… ohne Anmeldung ansprechbar). Alle Funktionen der Oberfläche laufen über die angemeldete API; von außen bleibt genau eine lesende Abfrage offen, der Fortschritts-Status während eines laufenden Updates (/updater/update/status), damit der Balken auch während des Neustarts weiterläuft. Leitest du mit einem eigenen Reverse-Proxy komplett an den Vesana-Webserver weiter, musst du nichts tun. Hast du eigene Regeln je Pfad gebaut, muss nur dieser Status-Pfad durchgelassen werden.

Manueller Notfall-Pfad

Nur wenn die GUI nicht erreichbar ist und auch der Updater-Dienst nicht antwortet. Hast du eine eigene docker-compose.override.yml, hänge an jeden docker compose-Befehl unten zusätzlich -f docker-compose.override.yml an (oder setze COMPOSE_FILE in der .env, siehe Eigene Anpassungen am Stack) — sonst fehlen deine Ergänzungen nach dem Neustart.

cd /opt/vesana

# 1. Backup (zusätzlich zum eingebauten Pre-Update-Backup)
docker compose -f docker-compose.prod.yml exec postgres \
  pg_dump -U vesana vesana | gzip > backup_$(date +%Y%m%d-%H%M%S).sql.gz

# 2. Compose-File aus dem Portal aktualisieren (nur falls vorgesehen)
sudo curl -sSL https://license.vesana.org/api/v1/install/compose -o docker-compose.prod.yml.new
diff docker-compose.prod.yml docker-compose.prod.yml.new
mv docker-compose.prod.yml.new docker-compose.prod.yml

# 3. Images aktualisieren
docker compose -f docker-compose.prod.yml pull

# 4. Init-Container für Migrationen
docker compose -f docker-compose.prod.yml run --rm init

# 5. Stack neu starten
docker compose -f docker-compose.prod.yml up -d

Bei Offline-Update zusätzlich vor Schritt 3:

tar xzf vesana-update-vX.Y.Z.tar.gz -C /tmp/vesana-update
for img in /tmp/vesana-update/images/*.tar; do docker load < "$img"; done

Nach einem solchen Neustart von Hand ist eine neue Anmeldung fällig — nur angekündigte Neustarts aus dem Updater übernehmen Sitzungen.

Profil-Updates aus der Vesana-Bibliothek

Installierte Profile aus der Vesana-Bibliothek, die lokal nicht verändert wurden, aktualisiert Vesana stündlich im Hintergrund. Der Schalter „Profile automatisch aktualisieren" auf dieser Seite (nur Super-Admin) schaltet das ab; Vorgabe: an. Jedes automatische Profil-Update steht im Diagnose-Log. Lokal geänderte Profile werden nie still überschrieben, sie zeigen „Update verfügbar". Nach Ende des Update-Zeitraums der Lizenz gibt es keine Profil-Updates mehr.

Agent- und Collector-Updates

Agents und Collectors aktualisieren sich automatisch beim nächsten Config-Refresh (wenige Minuten Default-Intervall). Sie ziehen die aktuelle Version vom Server, ersetzen ihre eigene Binary und starten den Dienst neu. Eingespielt wird nur eine vom Hersteller signierte Binary, und nie eine ältere Version als die laufende — auch ein übernommener Vesana-Server kann keine fremde Binary unterschieben. Diese Prüfung lässt sich nicht abschalten.

Anschluss