Single-Node Cloud Resilient Deployment Example Using Azure

Only available in Nexus Repository Pro. Interested in a free trial? Start here.

Already have a Nexus Repository instance and want to migrate to a resilient architecture? See our migration documentation.

You never know when disaster may strike. With a resilient deployment on Azure like the one outlined below, you can ensure that you still have access to Nexus Repository in the event of service or data center outage.

Similar architecture could be used for other cloud or on-premise deployments with Kubernetes and file-based or other supported blob storage. If you would like to manage your own deployment, see Single Data Center On-Premises Deployment Example Using Kubernetes. If you prefer to use AWS, see Single-Node Cloud Resilient Deployment Using AWS.

Nexus Repository Resiliency Azure Reference Architecture. One active Nexus Repository instance with one failover instance in different availability zones all within one Azure region.

Use Cases

This reference architecture is designed to protect against the following scenarios:

An Azure Availability Zone (AZ) outage within a single region
A node/server failure
A Nexus Repository service failure

You would use this architecture if you fit the following profiles:

You are a Nexus Repository Pro user looking for a resilient Nexus Repository deployment option in Azure in order to reduce downtime
You would like to achieve automatic failover and fault tolerance as part of your deployment goals
You already have an Azure Kubernetes Service (AKS) cluster set up as part of your deployment pipeline for your other in-house applications and would like to leverage the same for your Nexus Repository deployment
You have migrated or set up Nexus Repository with an external PostgreSQL database and want to fully reap the benefits of an externalized database setup
You do not need High Availability (HA) active-active mode

Requirements

A Nexus Repository Pro license
Nexus Repository 3.33.0 or later
kubectl command-line tool
An Azure account with permissions for accessing the following Azure services:
- Azure Kubernetes Service (AKS)
- Azure database for PostgreSQL
- Azure Monitor
- Azure KeyVault
- Azure Command-Line Interface
Kustomize

If you require your clients to access more than one Docker Repository, you must use an external load balancer (e.g., NGINX) as a reverse proxy instead of the provided ingress for Docker YAML.

Limitations

In this reference architecture, a maximum of one Nexus Repository instance is running at a time. Having more than one Nexus Repository failover instance will not work.

Setting Up the Architecture

Step 1 - Azure AKS Cluster

The first thing you must do is create a resource group. A resource group is a container that holds related resources for an Azure solution. In this case, everything we are about to set up will be contained within this new resource group that you create. Follow Microsoft's documentation to create a resource group from the Azure portal. Ensure you put the resource group in the same region you intend to setup your all your resources.

Then, you can follow Microsoft's documentation for creating an AKS cluster.

Ensure you enable Azure Monitor when creating your AKS cluster.

Step 2 - Azure PostgreSQL

We recommend Azure's Flexible Server option for storing Nexus Repository configurations and component metadata.

Follow Microsoft's documentation for creating an Azure database for PostgreSQL server.

When setting up the database, be sure to select the resource group you created when setting up your AKS cluster.
Be sure to select the same region as the resource group you created.

Use the Azure CLI to create the nexus database using Microsoft's documentation as a reference. (See Microsoft's documentation for installing the Azure CLI.)

Step 3 - Ingress Controller

An ingress controller provides reverse proxy, configurable traffic routing, and TLS termination for Kubernetes services. You can configure the ingress controller to associate a static IP address with the Nexus Repository pod. This way, if the Nexus Repository pod restarts, it can still be accessed through the same IP address.

Follow Microsoft's documentation for setting up an ingress controller in AKS.

Step 4 - Create Kubernetes Namespace

Follow the Kubernetes documentation for creating a Kubernetes namespace with the kubectl command-line tool. You will use the following command to create the namespace:

kubectl create namespace <namespace>

Step 5 - Licensing

Azure Key Vault

Azure Key Vault provides secrets, key, and certificate management. In the event of a failover, Key Vault can retrieve the license when the new Nexus Repository container starts. This way, your Nexus Repository always starts in Pro mode.

Follow Microsoft's documentation for creating a key vault.

Be sure to select the resource group you created when setting up your AKS cluster.
Be sure to select the same region as the resource group you created.
Restrict it to your virtual network.

You will then need to add your license file to the key vault using the Azure CLI. The command to add your license will look similar to the following:

az keyvault secret set --name <name_for_secret> --vault-name <name_of_keyvault> --file <path_of_license_file.lic> --encoding base64

You will also need to add the secrets for your username and password for your database; you can do this manually in the key vault you created via the portal. Follow Microsoft's documentation for adding secrets via the portal.

The Kubernetes node on which Nexus Repository will run requires the CSI Secrets Store driver to be able to retrieve the license and database user/password information from the key vault. This is a Kubernetes-specific plugin; directions for obtaining and installing this driver are available in Microsoft's documentation.

Note that the CSI Secrets Store Driver for AKS is still in preview. This is why we suggest using Kustomize to import the license as a ConfigMap that is mounted as a volume into the Nexus Repository pod to make the license available to Nexus Repository.

Kustomize

