Ce blog est réalisé en collaboration avec Benoit Legue. Nous avons migré récemment toute une plateforme Talend ensemble. Le client a débuté avec Talend Platform il y a fort, fort longtemps – 10 ans c’est long en informatique n’est-ce pas ? Cette migration devait être la 4è ou la 5è…
Ces derniers temps, il y a de nombreux articles qui évoquent le DataOps, où il s’agit de délivrer ces projets data à la manière de ce qui se passe dans le monde du développement classique. Talend a introduit un artefact repository très tôt dans son architecture, et plus tard son composant d’intégration continue avec Talend CI. Mais on ne parlait pas encore de DataOps !
Déjà en 2012, sur un autre projet, nous avions la volonté de découpler toutes les activités de livraison pour les différents “items” gérés. Notre vision se construisait alors avec une certaine nécessité que chaque “items” ait son propre cycle de vie. Si bien que vous pourriez de nos jours par exemple organiser un référentiel tel que celui-ci dans le cadre de projet d’informatique décisionnelle :
Référentiel projet de Data Warehousing / Business Intelligence :
├── documentation
├── provisioning (infrastructure as code : teraform, ansible, …)
└── src
├── apps (application frontend en javascript (nodejs, typescript…)
├── jeux de données (notamment les jeux de données de test, ou de référence)
├── base de données(script d’évolution : flyway, liquidbase….)
├── etls (processus ETL : talend, script…)
├── documents analytiques (rapport, OLAP, tableaux de bord)
├── orchestration (workflow de tâches (DAG): Apache Airflow)
└── metadonnées (schémas base de données, data liaeage…)
Il existe quelques acteurs et projets dédiés à la gestion d’artefacts, ou autrement dit, un gestionnaires de paquets, de librairies ou d’objets binaires. Il s’agit de gérer leur évolution donc leurs différentes versions. Il est tout aussi évident que les métadonnées associées (date de publication, auteur, dépendance…) sont aussi prises en compte.
Comme dans le cadre du projet en question, nous sommes convaincus que vous avez des référentiels, qui plus est sous Nexus (par exemple parce que vous avez une plateforme Talend) et que vous allez avoir besoin de migrer de la version 2.x.y à la version 3.m.n de Nexus.
Dans cet article, nous nous proposons de vous expliquer comment migrer de la version open source de Nexus.
Avant de démarrer vous devez savoir que pour migrer de la version 2.x.y à la version 3, vous allez devoir procéder à une migration intermédiaire vers la dernière version 2.x.y (l’ultime version 2.x.y à cette date c’est la 2.14.13). Et c’est seulement une fois cette migration réalisée que vous pouvez alors mettre à jour votre référentiel avec une version 3.x.
Mise à niveau vers la dernière version 2.
La mise à niveau de Nexus en version 2 est très simple, procédez comme suit :
- Téléchargez la dernière version Nexus 2 à partir de ce site:
- https://www.sonatype.com/download-oss-sonatype
- https://download.sonatype.com/nexus/oss/nexus-2.14.13-01-bundle.zip (vérifier bien que c’est la toute dernière version 2.x.y)
- Toutes les versions de Nexus ont un dossier « sonatype-work« . Créez une sauvegarde du dossier « sonatype-work » de votre ancienne version 2 (par exemple sonatype-work.tar.gz).
- Créez ou identifiez un dossier où installer la version de Nexus que vous avez téléchargée
- Décompressez l’archive nexus-2.14.13-01-bundle.zip dans ce dossier
- Supprimez le dossier « sonatype-work » de la dernière version 2 (dans notre cas 2.14.13 que nous venons de télécharger)
- Copiez / Restaurez le dossier « sonatype-work » de votre ancienne version 2.x.y
- Lancer la nouvelle version de Nexus 2.14.13 (bin/nexus start)
Votre mise à niveau est terminée : en effet, durant le démarrage Nexus 2.14.13 opère la mise à niveau.
Remarques :
- Attention à l’utilisateur et aux droits sur les répertoires de Nexus. Il est déconseillé de le lancer en tant qu’administrateur de la machine.
- Attention aussi au port que vous utilisez lors du lancement de Nexus, surtout si vous souhaitez en exécuter plusieurs instances sur le même serveur (voir fichier conf/nexus.properties)
Mise à niveau de Nexus 2 vers Nexus 3
Nexus 3 arrive avec un utilitaire qui permet de migrer de la version 2 à la version 3. Il faut activer la fonctionnalité et ensuite en suivre l’assistant pour procéder à la migration. Il est d’emblée utile de noter qu’il y a 3 types de mise à niveau possibles :
- Téléchargement via HTTP
- Copie du système de fichiers (si les deux instances 2.14.13 et 3.x.y sont lancés à même le même serveur)
- Copie via un système de fichiers en réseau
Dans le cas décrit ici nous nous utilisons la méthode de téléchargement via HTTP. La méthode employée offre l’avantage de pouvoir migrer des instances installées sur différents environnements distants sur le réseau, depuis des fournisseurs de cloud distincts.
En plus de l’activation de la fonctionnalité depuis l’interface d’administration de la version 3.x ; il faut dans un premier temps créer un “jeton” de sécurité pour autoriser le téléchargement distant au niveau de l’instance en version 2.14.13.
Nous commençons par cette étape.
Connectez vous à votre instance 2.14.13, et cliquez sur “Capabilities” puis “New” :
Une fenêtre apparaît, choisissez “Upgrade : Agent”
Maintenant vous devez paramétrer le jeton de sécurité pour la migration :
Retenez bien ce jeton de sécurité parce qu’il est question de s’en servir un peu plus tard. Si vous l’avez oublié vous pourrez revenir et le modifier. Vous avez bien une nouvelle ligne “Upgrade : Agent” parmi les “Capabilities”.
Maintenant activons la fonctionnalité de migration au niveau de la version 3.x.y
Connectez vous sur l’instance de la version 3, choisissez l’onglet « Administration » puis « Capabilities« . Créez en un nouveau :
Ici, sélectionnez « Upgrade » !
Et créez donc cette fonctionnalité :
Nous sommes alors prêts à employer l’assistant de migration. Nous avons une nouvelle entrée, « Upgrade« , au niveau du menu de gauche dans l’onglet Administration. Regardez, un peu en bas de votre écran. Sélectionnez-le et démarrons l’assistant.
Il est l’heure de renseigner l’url du Nexus 2.14.13 ainsi que le jeton de sécurité que nous avons précédemment créé.
Renseignez les information utiles et cliquez suivant.
Dans le cas qui nous intéresse nous n’avons pas eu à récupérer la configuration du serveur (on se doute que vous en aurez besoin).
C’est maintenant l’heure de désigner quelle méthode de mise à niveau que nous sélectionnons :
La prochaine étape consiste maintenant à sélectionner les référentiels que nous voulons migrer. Sélectionnez-les pour poursuivre :
Dans notre cas nous voulions récupérer « releases » et « snapshots ». Il faut bien noter que l’utilitaire de migration ne sait pas mettre à niveau un référentiel déjà existant en cible mais seulement le créer et l’alimenter !
Vous avez un récapitulatif des éléments qui vont être copiés depuis nexus 2.14.13 vers la version 3.x.
Procédez à la migration !
Un résumé de la migration vous est présenté :
L’utilitaire de migration pourra être employé à nouveau si vous avez besoin de migrer une autre instance de Nexus 2.x.y ! Vous pourrez indiquer alors que celle en cours est finie : cliquez sur « Done ».
Nous espérons, Benoît et moi, que cet article vous sera utile. Nous vous laissons quelques liens :
- Upgrading from 2.x to 3.y
- video : Migrating to Nexus Repository Manager 3
N’oubliez pas d’arrêter votre instance 2.14.13 ! Bonne migration !
Bonjour,
Sur mon installation Nexus 2.8, le dossier « sonatype-work » a été suprimé. Savez-vous comment le restaurer/re-créer afin de pouvoir procéder à la montée en version 2.14 simplement?
Merci par avance.