Kate Ebneter is a Build Engineer at Ning, Inc. an online platform running the largest number of social networks on the internet. Ebneter is responsible for maintaining mission-critical development infrastructure serving more than 60 developers distributed over seven locations. In this guest post, Kate shares her experience migrating from Artifactory to Nexus Professional. She details the problems Ning encountered with Artifactory, how Ning selected a new repository manager, and what steps they took to migrate from Artifactory to Nexus Professional.
Selecting Nexus Professional
A few years ago, we started out using Artifactory because it was readily available, free, and it supported most of what we needed from a Maven repository in terms of security and permissions for developers. It served its purpose for a while, but soon we reached a point where Artifactory was no longer enough. Our biggest concern was that Artifactory didn’t permit developers to deploy artifacts they needed during their work while still protecting our official builds by restricting the artifacts our builds could reference. We needed more fine grained security controls and we needed the ability to procure artifacts from a remote repository like Central.
In search of a better solution, we started by looking at the open source version of Nexus, but it didn’t have this capability as well. After examining Nexus Professional, it became clear to us that it was definitely the way to go. In addition to Nexus Professional’s procurement capabilities, we especially liked that the artifact “database” was just a straightforward file system. This makes backing up a repository very easy. It also makes it much easier to recover from various problems that might occur, and storing the repository in a file system makes it much easier to troubleshoot and see what is being stored in the repository without having to access it via the web front-end.
The Migration: From Artifactory to Nexus
Well in advance of the migration, we configured our systems to use the names <repo>/artifactory and <repo>/nexus to facilitate the changeover. We had originally intended to use an httpd front-end to the server to make the old Artifactory URLs point to the appropriate new URLs. Ultimately, we didn't need to resort to any URL rewriting during the migration, but the final system is proxied through an httpd server to simplify URLs.
At the time of the migration, we had approximately 133GB of artifacts in our local, hosted repository. This did not include any cached, proxied artifacts from Maven Central or other remote repositories. Once we started to migrate the repository from our existing Artifactory server to the new Nexus Professional repository, we used the Nexus migration plugin which greatly simplified the process of moving our repositories from Artifactory to the new Nexus Professional instance. Of course, we wanted to have the Artifactory repository available as much as possible while we were importing into Nexus Professional, to ensure that our developers could continue to work uninterrupted. The process we worked out to ensure a fail-safe transition looked like this:
- Shut down Artifactory.
- Create a complete copy of our Artifactory instance on another server.
- Restart Artifactory with all deployments disabled (to prevent adding any more artifacts!)
- Using Artifactory’s artadmin tool, export the contents of the Artifactory database, creating a dumpExport directory with the full contents of the export.
- In parallel with steps 1-4, install Nexus Professional and the Artifactory import plugin on the Nexus server machine.
- Fire up Nexus Professional.
- Copy the exported artifacts from the export server to the Nexus server and import them into Nexus Professional.
- Configure Nexus Professional proxy repositories (about a dozen, in our case, and very easily done).
- Shut down Artifactory. (For good!)
Post-migration Summary
At Ning, our top-level, base POM contains URLs that define the location of the repository for purposes of deployment. The original plan was to use Apache httpd to automatically rewrite these URLs, but we encountered some difficulties configuring the rewrite rules. In the end, we decided to simply update our base POM to change the URL to point to the new Nexus Professional instance. This did require everyone using a project that referenced this base POM to upgrade to a newer version of the base POM with updated URLs. In fact, this migration is still ongoing as less-frequently released projects encounter the need to deploy artifacts to the new Nexus Professional instance.
All of our developers had to change their settings.xml files to point to the new Repository Group, and this process went smoothly. We haven’t set up the procurement repository yet, but are planning to do so some time in the future. At this time, we’re very happy with the performance of Nexus Professional and haven’t had any issues with it so far. As the administrator, I really appreciate the simplicity of the user interface for uploading new artifacts that don’t reside in the any of the central Maven repositories, and the flexibility of the permissions is impressive.
Overall, my only regret about the migration is that we didn’t switch to Nexus sooner!
