Nous avions prévu de migrer vers une version mise à jour de WSO2 Enterprise Integrator, une installation avec environ 100 intégrations, qui se trouvait dans WSO2 ESB 490, DSS, Api Manager et Message Broker. Avec intégration continue CI/CD et services déployés dans le cloud avec des services gérés avec Kubernetes. Une série de composants développés sur mesure, tels que des connecteurs, des médiateurs personnalisés, etc.
Une partie des développements récents, avec une taille gérable et suivant des modèles simples et reproductibles. Une autre partie, développée il y a plusieurs années, par des équipes différentes et d’une taille et d’une complexité qui rendent la maintenance et l’évolution difficiles.
De plus, une série de scripts d’installation et de déploiement étaient disponibles, basés sur gradle et jenkins, bien qu’en cours de migration vers gitlab-ci, ce qui devait également être pris en compte dans notre plan.
Le projet comportait également une restriction de délai qui nous obligeait à être flexibles dans le processus de migration, à partir d’un système déjà en production.
Premier dilemme: vers quelle version migrer?
Les deux versions mises à jour qui ont été proposées comme options pour la migration WSO2 étaient Enterprise Integrator 6.6.0 et 7.1.
Pour prendre la décision avec des informations réalistes sur l’effort et la difficulté que chaque option pourrait entraîner, une série de tests a été réalisée en considérant à la fois l’adaptation des outils de déploiement automatisé et les intégrations.
Les conclusions de cette étude étaient les suivantes:
En général, les fichiers d’application CAR que nous avons utilisés dans les déploiements pour ESB490 étaient tout à fait compatibles avec EI 7.1.0, y compris les éléments de registre, les transformations, la gestion de la charge utile json, les services DSS, les appels au backend, etc. Cela nous a donné l’assurance que notre processus de construction d’intégration ne nécessiterait pas de changements majeurs.
Cependant, EI 7.1.0 représente un changement important car il est orienté vers les microservices, et d’autre part, l’API de gestion utilisée par nos processus de déploiement automatisé a considérablement changé. Par définition, les microservices doivent être immuables et donc l’API d’administration ne doit pas pouvoir les modifier. Au lieu de cela, le microservice doit être repensé et redéployé. Ce fut un changement majeur pour les processus de déploiement.
Un autre problème que cette orientation vers les microservices présentait est que le développement effectué jusqu’à présent n’était pas complètement orienté vers cette architecture, puisqu’il y avait certaines séquences ou modèles partagés, ainsi que certains éléments définis dans le registre (modèles, points de terminaison, configurations, etc. . ) qui étaient également partagées entre différentes intégrations.
Dans l’ESB de WSO2 version 4.9.0 et EI 6.6.0, il existe un contexte global partagé qui permet de partager certains éléments d’utilisation commune pour les intégrations. Cependant, l’amener à EI 7.1.0 aurait nécessité une refonte pour accueillir ces éléments partagés dans un contexte orienté microservices. Ces éléments partagés auraient dû être déployés dans chaque microservice, ce qui aurait obligé tous les microservices à être redéployés chaque fois qu’une modification devait être apportée à ces éléments communs, ou à en faire un microservice lui-même, qui serait utilisé par les différents microservices qui le consomment.
En raison de ces différences trouvées dans EI 7.1.0, qui impliquent un plus grand risque et effort de migration, et étant donné que nous avions une restriction dans le temps disponible, nous avons décidé de migrer d’ESB 4.9.0 vers EI 6.6.0. Bref, ce n’est pas toujours la meilleure option pour migrer vers la dernière version. Il est nécessaire d’analyser les avantages et les inconvénients de chaque option compte tenu des circonstances, du point de vue d’une équipe technique qualifiée.
Préparations de la migration d’intégration
Pour la migration des intégrations, une étude des projets a été réalisée afin de déterminer la typologie selon le modèle de conception qu’ils ont suivi, et les dépendances qu’ils avaient entre eux pour définir l’ordre à suivre.
Fort de ces informations, une liste des projets regroupés selon leur typologie et leur structure définies a été établie, et il a été décidé de commencer à travailler sur un projet de chacune de ces typologies. De cette façon, nous avons pu détecter des problèmes ou des inconvénients dans les phases antérieures de la migration, et ensuite reproduire les solutions dans le reste des projets de manière plus simple et plus rapide.
Une autre étude qui a été réalisée était les dépendances entre les différents projets. Il y avait des intégrations communes qui étaient transversales et utilisées par le reste des intégrations. Il y avait aussi des dépendances directes entre les intégrations. Après avoir passé en revue ces dépendances, un ordre correct a été établi entre elles, ce qui nous a permis de déterminer une stratégie à suivre pour entreprendre chaque intégration et la « feuille de route » pour la mettre en production de manière plus sécurisée, et ainsi éviter les conflits qui en découlent.
La prochaine étape à franchir consistait à examiner la documentation WSO2 concernant les mises à jour de version. Dans notre cas, comme nous étions dans la version 4.9.0 de l’ESB, une ancienne version, et que nous avons migré vers une version récente 6.6.0 de l’Enterprise Integrator, nous examinons d’abord le passage de notre version de l’ESB à une version ultérieure. version, puis le passage de cette version d’ESB à Enterprise Integrator.
- Cette page vous guide tout au long du processus de mise à niveau vers ESB 5.0.0 à partir d’ESB 4.9.0
Mise à niveau à partir d’une version précédente – Enterprise Service Bus 5.0.0 – Documentation WSO2
- Cette page vous guide tout au long du processus de mise à niveau vers WSO2 Enterprise Integrator (WSO2 EI) 6.6.0 à partir de WSO2 Enterprise Service Bus (WSO2 ESB) 5.0.0
Avec ces informations, nous avons pu déterminer les changements qui avaient été introduits à travers les différentes versions, des composants ESB qui avaient été découragés dans les nouvelles versions, différentes fonctionnalités ou comportements, etc. Cela nous a aidés à adapter nos intégrations au nouvel environnement.
Une revue des composants qui avaient été développés sur mesure pour ESB 4.9.0 (connecteurs, médiateurs personnalisés, bibliothèques, pilotes de bases de données, etc.) a également été réalisée afin de déterminer les modifications nécessaires pour les adapter au nouvel environnement.
Une autre des tâches réalisées a été la revue de notre intégration continue CI/CD, pour vérifier quelles modifications étaient nécessaires à apporter pour le déploiement automatique de nos intégrations dans le nouvel environnement. Pour cela, nous avons eu un premier environnement de test d’Enterprise Integrator 660, où nous avons pu apporter les modifications nécessaires dans nos scripts de déploiement de déploiement et le tester grâce à notre intégration continue.
Minimiser les perturbations
Comme il s’agit d’un système en production et que de nombreuses intégrations sont essentielles pour l’entreprise, un objectif prioritaire de la migration était de ne pas perturber le service.
Cela a été facilité d’une part par la gestion de l’infrastructure dans le cloud avec Kubernetes. D’autre part, nous avons effectué différents tests de fiabilité des opérations de déploiement pour vérifier qu’il n’y aurait pas d’impact de la migration pendant que l’entreprise fonctionnait. Sauf en de rares occasions et plus par précaution que par nécessité réelle, presque tous les déploiements ont été effectués pendant les heures ouvrables.
La plupart des intégrations ont suivi le modèle d’un service d’éditeur qui expose une API, qui à son tour écrit des messages dans un sujet, qui est reçu par plusieurs abonnés, qui finissent par transformer le message et l’envoyer, généralement en appelant un backend vers sa destination. Il y avait d’autres intégrations qui suivaient un modèle différent, comme l’exposition d’une API et la lecture ou l’écriture à partir d’un DSS, mais elles étaient moins fréquentes et nous les avons gérées pour les déploiements en tant qu’éditeur.
Pour l’analyse, nous distinguons éditeur et abonné. Pour analyser l’impact, nous avons préparé un projet jmeter qui a généré une séquence continue de requêtes, chaque requête comprenant un identifiant séquentiel pour pouvoir vérifier d’éventuels messages perdus ou en double, qui ont été vérifiés en examinant les journaux d’événements générés dans Kibana, et nous avons testé différentes opérations de déploiement pour analyser son impact.
Pour l’éditeur, la méthode fiable qui a été trouvée consistait à suivre notre processus de déploiement automatisé, en déployant d’abord l’intégration dans EI 6.6.0, puis en déployant l’Api dans Api Manager, afin que le point de terminaison d’Api Manager change de ce qui a été déployé dans ESB 4.9.0 à EI 6.6.0. Cette transition a pris un temps minimum et n’a produit aucun impact de perte ou de duplication de messages, et tout au plus un délai minimum lors du changement de point de terminaison dans Api Manager.
Plus tard, une fois que le fonctionnement normal a été revu dans EI 6.6.0, le fichier CAR qui a été déployé dans ESB490 a été éliminé. Cette même procédure a été suivie pour les projets basés sur le SSD.
Dangers à éviter
Concernant les abonnés, nos tests ont mis en évidence quelques dangers à éviter :
- Si nous nous déployons dans EI 6.6.0 alors qu’il était déployé dans ESB 4.9.0, à la fin, il y aurait un sujet avec deux abonnés, et les messages reçus seraient distribués entre les deux abonnés.
- Comme les abonnés suivent un modèle Store and Forward, basé sur une mémoire de messages, cela a causé un grave problème car un message sérialisé dans une version de l’ESB ne pouvait pas être interprété par l’EI et vice versa. La mémoire de messages est un élément partagé par l’ESB et l’IE, nous n’avions donc aucun contrôle sur qui lisait et écrivait quels messages dans la mémoire de messages, si les deux abonnés travaillaient simultanément.
Solution
La solution que nous avons trouvée pour éviter ce problème était:
- Désactivez l’abonnement à la rubrique dans l’abonné ESB 4.9.0 et attendez que le magasin de messages ait envoyé tous les messages au backend et soit vide pour éviter les problèmes de sérialisation.
- Supprimez le fichier CAR de l’abonné de l’ESB 4.9.0. Ainsi, l’abonnement au sujet était inactif et continuait à recevoir les messages du sujet qui s’y accumulaient.
- Déployez l’abonnement dans IE 6.6.0. Immédiatement, l’abonnement a été réactivé, et les messages qui y étaient accumulés ont commencé à être traités, sans problème de sérialisation car à aucun moment ESB 4.9.0 et EI 6.6.0 n’auraient utilisé le magasin de messages simultanément.
Avec ces opérations, il a été possible d’éviter les problèmes de sérialisation, avec le minimum d’inconvénients de retarder la livraison des messages pendant le temps qu’il a fallu pour déployer le nouvel abonné dans EI 6.6.0.
Problèmes détectés
Au cours de la migration, nous avons rencontré divers problèmes pour adapter et déployer les intégrations dans le nouvel environnement EI 6.0.0. Certains de ces problèmes sont dus à la migration de la version précédente ESB 4.9.0 vers la nouvelle version EI 6.6.0, et d’autres problèmes de la nouvelle infrastructure orientée vers les conteneurs avec kubernetes. Les principaux problèmes que nous rencontrons sont décrits en détail ci-dessous :
Lorsque nous essayons de déplacer un fichier vers un sFTP à l’aide de ‘fileconnector’, une exception est levée si le système ne peut pas identifier les autorisations de groupe/propriétaire.
- Le « médiateur d’enrichissement » modifie la nature de la charge utile de JSON en XML jsonObject même si le médiateur d’enrichissement n’est pas lié au corps.
- Le ‘médiateur payloadFactory’ échoue si vous utilisez des fonctions en ligne directement dans la section ‘format’.
- Dans ESB490, lorsqu’une demande a un en-tête accepte: application / xml et que la réponse est du texte, elle renvoie du texte, tandis que dans EI660, lorsqu’une demande a un en-tête accepte: application / xml et que la réponse est du texte, elle renvoie un xml < node text> avec le contenu.
- En utilisant l’expression xpath sans la fonction de texte ‘text ()’, un nœud XML est renvoyé à la place du contenu du nœud. Ce comportement diffère entre les différentes versions.
- Erreur lors du traitement des paramètres de chemin dans la requête ‘DELETE DSS’.
- Dans certaines intégrations, nous rencontrons le problème que le corps JSON disparaît après un appel au « médiateur d’appel » et ne continue pas dans le flux de la séquence.
- Dans le cadre de la nouvelle infrastructure, un proxy istio a été configuré dans kubernetes pour gérer le trafic des requêtes entrantes et sortantes. Dans certaines des intégrations, nous avons un service proxy pour appeler un backend via istio, et lorsque le backend est inaccessible, il envoie un RST + ACK comme rétablissement de la connexion. Cela provoque une erreur fatale lors du traitement de la réponse dans EI 6.6.0.
- Le proxy istio, dans le trafic sortant, change les en-têtes en minuscules, comme c’est le standard du protocole http-2. Cela provoque l’échec d’EI 6.6.0 lors de la tentative de traitement de la charge utile reçue en réponse, car elle est sensible à la casse.
- Nous trouvons le problème que les messages stockés dans une file d’attente du « Message Store » dans ESB 4.9.0, génère un échec lors de la tentative de les consommer à partir de EI600 en raison d’un problème de format de sérialisation. Cela ne se produit au moment du déploiement que si les deux abonnés sont opérationnels.
- Problèmes avec la configuration ‘timezone’. Dans ESB 4.9.0, le fuseau horaire est au format local, tandis que dans la nouvelle plate-forme EI 6.6.0 est configuré au format « UTC ».
- L’API des services d’administration « services d’administration » passe de la version ESB490 à la version EI660. Surtout, nous trouvons le problème que le service que nous utilisons dans l’ESB490 ‘LogViewer Admin Service’ pour vérifier les journaux des scripts de déploiement n’est plus valable pour EI 6.6.0, car dans cette version la version 2 est utilisée à partir de java ‘ bibliothèque log4j2’, au lieu de la version 1.
Une étude détaillée a été nécessaire pour la plupart des problèmes détectés, et la publication des mises à jour WUM d’EI 6.6.0 par l’équipe produit WSO2 a été nécessaire pour leur résolution. Pour d’autres problèmes, il a été nécessaire d’appliquer des solutions de contournement, ou des ajustements et des changements dans la configuration de la plate-forme kubernetes.
Leçons apprises après la migration des intégrations / Conclusions
Il est très important, au début du projet, d’analyser en détail les dépendances entre les intégrations et à partir de là de générer un plan de migration. Dans notre cas, nous disposions d’un outil qui traite les projets, découvre les éléments significatifs et recherche les relations entre eux, il nous a donc été relativement facile d’obtenir ces dépendances et de préparer un plan en fonction. Nous avons trouvé une intégration avec une conception complexe qui générait de nombreuses dépendances et qui était un goulot d’étranglement dans le plan que nous devions gérer de manière prudente. Ce plan doit tenir compte du fait qu’une partie des intégrations sont dans l’ancien environnement (ESB 4.9.0) tandis que d’autres ont été migrées vers le nouvel environnement (EI 6.6.0).
Dans un projet comme celui-ci, un nombre important d’événements imprévus peuvent survenir et sont très difficiles à anticiper. Un bon moyen de réduire l’incertitude est de trouver un ensemble représentatif d’intégrations de différents types, et de faire une première approximation avec elles pour avoir une première estimation de la complexité par type d’intégration. Dans tous les cas, des événements imprévus se produisent toujours, et il devrait y avoir une prévision de temps pour ce concept afin que le projet soit protégé contre les circonstances imprévues.
La migration simultanée de l’outil d’intégration (wso2) et de la plate-forme sur laquelle il se trouve introduit plus de complexité, car il y a trop de pièces mobiles dans le projet. Il vaut mieux l’éviter, mais c’est souvent difficile à réaliser et le changement de version sert à améliorer l’infrastructure. Dans ce cas, une collaboration très étroite avec les gestionnaires d’infrastructure est requise.
Bien que les versions impliquent des modifications qui en théorie maintiennent la compatibilité et qu’il existe des documents apportant les modifications apportées dans chaque version, en réalité, certains changements subtils de comportement peuvent vous obliger à peaufiner les intégrations et à les adapter.
Il est très important d’avoir une méthode de travail systématique qui documente les adaptations à apporter aux changements ou problèmes connus. Au fil du temps, il arrive un moment où la plupart des problèmes sont connus et une intégration peut être migrée en appliquant une liste de contrôle, à condition de veiller à générer une bonne documentation. Dans notre cas, vers la fin du projet, il était nécessaire de consacrer plus de ressources au processus de migration, et il suffisait pratiquement de leur fournir une liste de contrôle pour les rendre rapidement opérationnels. Une bonne documentation était essentielle pour cela.