Your Nexus Repository license is passed into the Nexus Repository container by using Kustomize to create a configuration map that is mounted as a volume of the pod running Nexus Repository. See Kubernetes documentation for using Kustomize for more information.

Step 6 - Azure Monitor

You should enable Azure Monitor when creating your AKS cluster.

When running Nexus Repository on Kubernetes, it is possible for it to run on different nodes in different AZs over the course of the same day. In order to be able to access Nexus Repository's logs from nodes in all AZs, we recommend that you externalize your logs to Azure Monitor.

When first installed, Nexus Repository sends task logs to separate files. Those files do not exist at startup and only exist as the tasks are being run. In order to facilitate sending logs to Azure Monitor, you need the log file to exist when Nexus Repository starts up. This can be accomplished using the YAML to configure logback shown in the example YAML files.

Apply the YAML to configure logback to the AKS cluster before applying the deployment YAML.

Enabling Azure Monitor when creating the AKS cluster automatically pushes logs to stdout from all containers in the Nexus Repository pod to Azure Monitor.

Therefore, in addition to the main log file (i.e., nexus.log), Nexus Repository uses side car containers to log the contents of the other log files (request, audit, and task logs) to stdout so that they can be automatically pushed to Azure Monitor.

Example of Obtaining Log Messages

Below is an example of using a query to find out container IDs and use them to view log messages.

Open the Azure portal and navigate to the Log Analytics workspace that you specified for Azure Monitor during AKS cluster creation. Select the Logs tab and open a query editor.

Run the following query for each of the containers in the Nexus Repository pod:

ContainerInventory
| where Name contains "<container_name>" and ContainerState == "Running"
| order by TimeGenerated desc

container_name could be one of the following:

nxrm-app_nxrm-deployment-nexus
tasks-log_nxrm-deployment-nexus
request-log_nxrm-deployment-nexus
audit-log_nxrm-deployment-nexus

This will return a result such as the following:

You can then copy the ContainerID from this result and use it to access the logs in another query such as the following:

ContainerLog
| where TimeGenerated > ago (1h)
| where ContainerID in ('4f5165265cd79f4876b308fa95b89a0de08b93cf6abbdb47a9a2c25f7ef3736d')
| order by LogEntry desc

This would return a result such as the following with log messages shown in the LogEntry column:

Step 7 - Nexus Work Directory YAMLs

Use the Create Nexus Work Directory Config YAML and Create Nexus Work Directory YAML to create a directory to which the nexus-data volume will be mapped on the node/VM. Nexus Repository will store state information such as logs, elasticsearch indexes, and configuration data in that directory so that such information is persistent across Nexus Repository pod restarts.

Step 8 - Local Persistent Volume and Local Persistent Volume Claim

Using a local persistent volume allows Elasticsearch indexes to survive pod restarts on a particular node. When used in conjunction with the NEXUS_SEARCH_INDEX_REBUILD_ON_STARTUP flag, this ensures that the Elasticsearch index is only rebuilt if it is empty when the Nexus Repository pod starts. This means that the only time the Elasticsearch index is rebuilt is the first time that a Nexus Repository pod starts on a node.

Storage space will be allocated to a local persistent volume from your root volume (i.e., the volume attached to the provisioned node). Therefore, you must ensure that the size you specify for your node's root volume is sufficient for your usage. Ensure that the size of the root volume is bigger than that specified in the local persistent volume claim so that there's some spare storage capacity on the node. For example, for a local persistent volume claim size of 100 Gigabytes, you could make the actual size of the root volume 120 Gigabytes.

See the sample storage class YAML, local persistent volume YAML, and local persistent volume claim YAML in our example YAML files.

Step 9 - Azure Blob

Azure Blob Storage provides your object (blob) storage.

Use Microsoft's documentation to first set up a storage account and then begin working with blobs.

When setting up your storage account, be sure to select the resource group you created when setting up your AKS cluster.
Select the same region as the resource group you created.
If available in your region, use the premium performance option. Otherwise, use the standard option.
- If using the premium performance option, select the block blobs premium account type.
Select the zone-redundant storage option.
Restrict it to your virtual network.

Upgrading Nexus Repository when Deployed in Kubernetes

To upgrade Nexus Repository deployed in Kubernetes, you must complete the following steps:

Update the deployment YAML (as shown in example YAML files) to the Nexus Repository Docker image version to which you want to upgrade.
Apply the updated deployment YAML to your cluster.

Sample Kubernetes YAML Files

The YAML files linked in this section are just examples and cannot be used as-is. You must fill them out with the appropriate information for your deployment to be able to use them.

You can use the sample Azure resiliency YAML files from our sample files GitHub repository to help set up the YAMLs you will need for a resilient deployment. Ensure you have filled out the YAML files with appropriate information for your deployment.

Before running the YAML files in this section, you must first create a namespace. To create a namespace, use a command like the one below with the kubectl command-line tool:

kubectl create namespace <namespace>

Then, you must run your YAML files in the order below:

The resources created by these YAMLs are not in the default namespace.