Upgrade - ABBYY Documentation

Upgrades von Vantage 3.0 selbstgehostet erfolgen operatorgesteuert. Führen Sie ein Upgrade der Helm-Releases vantage-operator und vantage-selfhosted auf dieselbe neue Version durch. Das neue vantage-selfhosted-Chart verweist auf eine versionierte Workloads-ConfigMap. Dadurch verarbeitet der Operator die Ressource Vantage erneut und reconciliiert die entsprechende Vantage-Version. Automatische Upgrades sind noch nicht implementiert.

Upgrade-Workflow

Der Operator und die Vantage-Charts werden zusammen veröffentlicht und müssen versionsgleich bleiben. Durch die Installation des neuen Operators werden der kompatible Controller und die CRD vorbereitet; durch die Installation des passenden vantage-selfhosted-Charts wird der Verweis auf die versionierte Workloads-ConfigMap aktualisiert und das In-Place-Update ausgelöst. So führen Sie das Upgrade durch:

Installierte Version prüfen

Bestätigen Sie die aktuell ausgeführte Version, indem Sie status.installedVantageVersion der Vantage-Ressource prüfen:

kubectl -n $install_namespace get vantages.vantage.abbyy.com $release_name -o yaml

Beide Charts upgraden

Führen Sie zuerst das Upgrade des Operators durch und aktualisieren Sie dann das Release vantage-selfhosted auf dieselbe Version.

helm upgrade --install vantage-operator $charts_uri/vantage-operator \
  --version $new_version \
  --namespace $operator_namespace \
  --wait

helm upgrade --install $release_name $chart_uri/vantage-selfhosted \
  --version $new_version \
  --namespace $install_namespace \
  --values <your-values-file> \
  --wait

Wenn Sie GitOps verwenden, aktualisieren Sie beide Chart-Revisionen auf dieselbe Version und lassen Sie sie von Ihrem Controller mit Ihrer vorhandenen Wertequelle rendern.

Warten, bis die Ressource reconciliiert ist

Überwachen Sie die Vantage-Ressource auf Ready:

kubectl -n $install_namespace wait \
  --for=condition=Ready vantages.vantage.abbyy.com/$release_name \
  --timeout=30m

Für eine detailliertere Einsicht überwachen Sie den OCI-Migrations-Job und den Anwendungssynchronisierungsstatus von ArgoCD. Die Skill-Installation wird als separater Job ausgeführt, den ArgoCD nicht nachverfolgt; siehe Lifecycle. Wenn ein Chart nicht reconciliiert werden kann, zeigt der Operator die Ursache in status.degradationReasons[] an.

Was sich gegenüber Vantage 2.7 geändert hat

In der selbstgehosteten Version von Vantage 2.7 bedeutete ein Upgrade, den Ansible-Installer-Container mit einer aktualisierten Values-Datei auszuführen und per helm upgrade jedes Chart nacheinander zu aktualisieren – ein Vorgang, der Infrastruktur und Anwendungskonfiguration in einem Schritt betraf. In 3.0 ist das Upgrade der Anwendung von Infrastrukturänderungen entkoppelt:

Schritt	2.7	3.0
Ein Upgrade auslösen	Den Ansible-Installer-Container erneut ausführen	Die passenden neuen Versionen der Operator- und Vantage-Charts installieren
Änderungen pro Komponente anwenden	Ansible führt für jedes Chart `helm upgrade` aus	Der Operator erzeugt ArgoCD-`Application`-Manifeste; ArgoCD reconciliert

Das Installationsmodell aus 2.7 wird in 3.0 nicht unterstützt, und es gibt kein In-Place-Upgrade von 2.7. Der Wechsel von 2.7 ist eine Migration; siehe Migration von Vantage 2.7. Die Upgrades der Vantage-Charts decken nur Vantage Core ab: Software, die Sie separat installiert haben, etwa Ihren Monitoring-Stack, aktualisieren Sie selbst nach Ihrem eigenen Zeitplan.

Nächste Schritte

Architektur

Was der Operator bei jedem Reconcile-Vorgang macht.

Bekannte Einschränkungen

Einschränkungen, die Sie vor der Planung eines Upgrade-Zeitfensters kennen sollten.

​Upgrade-Workflow

​Was sich gegenüber Vantage 2.7 geändert hat

​Nächste Schritte

Architektur

Bekannte Einschränkungen

Upgrade-Workflow

Was sich gegenüber Vantage 2.7 geändert hat

Nächste Schritte