Deployment Pattern Library
Deployment Pattern Library
Nexus Repository is mission-critical infrastructure with the need to balance the availability of the service with the cost of the hardware required to operate. Many Nexus Repository users have deployment teams across the globe, making effective and efficient distribution essential. In evaluating industry struggles and our customers' needs, we've identified three primary concerns that can be addressed with appropriate deployment patterns: resiliency, scalability, and distribution.
Ensure Resiliency
Resiliency refers to the ability to recover from disruptions to critical processes and supporting technology systems. Regardless of your distribution and scalability needs, you must have some level of resiliency for a successful deployment.
Resiliency starts with backup and restore procedures. Use this pattern for every Nexus Repository instance that is a system of record in your deployment.
See the Resiliency documentation for a comprehensive list of failure scenarios and recommendations.
Establish Scalability Needs
Enterprise deployments experience large spikes in requests or require scalability to handle intense workloads. Scalability refers to a deployment's ability to adjust to these flexible, changing demands. These are some ways Nexus Repository can be scaled.
Adding capacity in terms of compute, memory, and faster storage.
- Separating distinct workloads such as development, distribution, or ecosystems.
- Distributing requests across an HA cluster or independent servers proxying from a central source.
Define Distribution Requirements
A solid Nexus Repository deployment requires establishing both your current and future distribution needs. You can define these by answering a few important questions:
How many Nexus Repository systems of record do you plan to have?
You'll need to decide how many authoritative vs. transient instances you need; this helps determine a base deployment pattern from which to design your full deployment.
A star pattern is a centralized administration with transient servers as local proxies.
A federated deployment will involve distinct regional hubs sharing replicated content.
How much traffic does each system of record need to handle?
When there are very high read traffic on a single system of record consider distributing this traffic to more transient proxy nodes to insolate your development environments.
Do you need on-demand artifact sharing or proactive artifact availability?
Bi-directional proxying allows users to pull artifacts on demand from a distant repository via a proxy repository
Content replication proactively pulls content from a central host repository so content is quickly available on the remote server.
Deployment Patterns
The patterns in this library represent proven ways of deploying Nexus Repository; you likely need to combine multiple patterns to meet your needs.
Resilient/Scalable Patterns
You can combine the patterns in this section with any distribution patterns to add scalability and/or resiliency to your deployment.
| Pattern | Needs Addressed | Description |
|---|---|---|
| Backup/Same-Site Restore | Resiliency: Data | Backup/Same-site restore is an essential foundational pattern that involves backing up your Nexus Repository system of record so that you can restore from a point in time if necessary. Use this pattern to protect against data corruption. |
| Disaster Recovery Site | Resiliency: Data and Region | Adding a disaster recovery (DR) site involves having a cold standby available so that you can spin up a Nexus Repository instance and switch to this site in the event of failure at your primary Nexus Repository system of record. PostgreSQL Recommended |
| On-Prem Active/Passive Resiliency | Resiliency: Node | Our resiliency patterns make recovery less manual by using an automatic recovery mechanism (e.g., Kubernetes) to accomplish automatic failover if a system of record goes down. PostgreSQL Required |
| Cloud Active/Passive Resiliency | Resiliency: Node and Availability Zone | Our resiliency patterns make recovery less manual by using an automatic recovery mechanism (e.g., Kubernetes) to accomplish automatic failover if a system of record goes down. The cloud version of our resiliency pattern also protects against availability zone (AZ) outages. PostgreSQL Required |
| On-Prem Active/Active High Availability | Resiliency Scalability |
Advanced high availability (HA) deployment options use multiple active Nexus Repository instances to maximize uptime and minimize data loss in the event of node failure. PostgreSQL Required |
| Cloud Active/Active High Availability | Resiliency Scalability |
Advanced HA deployment options use multiple active Nexus Repository instances to maximize uptime and minimize data loss in the event of node failure. PostgreSQL Required |
Base Distribution Patterns
| Pattern | Needs Addressed | Description |
|---|---|---|
| Star Pattern (aka hub-and-spoke pattern) | Distribution: Single system of record | The star pattern is a base pattern that uses the scaling with proxies pattern to add more transient satellites to a single system of record. |
| Federated Repositories | Distribution: Multiple systems of record | Federated repositories involve multiple systems of record that also use the bi-directional proxy pattern and/or content replication pattern to distribute artifacts between them. |
Extensions to Base Distribution Patterns
| Extension Pattern | Builds Off Of | Needs Addressed | Description |
|---|---|---|---|
| Scaling with Proxies | Star Pattern | Scalability | Scaling with proxy nodes allows you to take read load off of a primary Nexus Repository system of record (node) by using proxy nodes with a load balancer to split read traffic. |
| Bi-Directional Proxying | Federated Repositories | On-Demand Distribution | Bi-directional proxying provides on-demand distribution by having writes published to a hosted repository in a given region. Then, when a team in another region needs those components, they request them via a proxy repository in their region. The proxy then pulls those requested components from the hosted repository in the first region. |
| Content Replication Pattern | Federated Repositories | Proactive Distribution | Content Replication allows teams to publish artifacts to a hosted repository in a Nexus Repository system of record. Then, a proxy repository in another Nexus Repository instance pre-emptively fetches these artifacts via HTTP to provide faster artifact availability across distributed teams. PostgreSQL Required |
Example Combination Patterns
The examples below combine some of the patterns described above to meet multiple needs.
| Combination Pattern | Needs Addressed | Description |
|---|---|---|
| Combination Active/Active High Availability + Disaster Recovery Site | Resiliency Scalability |
This pattern provides two layers of resiliency. It uses active/active HA to protect against node or AZ outages and a DR site to protect against a regional outage. PostgreSQL Required |
| Combination Active/Active High Availability + Disaster Recovery Site + Federated Repositories | Resiliency Scalability Distribution |
This pattern is the same as the Active/Active HA + DR Site combo described above but adds a layer of redundancy by using federated repositories to distribute artifacts between two regions. PostgreSQL Required |