Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// installation

Updates

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

basebox mit Helm aktualisieren: Changelog lesen, sichern, vor dem Anwenden rendern, Upgrade im Wartungsfenster, Datenbankmigrationen, Prüfung – und was ein Rollback voraussetzt. Dazu die Updates unterhalb von basebox: Betriebssystem, Treiber, Kubernetes. Es gibt keine automatischen Updates; Sicherheits- und Funktionsupdates werden per E-Mail und Release Notes angekündigt, die Installation liegt beim Betreiber.

Aktuelles stabiles Release

Chart basebox.ai 0.3.32 → basebox 1.8.8. Historie: Versionsmatrix.

Ablauf eines basebox-Upgrades

1. Lesen

Changelog und Release Notes der Zielversion: neue Funktionen, geänderte Standardwerte, Migrationshinweise, neue Umgebungsvariablen. Prüfen Sie, ob Ihre Values-Dateien angepasst werden müssen (etwa neue Konnektor-Werte oder umbenannte Schlüssel).

2. Sichern

Dump oder CloudNativePG-Backup der aisrv-db (und der übrigen Datenbanken), Secrets, Values-Dateien, helm list -n basebox – siehe Backup & Wiederherstellung. Optional AISRV_DB_MIGRATE_BACKUP: "true" mit persistentem AISRV_DB_MIGRATE_BACKUP_DIR.

3. Rendern

helm template basebox oci://gitea.basebox.health/basebox-distribution/helm/basebox.ai \
  --version <ziel-chart-version> \
  --namespace basebox \
  -f values.customer.yaml -f values.mcp.yaml \
  > /tmp/basebox-rendered.yaml

grep -nE 'image:|host:|nvidia.com/|name: inference' /tmp/basebox-rendered.yaml

Prüfen: neue Image-Tags plausibel, Ingress-Host unverändert, GPU-Requests wie bisher, externe Inferenz weiterhin ohne inference-Deployment.

4. Aktualisieren

Im Wartungsfenster, mit denselben Values-Dateien wie bei der Installation:

helm upgrade basebox oci://gitea.basebox.health/basebox-distribution/helm/basebox.ai \
  --version <ziel-chart-version> \
  --namespace basebox \
  --reset-then-reuse-values \
  --wait \
  --timeout 120m \
  --values values.customer.yaml \
  --values values.mcp.yaml

--reset-then-reuse-values übernimmt die neuen Chart-Standards (Image-Versionen) und behält Ihre Overrides. Alle Values-Dateien angeben, die die Installation nutzt. Das Chart aktualisiert in der richtigen Reihenfolge – Datenbanken (bei Schemaänderungen), Backend-Dienste, IDP, Inferenz, Frontend.

5. Migrationen

AISRV und storesrv migrieren ihre Datenbanken beim Start, wenn AISRV_DB_MIGRATE / STORESRV_DB_MIGRATE auf true stehen: Migrationen sind eingebettet, nummeriert (Vnnn__name), werden sequenziell angewendet, in _migrations_history verfolgt und per Prüfsumme validiert. Beobachten:

kubectl -n basebox logs -l app.kubernetes.io/name=aisrv -f | grep -i migrat

Migrationen sind vorwärts gerichtet. basebox 1.8.6 ergänzt die AISRV-Migration V32; eine Rückkehr zu einer älteren Version erfordert die Wiederherstellung des AISRV-Backups von vor dem Upgrade zusammen mit dem früheren Helm-Release.

6. Prüfen

helm list -n basebox                               # neue Chart-/App-Version
kubectl -n basebox get pods                        # alle Running, keine Neustarts
kubectl -n basebox get deployments -o wide         # neue Images

Dann: Login, Chat, eine RAG-Antwort, ein Upload, „Über" zeigt die neue Version – die Kurzform von Installation prüfen. Die Inferenz braucht nach einem Neustart Minuten zum Warm-up.

7. Festhalten

Manifest aktualisieren: Chart, App, Image-Digests, Datum, wer. Administratoren informieren; sie sehen Änderungen im Changelog.

Rollback

Nur mit Backup:

helm rollback basebox <revision> -n basebox oder helm upgrade … --version <alte-chart-version> mit den alten Values.
Wurden Datenbankmigrationen angewendet, zuerst die Datenbanken aus dem Backup von vor dem Upgrade wiederherstellen (siehe Backup & Wiederherstellung), dann das alte Release starten.
Prüfen wie oben.

Ohne Backup ist ein Rollback nach Migrationen nicht möglich – deshalb Schritt 2.

Updates unterhalb von basebox

Komponente	Vorgehen	Vorsicht
Ubuntu	`sudo apt update && sudo apt upgrade -y`; `unattended-upgrades` für Sicherheitsupdates	Kernel-Updates → Neustart planen; NVIDIA-Treiber muss zum Kernel passen
NVIDIA-Treiber	`sudo apt install --upgrade nvidia-driver-<version>`	Kompatibilität mit CUDA-Version und vLLM prüfen; zuerst in Nicht-Produktion testen; MIG-Layout nach Neustart prüfen
CUDA	Nur bei Bedarf der Inferenz-Runtime	Treiber-/Toolkit-Matrix beachten
Kubernetes	kubeadm-Upgrade-Pfad, eine Minor-Version je Schritt	Kubernetes-Dokumentation; Cluster-Backup (etcd) vorher
GPU Operator	`helm upgrade` im Namespace `gpu-operator`	Treiber-Container vs. Host-Treiber konsistent halten
CloudNativePG-Operator	`helm upgrade` in `cnpg-system`	Release Notes; Datenbank-Backups vorher
Ingress-Controller, cert-manager	Nach deren Dokumentation	Annotationen und ClusterIssuer prüfen

Regel: eine Schicht je Wartungsfenster, danach Abnahmeprüfung. Aufräumen: sudo apt autoremove -y; docker system prune nur mit Bedacht.

Abgeschottete Umgebungen

Images der Zielversion und ggf. neue Modellartefakte vorab in den Mirror übertragen; helm template gegen den Mirror prüfen; Modelle mit HF_HUB_OFFLINE=1. Das Transferverfahren stimmen Sie mit support@basebox.ai ab.

Betrieb durch basebox

basebox kündigt Release, Zeitpunkt und Auswirkung an, sichert, aktualisiert im freigegebenen Fenster und berichtet mit Manifest – Ablauf unter Betrieb durch basebox.

Nächster Schritt: Skalierung