Nexus Repository 3 High Availability (HA) and Resiliency Helm Chart and Sample YAML Repository
This repository contains resources for those deploying Sonatype Nexus Repository in an HA or resilient environment. Please refer to the documentation provided by your Customer Success Engineer for instructions on how to use these files. Also see our resiliency and HA help documentation.
Have an idea for an improvement? Pro customers can submit ideas through Sonatype's Ideas portal.
NOTE: Sonatype does not support or plan to support using a Helm chart for deployments using embedded databases, which includes all OSS deployments. Using Kubernetes to manage an application with an embedded database is a leading cause of corruption, outages, and data loss.
HA Prerequisites and System Requirements
Along with the HA-specific requirements listed below and further detailed in our HA system requirements help documentation, each instance must also meet our normal Nexus Repository system requirements.
HA requires the following:
- A Nexus Repository 3 Pro license
- An external PostgreSQL database using Postgres 13 or later; size your database appropriately based on your request traffic and desired number of nodes
- At least 2 Nexus Repository instances
- All Nexus Repository instances must be using the same Nexus Repository 3 Pro version, and it must be version 3.45.1 or later
- All Nexus Repository instances must have identical configuration in their $data-dir/etc/nexus.properties files
- A load balancer (e.g., HAProxy, NGINX, Apache HTTP, or AWS ELB)
- A blob store location for storing components that can be commonly accessed by all active nodes
- Connectivity between Nexus Repository, the database, and blob store
- All architecture must be in one region (if deploying to cloud) or data center (if deploying on-premises)
- A disk accessible to all active nodes for storing Nexus Repository logs and configuration settings used for generating the support zip
If the Nexus Repository deployment will contain more than one Docker repository, you must use one of the following:
- An external load balancer (e.g., NGINX) as a reverse proxy instead of the provided ingress for Docker YAML
- A Docker Subdomain Connector with external DNS to route traffic to each Docker subdomain