Zum Inhalt

Updates

Vesana aktualisiert sich über die Admin-UI (Admin → System → Updates). Ein Updater-Dienst im Hintergrund führt das Update aus: Backup, Pull, Migration, Neustart, Health-Check. 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 erstellt vor jedem Update automatisch ein Backup und prüft Diskplatz und Health, bevor er wirklich umschaltet. Manuelle Updates umgehen diese Schutzmaßnahmen.

Kein Kanal-Konzept

Es gibt keine Beta-/Stable-/Nightly-Kanäle. Es gibt immer genau eine „neueste Version" vom Lizenzportal — Vesana zeigt dir „Aktuelle Version" und „Verfügbare Version" gegenüber. Ist ein Update kritisch (Sicherheitsfix, dringender Bugfix), markiert ein rotes „Kritisch"-Badge das Update entsprechend.

Online-Update (manuell)

Voraussetzungen: ausgehender Zugriff auf das Lizenzportal (Update-Check) und die Container-Registry (Image-Pull).

  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. Disk-Space-Check — es müssen rund 4 GB frei sein, denn der Image-Pull lädt die neuen Images zusätzlich zu den alten, bevor aufgeräumt wird
  2. Pre-Update-Backup — immer ein Konfigurations-Backup (kein Voll-Dump; landet im selben Backup-Katalog wie geplante/manuelle Backups, siehe Backup & Disaster-Recovery)
  3. 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
  4. Bei Online-Updates: aktuelle Compose-Datei vom Lizenzportal laden (alte Version wird als Sicherung behalten)
  5. Neue Images pullen
  6. Migrationen über den Init-Container ausführen
  7. Version in der Konfiguration aktualisieren, Stack neu starten

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: idle → checking → downloading → backing_up → migrating → restarting → health_check → done (oder failed).

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.

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.
  • „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

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

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 — Disk-Check, Pre-Update-Backup, Migrationen, Neustart über den Hilfscontainer. Zusätzlich läuft danach ein Health-Check mit Timeout (rund 90 Sekunden), da beim Offline-Pfad kein direkter Zugriff auf externe Erreichbarkeitsprüfungen besteht.

Versionsverlauf

Zwei getrennte Ansichten unter Admin → System → Updates:

  • Versionsverlauf — alle verfügbaren Releases mit Änderungsprotokoll (die letzten fünf sichtbar, „Ältere Versionen anzeigen" für den Rest)
  • 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:

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.

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, prüfen die Signatur, ersetzen ihre eigene Binary und starten den Dienst neu.

Anschluss