Vantage 3.0 verwendet ein anderes Bereitstellungsmodell als 2.7 und frühere Versionen. Frühere Releases erforderten die von ABBYY exakt spezifizierte Infrastruktur, die mit von ABBYY bereitgestellten Ansible- und Azure-CLI-Skripten erstellt und konfiguriert wurde. Dieses Modell wird in 3.0 nicht unterstützt:
- Sie stellen Ihre eigene Infrastruktur bereit: den Kubernetes-Cluster, die Datenbanken, die Speicherkonten und den Key Vault. ABBYY stellt für 3.0 keine Bereitstellungsskripte, Vorlagen oder andere Infrastrukturautomatisierung bereit.
- Das Installationsprogramm stellt nur Vantage Core bereit. Drittanbietersoftware, auf die Vantage angewiesen ist, wie ArgoCD, Ihr Service Mesh und Ihr Ingress-Controller, Ihre Secrets-Integration und Ihr Überwachungs-Stack, wird von Ihnen installiert und gewartet, in der Regel über Helm.
- Die dokumentierten Konfigurationen sind von ABBYY getestete Szenarien. Sie können Ihre Installation anhand der dokumentierten Beispiele anpassen; die Validierung einer solchen Anpassung liegt in Ihrer Verantwortung.
Bevor Sie beginnen
- Einführung: die Architekturunterschiede zwischen 2.7 und 3.0, einschließlich des Wechsels von den von ABBYY bereitgestellten Ansible- und Azure-CLI-Skripten hin zum Operator- und Custom-Resource-Muster.
- Bekannte Einschränkungen: aktuelle Einschränkungen in 3.0, z. B. dass der SMTP-Pfad nur Basic Auth (oder keine Authentifizierung) unterstützt. Vergewissern Sie sich vor der Migration, dass keine Ihrer 2.7-Abhängigkeiten davon betroffen sind.
- Voraussetzungen: 3.0 führt neue Infrastrukturanforderungen ein, darunter ArgoCD, ein unterstütztes Service-Mesh und einen Ingress-Controller, eine Secrets-Integration sowie für jeden unter Secrets und Key Vault aufgeführten Connection-String-Alias jeweils eine Datenbank.
Vantage 3.0 Migrator
Versionshinweise zu Vantage 3.0 und zum Migrator
Sehen Sie sich die vollständigen Versionshinweise für 3.0, 3.0.1, 3.0.2, 3.0.3 und 3.0.4 auf docs.abbyy.com an, einschließlich der Aktualisierungen für den Vantage 3.0 Migrator.
Empfohlene Vorgehensweise
1
Eine parallele 3.0-Umgebung aufsetzen
Stellen Sie gemäß Azure oder Self-Managed Kubernetes eine separate Umgebung bereit. Beachten Sie, dass das Helm-Chart
vantage-operator nur eine Instanz pro Cluster unterstützt; siehe Bekannte Einschränkungen.2
Daten mit dem Vantage 3.0 Migrator migrieren
Verwenden Sie den Vantage 3.0 Migrator, um Daten aus Ihrer 2.7-Installation in die 3.0-Umgebung zu übertragen. Vergewissern Sie sich zunächst, dass die 3.0-Installation ordnungsgemäß läuft: Warten Sie, bis die
Ready-Bedingung der Ressource Vantage erfüllt ist und der Skill-Installer-Job abgeschlossen wurde. Die Befehle zur Überwachung finden Sie unter Lebenszyklus.3
Traffic umleiten
Sobald die Daten migriert und verifiziert wurden, verweisen Sie Ihr DNS / Ihre Clients auf den 3.0-Cluster. Halten Sie die 2.7-Umgebung als Rollback-Ziel verfügbar, bis Sie den Produktiv-Traffic auf 3.0 validiert haben.
4
2.7 außer Betrieb nehmen
Sobald 3.0 über Ihren Verifizierungszeitraum hinweg stabil gelaufen ist, nehmen Sie die 2.7-Umgebung gemäß Ihrem üblichen Change-Management-Prozess außer Betrieb.
Was Sie für Ihr Account-Team vorbereiten sollten
- Ihre aktuelle Version 2.7 und alle Out-of-Band-Patches.
- Ob Ihr Mail-Setup von einem anderen SMTP-Authentifizierungsschema als Basic Auth abhängt: Der SMTP-Pfad in 3.0 unterstützt derzeit nur Basic Auth oder keine Authentifizierung, und SendGrid ist der Standard-Mail-Provider. Siehe Bekannte Einschränkung.
- Den erwarteten Dokumentdurchsatz und die Anzahl der Tenants, um die Dimensionierung für die 3.0-Umgebung zu validieren.
Wie geht es weiter
Architekturübersicht
Was sich strukturell zwischen 2.7 und 3.0 ändert.
Vantage 2.7-Dokumentation
Referenz zu Ihrer bestehenden 2.7-Bereitstellung, bis die Migration abgeschlossen ist.