<disclaimer> As a member of the Archiva team (though rarely active, I admit) I will try to defend it throughout this article. However, being a professional consultant first and foremost, I hope to keep my objectivity. I’ll let you be the judge … </disclaimer>

Having recently migrated a significant number of repository servers from Apache Archiva to Sonatype Nexus, I would like to share with you the process I followed, some tips, and point out a few pitfalls I encountered.
A big Thank you to Tarpoon, C’est pas dur and all of my team for helping.

Introduction

Background

A little background to this migration: We had a large enterprise-scale implementation with dozens of JEE projects of all sizes (from a mouse to the ocean liner – and NO! I am not talking about the Titanic!), and at least 200 active developers accessing the system simultaneously during the day.
Most projects are using Maven. To help teams to make better and faster builds we offered a complete infrastructure for continuous integration: a big server (Dual QuadCore Xeon with 16GB RAM running Red Hat Enterprise Linux 5.1),  hosting an Atlassian Bamboo continuous integration server with (approximately): 110 (real time) continuous integration builds, 40 (daily) maven sites builds, 20 (daily) Sonar builds. It also hosted a Maven repository server (Archiva 1.1.1 before migrating), which stored a little less than a dozen local repositories and provided a proxy and cache for twenty external repositories (for almost 400GB of data).
The majority of that space was used by the repository of internal snapshots (200GB) and the repository of internal releases (150GB). To understand these sizes you must know that some projects may produce (for good or bad reasons) some EARs up to 100MB in size. By adding the sizes of JARs and WARs that compose these EARs, each deployment quickly grows to take up a lot of space.

Why change?

For several months we were having stability issues with our integration environment. From one build to another we would see execution times fluctuate widely. We also had intermittent errors that were not related to projects, but to the infrastructure :

• 500 or 502 errors on uploads in Archiva without any apparent reason (I tried to track down the issues without success),
• Many periods of unavailability of Archiva or Bamboo after exceeding the maximum number of open file descriptors allowed for the user. We must concede that these tools handle a lot of files (downloads, uploads, and other manipulations on a large number of artifacts). Archiva easily exceeds the default limit of 1024 descriptors which forced us to increase it. But even at 2048 Archiva would still occasionally exceed the limit.
• Inability to download snapshots if the local repository used by Bamboo was emptied just prior to that. This resulted in regular failures of our Maven sites or Sonar builds.

We recently submitted a bug against Archiva (MRM-1136), for which I spent several hours diagnosing the issue (problems with management of meta-data issued by Maven 2.1.0). To resolve the issue would require us to quickly upgrade to Archiva 1.1.4 or 1.2.

All of these problems, even though they were only occasional, strongly discredited our continuous integration service. How could we criticize a project for not using our CI if it kept sending them false negatives? They already have enough work with addressing real errors in their builds. The continuous integration environment must be as reliable as a Swiss watch.

It was time for us to act.

We could update Archiva, which would entail significant validation costs without much improvement. Apart from the incompatibility with Maven 2.1.0, nothing suggested that the new version fixed any of our problems and there were few improvements/new features at that time, due to lack of time by the maintainers.

The other choice was to get another tool with the potential to meet the new requirements.

The feedback from the community about Nexus was very encouraging. Moreover, the latter pro version opens up new possibilities for the future with its innovative features:

• Staging repositories to put artifacts being validated in a temporary area prior to delivery.
• Opportunity to proxy and aggregate eclipse update sites. Currently we are doing it by hand, which is expensive, complicated (I hate P2), and boring.
• and more…

As the situation seemed to be calling for it, we decided to try our luck with Nexus.

Migration

Let’s get started.

Existing environment

A little overview of our existing environment. Before the migration, our environment was like this:

The environment before the migration

We were hosting our internal repositories in what Archiva calls managed repositories. There is one for releases, one for snapshots and another one for third-party libraries (often those delivered by closed-source vendors).
To cache external repositories (configured as “remote repositories”) we are using two more repositories (one for external releases and one for external snapshots).

Our Archiva shows two groups: One to access released artifacts, and another one for snapshots. We never set up a unique group with access to both of them because in our tests we noticed that Archiva often had issues merging descriptors coming from several repositories (maven-metadata.xml), and it can have dramatic consequences if you mix up releases and snapshots.

Groups allow to greatly simplify Maven configuration, avoiding the need to declare too many repositories. Moreover, they enhance your Maven experience, speeding up your builds. Each missing dependency request is sent only once to each group, while the process in the background polls each repository in the group and maintains a cache about missing dependencies to further speed up the build. Sending missing dependency requests to several repositories is an inexcusable waste of time.

Repository users (developers and the continuous integration server) access them using these settings :
[xml]

