Real World Project: A Migration Roadmap from Artifactory to Nexus

Author, Mike Filosa

Author, Mike Filosa

As part of our ongoing investigation into how people are using Nexus, I have created a brief overview for a migration path from Artifactory to Nexus. This is a real world project, documenting our work with an enterprise level financial services client.

I’ll lay out the current situation with the original repository setup and security configuration, and then show you a roadmap of how the migration took place.

Current Situation

  • Current repository manager: Artifactory
  • Number of remote proxy repositories: 32
  • Number of local hosted repositories: 8
  • Current storage: Approximately 1.2TB

Current Security Configuration:

  • Anonymous read only access is granted to the repository
  • A small number of local user accounts have been created for deployments to the repository
  • Deployments happen from the CI environment only

 

Migration Plan

Summary

To start, configure a Nexus Professional instance to proxy the Artifactory local hosted and public repositories directly within Nexus. Over time, the artifacts will be pulled from the Artifactory instance and the appropriate public proxy repositories. During this time, perform validation of the Nexus configuration. Once validated and artifacts have been migrated, disconnect and shut down your Artifactory instance. At this time, any artifacts that remain within Artifactory can be exported and copied into the appropriate location within Nexus or archived.

 

Details

  • Remote Proxies: Create proxy repositories within Nexus and proxy the 32 remote repositories directly. Nexus will pull artifacts from the remote repository as they are requested via builds.Please Note: This may have impact on the speed of builds that are first run against Nexus.  Nexus will need to fetch any artifacts until it has cached them locally.
  • Local Snapshot Repositories and Release Repositories: A set of two repositories should be created in Nexus for each of the 8 local repositories.
    • (1) A temporary proxy repository which proxies the current Artifactory instance’s local repository. This repository at some point will be disconnected from Artifactory once the configuration is validated and Nexus has been populated.
    • (2) A hosted repository for deploying new artifacts to Nexus. Any builds deploying should be changed to deploy to the URL of these new hosted repositories. Once ready, the Artifactory hosted repositories should be placed in read-only mode.
  • Group Repositories: Any group repositories (Artifactory calls these Virtual Repositories) currently in use with Artifactory should be recreated in Nexus and contain the appropriate proxy and hosted repositories to mirror your current configuration within Artifactory.
  • User Access: Nexus supports the currently used anonymous access granted to the Artifactory repositories through its default configuration.
  • For each of the small number of user accounts that are deploying to Nexus, create local user accounts within Nexus and grant the “Nexus Deployment Role” to the appropriate hosted repositories.
  • Crowd or LDAP integration may be an option for controlling access to various features of the Nexus UI.  Further details regarding this configuration may be seen here.

 

Other Concerns

  • Running Nexus on Multiple Ports:  Having Nexus listen on multiple ports may be required. This can be configured by adding an additional connector within Jetty (Web Server) configuration.Please Note: It’s important to NOT check “force base url” in administration/server. Prior to enabling this configuration, please open a ticket with support@sonatype.com to help track this request.
  • Planning for expansion and increased usage: As load increases, additional installations of Nexus will help distribute the load. Additionally, enabling Smart Proxy may be beneficial.  In anticipation, we recommend creating separate DNS entries by creating one URL for read access to Nexus and a separate DNS entry for writing artifacts to Nexus. These can route to the same instance initially. Should you later decide to stand up a separate instance, these URLs will have already been communicated to your development teams.
  • Scheduled tasks: This KB article discusses the different scheduled tasks.

 

The following two tabs change content below.

Mike Filosa

A top performing Technical Sales Director with a unique background of 15 years of software development/architecture experience with a variety of programming languages and SDLC supporting technologies. I have successfully sold and deployed software with many of the largest organizations in the country including Banks, Insurance companies, high-tech as well as startups. Success with Pre-Sales / Post-Sales / Application Development and Product Owner roles.

Latest posts by Mike Filosa (see all)

Authors

Related posts

One Comment;

  1. Mykel Alvis said:

    We did something similar to this within the last year.

    Were I to do this again, I would make an entirely separate blobstore ONLY for the repository that we used to proxy Artifactory. Since it is nearly impossible to directly rebuild all those tags (they have different endpoints for their distribution URLs), that copy of the original Artifactory proxy is extremely important.
    Unfortunately, we put that proxy repo in among all our other proxy repos. It’s not a simple thing to extricate it now without repeating this process using a new Nexus instance, so that entire proxied (and growing) blobstore has to be kept around and managed long-term.

    Had we just proxied the Artifactory-hosted objects (not the Artifactory-PROXIED objects, which is what we did), this would be a much simpler issue to deal with.

    YMMV, of course.

*

Top