With the Nexus Professional 2.0 release, we’ve added a more intelligent approach to proxying repositories called Smart Proxy. When you configure a Smart Proxy you are establishing a relationship between two instances of Nexus.
To illustrate this feature, consider how a proxy repository works in Nexus 1.x: A traditional proxy repository has a very one-sided relationship with a remote repository. If a new artifact is published or modified on the remote repository, a traditional proxy has no way of knowing about changes unless it polls the remote repository. When you configure a proxy repository as a Smart Proxy in Nexus Professional 2.0 it can subscribe to change events published by a remote repository.
This post introduces Smart Proxy with an example of two, geographically distributed teams each maintaining a master instance which needs to proxy the other team’s instance. Once you understand this basic mechanism of behind Nexus Professional’s new Availability Architecture you’ll be able to plan and implement more complex deployments such as:
- Configuring several Nexus instances as smart proxies for a single master instance and then adding a load balancer to implement a redundant, highly-available cluster of Nexus servers.
- Maintaining a central instance of Nexus with hosted repositories for Snapshots and Releases, mirroring this central instance to distributed development teams with Smart Proxy repositories ensuring that every team has the latest artifacts.
Supporting Distributed Collaboration
To illustrate how Smart Proxy works, suppose you have two Nexus instances: one in New York and one in Paris. Each instance supports an active group of developers. Both instances mirror Central and a handful of other remote repositories, and each instance maintains hosted release and snapshot repositories.
While both teams are collaborating with one another every day, let’s also assume that New York is working on a separate subsystem from the team in Paris. The New York team is building a web-based interface to a banking system that depends on some back-end functionality implemented by the team in Paris. The New York team is an internal “client” for the Paris team consuming libraries that facilitate access to a backend accounting systems. Both groups push release and snapshot artifacts to their own Nexus installations, and the New York team depends on snapshot artifacts from Paris.
This challenge is a common one. How do you support distributed development teams and share release and snapshot artifacts between these instances in a way that guarantees each instance has the most up to date snapshots and releases?
Establishing Relationships between Nexus Instances.
If the team in New York is depending on snapshots from Paris and vice versa, each Nexus instance has to proxy the other’s hosted repositories. This is where Smart Proxy comes to the rescue.
Traditionally, in Nexus 1 proxy repositories had to be configured to frequently poll the source repository for any changes. Caching timeouts for snapshot repositories in particular had to be set so low that there was little benefit to maintaining a local proxy cache of a remote snapshot repository. This was inefficient, it caused performance issues, and there was always a chance that the proxying side could be serving stale snapshots.
In Nexus 2.0, instead of frequent polling, these proxy repositories subscribe to change events from the source repository. One side registers interest in a collection of events published by the other side. In effect, your remote repository is now able to “push” change events to a proxying client.
Immediate Notification of Repository Changes
The New York team’s proxy repositories are guaranteed to be up to date because the New york instance of Nexus is notified of changes immediately. When the French team pushes a new release or a new snapshot to Nexus, their instance notifies the other instance of a change event.
If an artifact has been deployed, deleted, or changed, the source repository notifies the proxy. If both teams proxy each other’s hosted repositories and configure Smart Proxy subscriptions, then both teams are assured that Nexus will never serve stale content.
This simple mechanism makes it possible to build complex distributed networks of Nexus instances relying on this publish/subscribe approach.
To learn more about Nexus Professional 2.0, go to http://sonatype.com/nexus.
Written by Tim OBrien
Tim is a Software Architect with experience in all aspects of software development from project inception to developing scaleable production architectures for large-scale systems during critical, high-risk events such as Black Friday. He has helped many organizations ranging from small startups to Fortune 100 companies take a more strategic approach to adopting and evaluating technology and managing the risks associated with change.
Explore All Posts by Tim OBrien