By redefining the central server address (normally located here: http://repo1.maven.org/maven2/) we configured Maven to look only for released artifacts in our group in Archiva. This gives us access to both internal and external releases. In the same way, the repository snapshots allow us to obtain development versions of all artifacts.

Constraints

Migrating a server isn’t easy when you have 200 developers using it every day.

First, we had to be sure to only stop the service for a very short time (or we would have to do it outside of working hours… ouch!!!). Stopping the continuous integration server temporarily isn’t such a big problem. Asking all teams to use maven in offline mode, and not to use our repositories is more difficult. Usually, we don’t have to wait long before someone needs to download a new artifact or a project has to do a release.

Secondly, it was mandatory for us to keep the compatibility with preexisting Maven settings. Due to the large number of projects and developers it would be impossible to change all repositories settings in Maven configuration. It would impact all projects and all developers if we changed the upload URLs (distributionManagement) and download settings (repositories).

The process

To reduce cost, we decided to not perform our tests in a test environment. This would require us to duplicate the entire integration environment we have in production.
After some basic tests performed on the tool, the real baptism by fire was the scalability of the server (with an increasing volume of data and number of users).
During migration system resources allowed us to easily handle both servers in parallel. We chose the strategy to run Archiva and Nexus in parallel and to switch services to the new server one after another, while keeping the fallback option to revert if necessary.

We had enough space to rebuild caches of external repositories (this required only a few gigabytes), however we could not duplicate our internal repositories, which are too large, and we could have consistency issues. We also did not want to give both products access to internal repositories, because we feared they might access them simultaneously and corrupt our data. Therefore we began our migration leaving our internal repositories on Archiva planning to move them to Nexus at the end of migration.

For URL compatibility we used rewriting rules on the Apache server. It would switch between old and new URLs in a transparent manner.

Installing Nexus

We performed a classic installation of Nexus 1.3.2 (the opensource and standalone bundle) adjusting a few parameters such as the HTTP port, the paths of data and log directories to conform to the organization of our server. All this was quickly done because unlike Archiva we did not have to create a database (which had to be in mysql to follow our standards). Our server was up and ready to be configured.

Configuration of groups and external repositories

We started the Nexus configuration by creating proxy repositories. We also added, for purposes of migration, proxies for our internal repositories hosted on Archiva.

The GUI is ergonomic which makes the registration of 20 external repositories very bearable. Thank you ExtJS!

Unlike Archiva which proposes to store the artifacts of external repositories in the same local repository, Nexus stores the contents of each in a dedicated repository (proxy).

Regarding settings of external repositories, it should be noted that we lose the opportunity provided by Archiva to have white and black lists of artifacts coming from each external repository. Nexus uses the concept of “routes” for this type of filtering. Unfortunately we can apply those routes only at a group level and not on a repository.
Since some lists that we have in Archiva are only for performance issues (e.g. do not query a repository in which we know that a certain artifact is not located), we decided to not duplicate this setup in Nexus waiting to see if there were real problems.

In our setting we faced a first disappointment. As we have to proxy some repositories hosted internally (the one delivered by the Sonar server and all of those always on Archiva during the migration) we were forced to declare the company web proxy on each proxy repository. It is impossible to define the web proxy in the global configuration of Nexus and to disable it on a given proxy repository (NEXUS-2317).

While our external repositories configuration was almost complete, we had our first big setback. We discovered that it was impossible to proxy repositories which are in the legacy layout of maven 1 (at Atlassian and dev.java.net for example).
To achieve this we need to create virtual repositories which are used by Nexus to convert a repository from one format to another. Tough luck, because two bugs (NEXUS-1909, NEXUS-1910) prevented us from doing it.
Fortunately for us, the Nexus team has been very responsive and was able to incorporate the corrections to these bugs in version 1.3.3 which was published the day after our discovery. Otherwise we have to admit that we probably would not have continued our tests on Nexus.
We have updated our server which allowed us to see that the process was very simple since the application, its configuration, and the data were all well separated.

We finalized the configuration of Nexus by creating groups. That is the same concept as in Archiva (which copied it).
The configuration of groups is however relatively poorly designed in terms of ergonomics. We had to select each repository we wanted to add to the group and then put it in the correct order in the list. The order is very important, because Nexus will use it to search for artifacts. We must therefore place internal repositories prior to external ones. The problem is that this list displays only the name of each repository (and the name is often truncated because of its length). So you should be careful in naming your repositories to be able to easily sort them when you have several dozen in a group.

We followed Nexus recommendations by creating a single group that exposes all releases and all snapshots. (This will help us avoid having to battle the screen for configuring a group twice ).

From now we were supposed to be able to download all artifacts needed to build our projects with Nexus.

After several successful tests on our desktop we tested the whole system with our continuous integration server.
We deleted its local repository and updated its configuration:

[xml]




nexus
*
http://serveur.entreprise.fr/nexus/content/groups/public/

Please note: I am not at all a fan of using the mirror * which requires us to put releases and snapshots in the same group. However, this is the only solution, as there is no way to tell Maven to find releases on one mirror location and snapshots on another one. I find this dangerous because e.g. when you call a plugin without defining its version (a plugin in command line such as eclipse:eclipse or archetype:generate) you may retrieve a snapshot version of it. Thus you have to take care to follow the recommendation of Maven to define all the versions of plugins that are used in your project descriptor (directly or by inheritance) to avoid surprises. In our context we won’t have this issue since the recommendation is followed by all projects using a parent POM that is setting all versions for them.

The environment with Nexus and Archiva running in parallel was now ready to go :

The environment while migrating

Nothing changed for developers who still use Archiva while the continuous integration server retrieves all artifacts from Nexus.

Tuning

After testing it a few days we could see that Nexus sometimes had difficulty quickly delivering artifacts. The time has come to look at a few more advanced settings.

Routes allow to restrict the list of repositories that Nexus has to verify when we request an artifact to a group. This can be done via permissions or prohibitions.

The first route we create is the one which tells to Nexus to search for our artifacts (.*/com.mycompany/.*) only in proxy repositories giving access to our internal artifacts on Archiva. When the switch to Nexus will be completely finalized, this route will point only to our internal repositories hosted by Nexus.

We also add rules for .*/org/apache/.* and .*/org/codehaus/.* which are heavily used by Maven, so that artifacts are retrieved only from the central repository and snapshots repositories of each community.

This gave a pretty good boost to our Nexus implementation.

After several days of use by the continuous integration server, Nexus was running fine. Therefore we got ready for the second part of our migration: hosting of our internal repositories on Nexus.

Setting internal repositories and security

Before we could move internal repositories from Archiva to Nexus we had to create hosted repositories. We created directories for our repositories in a different location from Archiva, as to not let both products access the same data. We reused repository identifiers used in Archiva to easily create rewriting rules on Apache HTTP server.

We spent some time learning the security mechanism in Nexus. Settings are so fine that even the most basic use cases require convoluted settings.

We began by creating privileges (read, write, update) on each hosted repository. We created roles that grouped some privileges on hosted repositories together. In our case, one role to deploy released artifacts on repositories (for projects teams) and another role to deploy snapshots on repositories (for continuous integration server).

We finished by creating users with roles defined above without forgetting the role to download from any repository.

Internal repositories were ready, all was left to do was to move data to Nexus and to stop Archiva.

The final steps

To keep the compatibility between Archiva and Nexus we had to do two things.
For each internal repository on which we’ll have to upload artifacts we explicitly wrote a rule to transform the URL from Archiva to Nexus.
Apache configuration example:
[text]
RewriteRule ^/archiva/repository/internal-releases/(.*) http://localhost/nexus/content/repositories/internal-releases/$1 [P]
RewriteRule ^/archiva/repository/internal-snapshots/(.*) http://localhost/nexus/content/repositories/internal-snapshots/$1 [P]
RewriteRule ^/archiva/repository/third-parties/(.*) http://localhost/nexus/content/repositories/third-parties/$1 [P]
[/text]
For all other types of read access we just created a rule which transfered them to our unique group in Nexus.
Apache configuration example:
[text]
RewriteRule ^/archiva/repository/[a-z\-]+/(.*) http://localhost/nexus/content/groups/public/$1 [P]
[/text]
Now we were ready to migrate:

1. Stop Nexus.
2. Stop Archiva.
3. Install rewriting rules on Apache.
4. Move content of internal repositories from Archiva to Nexus.
5. Restart Nexus.

On D-day we made the switch in less than 10 minutes. Nexus took a few hours to index the hundreds of GB of data, but without taking much of a performance hit.

The final environment

Despite some pitfalls we encountered, the migration wasn’t technically really complex. We did it in 2 weeks and we spent less than half that time actually working on it.

Now we are studying how to configure scheduled services. Sonatype made a major effort on product documentation. It allows us to quickly discover all its features. However, we are disappointed when we want to go further than the reference guide. Some best practices about the usage of the tool in a corporate environment are still missing:

• What scheduled tasks should be used?
• Under what circumstances?
• When?
• Why should we repair metadata?
• Why should we delete caches?
• How are we supposed to use the trash?

Results

Two weeks after the migration we drew a first conclusion of our Nexus experience.

Let’s begin by changes on issues we previously had with Archiva and which led us to attempt the Nexus adventure.

The number of file descriptors simultaneously opened

It’s a little bit early to declare victory, however after running for two weeks we can see that our problem on the number of file descriptors opened simultaneously disappeared. Whereas Archiva easily exceeded the 1024 descriptors opened, Nexus uses only 400 which enormously reduces the load on the server.

Number of file descriptors simultaneously opened by Archiva

Number of file descriptors simultaneously opened by Nexus

Memory consumption

Even if we had enough RAM, Archiva is a big consumer of memory. Archiva took an average of 1.3 GB to run. Nexus requires many less and works with 400MB (Even my Eclipse requires more ). It saves almost 1GB that we can now allocate to our builds.

Memory consumption by Archiva

Memory consumption by Nexus

Not found snapshots

Sadly this problems always persists. Because migration to Nexus hasn’t fixed it, we investigated a little bit more and discovered two causes for it :

• The first one is a bug in Maven (MNG-4142) : It’s a subtle problem halfway between the use of artifacts with classifiers and a corruption of metadata in the local repository.
• The second one is a set of bugs in Nexus (NEXUS-1333, NEXUS-2036): The scheduled service used to repair metadata deletes them if it cannot read it. The problem is that it doesn’t succeed to read them if you are using some deprecated properties like {parent.*} (replaced by ${project.parent.*}) or ${pom.*} (replaced by ${project.*}). Note that NEXUS-2036 is marked as fixed on version 1.3.4.

Nothing is perfect

A bug we didn’t have before appeared with the usage of Nexus. Because of our usage of rewriting rules in apache, Maven now complains that cookies are rejected when we upload artifacts on an internal repository (NEXUS-1967). This is a minor issue which doesn’t alter our system, but is annoying because it pollutes our Maven logs on the integration server.

But we had a good surprise

Resource savings on the server (IO, RAM) and the quality of Nexus on the speed to upload artifacts (whatever their size) lead to an important improvement of quality of service and stability of the continuous integration server. As you can see below on some graphs taken from different builds in Bamboo there’s a big difference between before and after Nexus. Build times decreased and are consistent like never before.

Conclusion

Did we find the silver bullet ? Of course, no. I have already listed some constraints and problems we had and there are probably many others to discover (the team already has a good backlog). Any product can be improved. Despite all that, how could I say something other than… migrate! It’s unfortunate for me to have to admit this as a member of the Archiva team, but my own research proves it. Nexus is a product of great quality, which delivers the service you need for your development projects very well. Furthermore, developed by full-time employees (thank you Sonatype), it enjoys an easily accessible and responsive support (I recommend the channel #nexus on #irc.codehaus.org). Archiva itself is governed by the laws of open source, suffers from the lack of time of its maintainers (even if they are doing as much as they can) which doesn’t help it to stay in the competition.

So, enjoy and benefit from service and quality by adopting Nexus!

Tout d’abord revenons sur les problèmes que nous avions avec Archiva et qui nous ont poussés à tenter l’aventure Nexus.

Le nombre de descripteurs de fichiers ouverts par le produit

Il est encore un peu tôt pour crier victoire cependant après plus de deux semaines d’exploitation nous pouvons constater que notre problème sur le nombre de descripteurs de fichiers ouverts simultanément a disparu.Là où Archiva dépassait facilement les 1024 descripteurs ouverts, Nexus se contente d’environ 400 ce qui soulage énormément la machine.

Nombre de 'file descriptors' ouverts par Archiva

Nombre de 'file descriptors' ouverts par Nexus

La consommation mémoire

Même si cela n’était pas très grave puisque nous avions les ressources nécessaire Archiva était très consommateur de mémoire. Il en prennait en moyenne 1,3Go. Nexus est beaucoup moins gourmand et tourne avec moins de 400Mo (Même mon eclipse consomme plus ).

Mémoire consommée par Archiva

Mémoire consommée par Nexus

Les problèmes de snapshots non trouvés

Malheureusement à ce niveau là, le problème perdure. Mais le fait que le changement de serveur ne résolve pas le problème nous avons investigué un peu plus.
Nous avons découvert aujourd’hui deux causes plus précises du problème :

• La première est un bug Maven (MNG-4142) qui est un subtil problème à moitié chemin entre l’utilisation d’artifacts avec des classifiers et une corruption des metadonnées du repository local.
• La seconde cause est liée à des bugs NEXUS (NEXUS-1333, NEXUS-2036) qui font que le processus de correction des metadonnées les supprime dans un répertoire si il n’arrive pas à comprendre un POM. Cas qui semble arriver fréquemment en utilisant par exemple des propriétés maven “deprecated” comme ${parent.*} (à remplacer par ${project.parent.*}) ou ${pom.*} (à remplacer par ${project.*}).

A ces problèmes vient s’en greffer un nouveau spécifique à Nexus.

Les cookies rejetés

Un problème est apparu avec Nexus. Nous avons un soucis avec les règles de réécriture qui font que Maven se plaint lorsqu’il fait un déploiement que les cookies sont rejetés (NEXUS-1967). Ca n’est pas grave, mais cela crée du bruit dans les logs Maven ce qui ne facilite pas le diagnostic des erreurs.

Mais au final le jeu en valait bien la chandelle !!

La cerise sur le gâteau

Au final toutes les économies de ressources sur le serveur mais aussi la meilleure qualité de Nexus sur la rapidité de l’upload des artifacts (quelque soit leur taille) font que le serveur d’intégration continue est beaucoup plus stable et beaucoup plus régulier. Comme on peut le voir sur les quelques graphiques ci-dessous tirés de différents builds sur Bamboo il y a une nette fracture lors de la mise en production de Nexus. On note une régularité sans commune mesure sur les temps des builds et surtout une grande diminution de ceux-ci.

Conclusion

Avons-nous trouvé la silver bullet ? Bien sur que non. J’ai déjà listé quelques contraintes ou problèmes rencontrés et il y en a d’autres à découvrir. Tout produit est perfectible. Malgré cela comment dire autre chose que …. migrez !!! C’est malheureux pour moi de l’avouer en tant que membre de l’équipe Archiva mais je dois me ranger aux résultats. Ils sont édifiants. Nexus est un produit de qualité qui rend très bien le service qu’on lui demande. De plus, développé par des personnes à temps plein (merci Sonatype), il bénéficie d’un support réactif et facilement accessible (je vous conseille le channel #nexus sur irc.codehaus.org). Archiva, lui, régit par les lois de l’open-source, doit se contenter du maigre temps libre de ses committeurs ce qui ne suffit plus pour rester dans la compétition.
Alors, faites-vous plaisir et profitez d’un service à la hauteur de vos demandes, adoptez Nexus !

Avant de migrer …

Petit topo sur la solution existante. Avant la migration, notre environnement ressemble à peu de choses près à ceci :

L'environnement avant migration

Nous hébergeons nos référentiels internes dans ce que Archiva appelle des managed repositories. On en retrouve un pour les releases, un pour les snapshots et un dernier pour les librairies tierces (celles des éditeurs en général).
Pour gérer le cache des référentiels externes (déclarés en tant que “remote repositories”) nous utilisons deux autres référentiels internes ( releases et snapshots).

Archiva expose deux groupes : L’un pour accéder à toutes les releases, l’autre pour les snapshots. Nous n’avons jamais mis en place de groupe qui expose les deux types d’artifacts ensembles car Archiva a souvent eu des problèmes pour fusionner les descripteurs présents sur les référentiels (maven-metadata.xml).

Les groupes permettent de simplifier énormément la configuration de Maven en évitant de déclarer tous les référentiels. Encore plus important, les groupes optimisent grandement les performances de Maven car pour un artifact manquant celui-ci ne fait qu’une requête vers le groupe qui la distribue sur tous les référentiels qu’il masque. Interroger individuellement chaque référentiel est une perte de temps inexorable.

Les clients des référentiels (utilisateurs et intégration continue) y accèdent en configurant ainsi Maven :
[xml]

En redéfinissant l’adresse du serveur central (normalement situé ici : http://repo1.maven.org/maven2/) Maven recherche les artifacts de type release dans notre groupe dédié sur archiva. Cela nous donne alors accès autant aux releases internes qu’externes. De la même manière le référentiel additionnel snapshots nous permet d’obtenir les versions en cours de développement.

Les contraintes

La migration n’est pas aisée lorsque l’on a 200 développeurs qui utilisent le serveur au quotidien.

Premièrement, il faut s’assurer de stopper le gestionnaire d’artifacts un minimum de temps (ou alors venir le faire en dehors des heures de travail … gloups !!!). Arrêter l’intégration continue temporairement n’est pas un problème majeur. Par contre, demander aux équipes d’utiliser Maven en mode offline et de ne plus utiliser les référentiels est plus difficile. En général, Il ne faut pas longtemps avant qu’une personne ait besoin de télécharger une librairie ou qu’un projet doive faire une release.

Deuxièmement, il est impératif de garder la compatibilité avec les paramétrages Maven actuels. Compte tenu du nombre de projets et de développeurs il est impossible de reconfigurer tous les références aux référentiels dans le paramétrage Maven. Il faudrait impacter tous les projets pour modifier les urls d’upload (distributionManagement) et tous les développeurs pour les paramètres de téléchargement (repositories).

La démarche

Pour limiter les coûts nous avons décidé de ne pas faire tous nos tests sur un environnement de recette. Il aurait fallu dupliquer tout l’environnement d’intégration continue aujourd’hui en production afin d’avoir des résultats probants.
Une fois les quelques tests de base effectués sur l’outil, la véritable épreuve du feu se joue sur la volumétrie et la montée en charge du serveur.
Comme nous changeons de produit, nous pouvons facilement faire tourner les deux serveurs en parallèle (tant que les ressources système nous le permettent). Nous sommes donc partis sur la stratégie de faire un “parallel run” Archiva / Nexus pour ensuite basculer les services les uns après les autres (en gardant la possibilité de revenir en arrière au cas où).
Nous avons assez de place pour recréer les caches des référentiels externes (cela ne représente que quelques Go). Il n’y a que les référentiels internes que nous ne pouvons pas dupliquer (ils sont trop gros, et cela poserait un problème de cohérence). Nous ne voulons pas non plus partager ces référentiels internes entre les deux produits afin de ne pas risquer d’avoir des accès concurrents. Nous commencerons donc notre migration en laissant les repositories internes sur Archiva puis nous les migrerons à la dernière minute sur Nexus lors de la bascule finale.

Pour la compatibilité des urls nous allons utiliser des règles de réécritures (rewriting rules) sur le serveur Apache que nous avons en frontal. Il fera le passage entre les anciennes url et les nouvelles de manière transparente.

Installation de Nexus

Nous effectuons une installation classique de Nexus 1.3.2 en version opensource standalone en adaptant uniquement quelques paramètres comme le port HTTP, les chemins des répertoires des données et des logs pour se conformer à l’organisation de notre serveur. Tout cela se fait en très très peu de temps puisque contrairement à Archiva nous n’avons pas à créer de base de données. Notre serveur Nexus est rapidement en route et prêt à être configuré.

Configuration des groupes et référentiels externes

Nous commençons la configuration de Nexus par les référentiels externes (proxy repositories). Nous rajoutons aussi pour les besoins de la migration les caches vers nos référentiels internes toujours hébergés sur Archiva.

L’IHM est assez bien faite ce qui rend la saisie des 20 référentiels externes supportable. Merci à ExtJS !

Contrairement à Archiva qui propose de stocker les artifacts de plusieurs référentiels externes dans un même référentiel local, Nexus stocke le contenu de chacun dans un répertoire dédié.

Concernant le paramétrage des référentiels externes, il faut noter que l’on perd la possibilité offerte par Archiva de gérer des listes blanches ou noires des artifacts à récupérer sur les référentiels externes. C’est la notion de “routes” qui est utilisée dans Nexus pour faire ce type de filtrage. Malheureusement elle ne s’applique aujourd’hui qu’au niveau d’un groupe et non pas au niveau d’un référentiel.
Puisque les quelques listes que nous avons dans Archiva ne sont là que pour des questions de performance (ne pas interroger un référentiel dans lequel on sait qu’un artifact n’est pas), nous avons décidé de ne pas dupliquer cette configuration sur Nexus en attendant de voir si cela posait de réels problèmes.

Lors de notre paramétrage nous faisons face à une autre déconvenue. Comme nous devons faire proxy pour des référentiels hébergés en interne (pour le référentiel exposé par le serveur sonar et pour Archiva pendant la migration) nous avons été obligés de déclarer le proxy web de l’entreprise sur chaque référentiel externe. Il est impossible en définissant le proxy web dans la configuration globale de Nexus de la désactiver sur un référentiel donné.

Alors que notre configuration des référentiels externes était quasiment terminée, nous trébuchons sur un os de taille. Nous découvrons qu’il est impossible de faire proxy de référentiels qui sont au format maven 1 (chez atlassian et dev.java.net par exemple).
Pour y parvenir nous devons créer des référentiels virtuels (virtual repository) qui servent à Nexus pour convertir un référentiel d’un format vers un autre. Manque de chance deux bugs (NEXUS-1909, NEXUS-1910) nous empêchent de le faire.
Heureusement pour nous, l’équipe Nexus a su être très réactive et elle a pu incorporer les corrections à ces bugs dans la version 1.3.3 qu’elle publiait le lendemain de notre découverte. Sans cela il fallait bien avouer que l’on n’aurait probablement pas continué nos tests sur Nexus.
Nous avons donc mis à jour notre installation ce qui en passant nous a permis de voir que l’opération était très aisée puisque l’application, sa configuration et ses données sont très bien séparées.

Nous finalisons la configuration de Nexus par la création des groupes. Cette la même notion que celle d’Archiva (qui a d’ailleurs copié dessus).
La gestion d’un groupe est par contre assez mal faite en terme d’ergonomie. Il nous faut sélectionner les référentiels à rajouter au groupe puis l’ordonner dans une liste. L’ordre est très important car Nexus l’utilisera pour rechercher les artifacts. Il faut donc placer les référentiels avec des releases avant des snapshots et les référentiels locaux avant les référentiels externes. Le problème c’est que cette liste n’affiche que le nom de chaque référentiel (et encore ce nom est souvent tronqué faute de place). Vous avez donc intérêt à faire très attention au nommage des référentiels pour vous y retrouver lorsqu’il faut en classer plusieurs dizaines dans un groupe.

Nous suivons les recommandations de Nexus en créant un groupe unique qui expose toutes les releases et tous les snapshots. (Ce qui nous évitera en plus de nous battre deux fois avec l’écran de configuration d’un groupe).

A partir de ce moment là nous sommes censés être en mesure de récupérer tous les artifacts nécessaires à la construction de nos projets depuis Nexus.

Après quelques tests unitaires concluants nous validons l’ensemble avec notre serveur d’intégration continue.
Nous supprimons son référentiel local et mettons à jour sa configuration :
[xml]




nexus
*
http://serveur.entreprise.fr/nexus/content/groups/public/

A noter : Je ne suis pas du tout fan de l’utilisation du mirroir * qui oblige à mettre dans le même groupe les releases et les snapshots. C’est cependant la seule solution aujourd’hui puisqu’il n’y a pas la possibilité avec les miroirs de dire à Maven de rechercher les releases à un emplacement et les snapshots à un autre. Je trouve cette utilisation dangereuse car, par exemple, lorsque vous demandez un plugin sans définir sa version (un plugin en ligne de commande par exemple comme eclipse:eclipse ou archetype:generate) vous risquez de récupérer une version snapshot. Il faut donc prendre à la lettre la recommandation de Maven qui est de définir dans son POM (ou par héritage) toutes les versions des plugins que l’on utilise pour s’éviter des surprises (ce qui ne me gène pas dans notre contexte puisque la recommandation est suivie par tous les projets en utilisant un pom parent qui fait cette définition pour eux).

L’environnement Archiva et Nexus en parallèle est opérationnel.

Nexus / Archiva en parallèle

Rien ne changent pour les développeurs qui continuent d’utiliser Archiva. Le serveur d’intégration continue récupère par contre tous les artifacts nécessaires depuis Nexus.

Tuning

Au bout de quelques jours de tests on remarque que Nexus a parfois du mal à servir rapidement les artifacts. On s’intéresse donc aux paramétrages un peu plus avancés.

Les routes permettent lorsque l’on demande un artifact à un groupe de restreindre la liste des référentiels que Nexus doit consulter dans le groupe donné. Cela peut se faire via des autorisations ou des interdictions.

La route que nous créons en premier est celle qui concerne les artifacts de nos projets (.*/fr/monentreprise/.*) pour lesquels Nexus doit renvoyer automatiquement vers les proxy des référentiels gérés pour l’instant par Archiva. Une fois la mise en production finale effectuée, celui-ci pointe uniquement vers les référentiels locaux.

Nous ajoutons aussi des règles pour .*/org/apache/.* et .*/org/codehaus/.* qui sont massivement utilisées par Maven afin que les artifacts ne soient recherchés que sur le référentiel central et sur les référentiels des snapshots de chaque communauté.

Tout cela donne déjà un bon coup de boost à notre Nexus.
Après plusieurs jours d’utilisation pour les téléchargements de l’intégration continue, le serveur Nexus tourne parfaitement. Nous préparons donc la deuxième partie de la migration : La mise en place des référentiels internes sur Nexus.

Configuration des référentiels internes et de la sécurité

Pour reprendre les référentiels internes hébergés par Archiva sur Nexus il nous faut commencer par créer les référentiels internes (hosted repositories). Nous plaçons les répertoires de stockage des artifacts à un emplacement différent de celui d’Archiva pour ne pas laisser les deux produits accéder aux même données. Nous reprenons les identifiants de référentiels utilisés dans Archiva afin de pouvoir facilement créer des règles de réécriture sur notre frontal Apache.

Nous passons un peu de temps pour comprendre le mécanisme de sécurité de Nexus. Ce dernier est tellement fin que les paramétrages basiques sont vite compliqués.

Nous commençons par créer des privilèges sur les référentiels internes (lecture, écriture, mis à jour). Nous créons des rôles qui regroupent un certain nombre de privilèges sur certains référentiels. Dans notre cas un rôle pour déployer sur les référentiels des releases (pour les équipes projets) et un rôle pour déployer sur les référentiels de snapshots (pour l’intégration continue).
Nous terminons en créant les utilisateurs avec les rôles définis ci-dessus sans oublier le rôle pour lire sur tous les référentiels.

Les référentiels internes étant prêts il ne nous reste plus qu’à les basculer sur Nexus et éteindre Archiva.

La bascule finale

Pour conserver la compatibilité des urls entre Archiva et Nexus nous faisons deux choses.
Pour les accès en écriture sur les référentiels nous définissons une à une la règle qui transforme l’adresse d’Archiva vers Nexus.
Exemple de configuration Apache :
[text]
####
# Compatibilité ARCHIVA
####
RewriteRule ^/archiva/repository/internal-releases/(.*) http://localhost/nexus/content/repositories/internal-releases/$1 [P]
RewriteRule ^/archiva/repository/internal-snapshots/(.*) http://localhost/nexus/content/repositories/internal-snapshots/$1 [P]
RewriteRule ^/archiva/repository/third-parties/(.*) http://localhost/nexus/content/repositories/third-parties/$1 [P]
…
[/text]
Pour les accès en lecture qui se faisaient sur archiva avec des groupes nous transférons la demande vers le groupe unique que nous avons sur Nexus.
Exemple de configuration Apache :
[text]
####
# Accès aux groupes
####
RewriteRule ^/archiva/repository/[a-z\-]+/(.*) http://localhost/nexus/content/groups/public/$1 [P]
[/text]
La bascule est prête :

1. Arrêt de Nexus,
2. Arrêt d’Archiva,
3. Installation des règles de réécriture sur le frontal Apache,
4. Déplacement du contenu des référentiels internes depuis Archiva vers Nexus,
5. Redémarrage de Nexus.

Le jour J nous avons fait la bascule en moins de 10 minutes. Nexus a pris quelques heures à digérer nos centaines de Go de données mais sans pour autant que cela diminue énormément ses performances.

Environnement après migration

Malgré les quelques écueils rencontrés, la migration n’aura pas été d’une grande complexité technique. Elle s’est déroulée sur deux semaines et nous en a coûté moins de la moitié en temps consommé.

Nous étudions aujourd’hui comment régler les taches en arrière plan. Sonatype a fait un très gros effort sur la documentation du produit. Celle-ci permet de découvrir rapidement l’ensemble de ses fonctionnalités. Cependant on reste vite sur notre faim lorsque l’on veut dépasser le cadre du guide de référence. Il manque encore quelques bons conseils sur la mise en œuvre de l’outil dans un environnement d’entreprise :

• Quelles tâches planifiées faut-il utiliser ?
• Dans quels cas ?
• Quand ?
• Pourquoi réparer les metadonnées ?
• Pourquoi supprimer les caches ?
• Comment gère-t’on la poubelle ?

Je n’hésiterai pas à remonter ces manques à l’équipe Nexus pour qu’elle enrichisse la documentation ( C’est Tim qui va être content ).

Ainsi se termine ce retour d’expérience les mains dans le cambouis pour migrer d’Archiva vers Nexus. Sur le prochain et dernier article sur le sujet, à découvrir dès demain, vous verrez quel est notre bilan un peu plus de deux semaines après la migration.

Le contexte

Le contexte de la migration est le suivant : une grande entreprise, avec plusieurs dizaines de projets JEE de toutes tailles (de la petite souris au gros paquebot — NON ! je n’ai pas parlé du Titanic !! ), et au moins 200 développeurs actifs simultanément en pleine journée.

La majeure partie des projets utilise Maven. Pour aider les équipes des études à faire mieux et plus vite nous offrons toute une infrastructure dédiée à l’intégration continue. Un serveur du genre Mister Muscles (Bi-Xeon QuadCore avec 16Go RAM sous RedHat Enterprise Linux 5.1), héberge un serveur d’intégration continue Atlassian Bamboo avec à son bord (environ) : 110 builds d’intégration continue, 40 builds de sites maven (quotidien), 20 builds Sonar (quotidien). Il héberge aussi un gestionnaire de référentiels d’artifacts Maven (Archiva 1.1.1 avant la migration) qui abrite un peu moins d’une dizaine de référentiels locaux et qui fait proxy-cache d’une vingtaine de référentiels externes. Ces référentiels représentent tout de même 400Go de données. La majeure partie est utilisée par le référentiel des snapshots (200Go) et par le référentiel des releases (150Go). Pour comprendre ces tailles il faut savoir que certains projets produisent (pour de bonnes ou de mauvaises raisons) des EARs pouvant faire jusqu’à 100Mo. En rajoutant la taille des WARs et JARs qui composent ces EARs, un projet occupent rapidement beaucoup de place à chaque déploiement.

Pourquoi changer ?

Cela faisait plusieurs mois que la stabilité de notre environnement d’intégration ne nous satisfaisait pas. Nous avions des temps d’exécution très variables d’un build à un autre, et par intermittence nous avions des erreurs qui n’étaient pas liées aux projets mais à l’infrastructure mise en place :

• Erreurs 500 ou 502 sur des uploads sur Archiva sans raison apparente (j’ai cherché sans succès la cause),
• Plantage complet d’Archiva ou d’un autre soft après avoir dépassé le nombre maximum de descripteurs de fichiers ouverts pour l’utilisateur. Il faut concéder que ces outils manipulent beaucoup de fichiers (téléchargements, uploads, et autres manipulations sur un grand nombre d’artifacts). Archiva dépasse allègrement la limite par défaut des 1024 descripteurs ce qui nous avait forcé à l’augmenter. Mais même à 2048 il lui arrive encore occasionnellement de la dépasser.
• Récupération de snapshots impossible si le référentiel local utilisé par Bamboo avait été vidé juste avant. Cela entraînait régulièrement l’échec des builds de sites Maven ou Sonar.

A tout cela il faut rajouter le récent bug d’Archiva (MRM-1136) sur lequel j’ai passé plusieurs heures en diagnostic (problème sur la gestion des meta-données émises par Maven 2.1.0) et qui allait nous obliger à upgrader rapidement vers une version 1.1.4 ou 1.2.

Tous ces problèmes même s’ils n’étaient que ponctuels, dévalorisaient fortement l’intégration continue. Comment reprocher à un projet de ne plus en tenir compte si cette dernière vous envoie des faux négatifs ? Ils ont déjà bien assez de travail pour traiter les véritables erreurs. L’environnement d’intégration continue doit être aussi fiable qu’une horloge suisse.

Il était donc temps pour nous de réagir.

Soit nous mettions à jour Archiva, ce qui représentait un coût non négligeable en recette mais qui n’apporterait pas beaucoup d’améliorations. En dehors de l’incompatibilité avec Maven 2.1.0, rien ne nous laissait penser que les nouvelles versions corrigeraient certains autres de nos problèmes. Et du coté des évolutions, ces dernières se font rares sur Archiva en ce moment (faute de moyen).

Soit nous faisions le pari de prendre un autre outil avec le risque de rencontrer de nouveaux écueils.

Les retours de la communauté à propos de Nexus sont très encourageants. De plus, celui-ci en version pro ouvre de nouvelles possibilités à l’avenir avec ses fonctionnalités novatrices :

• Référentiels de recette (staging repository) pour mettre dans un sas les artifacts en cours de validation avant leur livraison,
• Possibilité de faire proxy pour les updates sites eclipse. Actuellement nous le faisons à la main cependant cela est coûteux, compliqué (je déteste P2), et inintéressant.

Puisque le jeu semblait en valoir la chandelle, nous avons décidé de tenter notre chance avec Nexus…