Vantage 3.0 utilise un modèle de déploiement différent de celui de la version 2.7 et des versions antérieures. Les versions précédentes nécessitaient l’infrastructure précisément spécifiée par ABBYY, créée et configurée à l’aide des scripts Ansible et Azure CLI fournis par ABBYY. Ce modèle n’est plus pris en charge dans la version 3.0 :
- Vous provisionnez votre propre infrastructure : le cluster Kubernetes, les bases de données, les comptes de stockage et le Key Vault. ABBYY ne fournit pas de scripts de provisionnement, de modèles ni d’autre automatisation d’infrastructure pour la version 3.0.
- L’installateur déploie uniquement Vantage Core. Les logiciels tiers dont Vantage dépend, tels qu’ArgoCD, votre maillage de services et votre contrôleur d’ingress, votre intégration des secrets et votre stack de monitoring, sont installés et maintenus par vos soins, généralement via Helm.
- Les configurations documentées correspondent aux scénarios testés par ABBYY. Vous pouvez adapter votre installation à partir des exemples documentés ; la validation de cette adaptation relève de votre responsabilité.
Avant de commencer
- Introduction : les différences d’architecture entre les versions 2.7 et 3.0, y compris le passage des scripts Ansible et Azure CLI fournis par ABBYY au modèle operator + custom resource.
- Limitations connues : les limitations actuelles de la version 3.0, par exemple la configuration SMTP, qui ne prend en charge que l’authentification de base (ou aucune authentification). Vérifiez qu’aucune de vos dépendances en 2.7 n’est concernée avant de migrer.
- Prérequis : la version 3.0 introduit de nouvelles exigences d’infrastructure, notamment ArgoCD, un maillage de services et un contrôleur d’ingress pris en charge, une intégration des secrets, ainsi qu’une base de données pour chaque alias de chaîne de connexion répertorié dans Secrets and Key Vault.
Vantage 3.0 Migrator
Notes de version de Vantage 3.0 et Migrator
Consultez l’intégralité des notes de version 3.0, 3.0.1, 3.0.2, 3.0.3 et 3.0.4 sur docs.abbyy.com, y compris les mises à jour de Vantage 3.0 Migrator.
Approche recommandée
1
Mettre en place un environnement 3.0 parallèle
Déployez un environnement distinct en suivant Azure ou Kubernetes autogéré. Notez que le chart Helm
vantage-operator ne prend en charge qu’une seule instance par cluster ; voir Limitations connue.2
Migrer les données avec le Vantage 3.0 Migrator
Utilisez le Vantage 3.0 Migrator pour déplacer les données de votre installation 2.7 vers l’environnement 3.0. Vérifiez d’abord que l’installation 3.0 est saine : attendez que la condition
Ready de la ressource Vantage soit atteinte, puis attendez la fin du job d’installation des compétences. Voir Cycle de vie pour les commandes de surveillance.3
Basculer le trafic
Une fois les données migrées et vérifiées, faites pointer votre DNS / vos clients vers le cluster 3.0. Conservez l’environnement 2.7 comme solution de repli jusqu’à ce que vous ayez validé le trafic de production sur 3.0.
4
Mettre 2.7 hors service
Une fois que 3.0 a fonctionné sans incident pendant votre fenêtre de vérification, mettez l’environnement 2.7 hors service conformément à votre processus habituel de gestion des changements.
Ce qu’il faut préparer pour votre équipe de compte
- Votre version 2.7 actuelle et tous les correctifs hors bande.
- Indiquer si votre configuration de messagerie dépend d’un schéma d’authentification SMTP autre que l’authentification de base : le composant SMTP 3.0 ne prend actuellement en charge que l’authentification de base ou l’absence d’authentification, et SendGrid est le provider de messagerie par défaut. Consultez Limitations connue.
- Le throughput de documents attendu et le nombre de tenants, utilisés pour valider le dimensionnement de l’environnement 3.0.
Prochaines étapes
Vue d’ensemble de l’architecture
Les changements structurels entre les versions 2.7 et 3.0.
Documentation de Vantage 2.7
Référence pour votre déploiement 2.7 actuel jusqu’à la fin de la migration.