Installing Sonatype Nexus Repository Using the OpenShift Operator

Note

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

Prerequisites

To install Sonatype Nexus Repository using the OpenShift operator, you must meet the following prerequisites:

You must be running the OpenShift platform and have access to RedHat repositories
You must have OpenShift administrator privileges
You will need a separate OpenShift project for your Sonatype Nexus Repository deployment
You must have a PostgreSQL database set up and accessible to your OpenShift cluster
You must have a Base64-encoded Sonatype Nexus Repository license file; see the following example, which uses an example file named nx-license.lic
```
$ base64 nx-license.lic
cylwwtYx6Fjh7o4k34Ih3KM.....
```
If you plan to deploy Sonatype Nexus Repository in HA (active/active) mode, you must meet all System Requirements for High Availability Deployments.

Storage

The default configuration uses an emptyDir volume for storing Sonatype Nexus Repository logs. However, we strongly recommend that you configure dynamic provisioning of persistent storage based on your deployment environment as explained below.

Cloud Deployments (AWS, Azure)

Ensure the appropriate Container Storage Interface (CSI) driver(s) are installed for your chosen OpenShift cloud deployment (AWS, Azure).

Refer to OpenShift documentation for details on configuring CSI drivers.

Note

If you're using Red Hat OpenShift on AWS (ROSA), CSI drivers for dynamically provisioning EBS volumes are installed by default; you should see associated storage classes for them in your cluster web console similar to what's shown below:

On-Premises Deployments

Attach separate disks (i.e., separate from the root disk) to your worker nodes.
Follow the OpenShift local persistent storage documentation and Local Storage Operator documentation to install the Local Storage Operator.
Use the Local Storage Operator to automatically create persistent volumes for your chosen storage class name. See the OpenShift documentation for details.

Configuring the Operator for Dynamic Persistent Volume Provisioning

Set the nexusData.storageClass.name parameter to a storage class name. This could be one of the default storage classes automatically created in your OpenShift cluster (e.g., if you're using ROSA) or one that you would like the operator to create.
1. If you would like to create a dedicated storage class (i.e., you don't want to use the default), then in addition to specifying a value for nexusData.storageClass.name, you must also set nexusData.storageClass.enabled parameter to true.
2. Set the nexusData.volumeClaimTemplate.enabled parameter to true.

Migrating from the Old OrientDB Operator

Note

The old OrientDB operator, which will be sunset on December 15, 2023, is called "Nexus Repository Certified Operator" in the RedHat catalog. The new operator is called "Nexus Repository HA Certified Operator."

There is no direct migration path from the old operator to the new operator as the old one used the embedded OrientDB database while the new one requires that you migrate to PostgreSQL.

If you wish to use the new operator, you will need to uninstall the old operator, migrate to PostgreSQL (see Migrating to a New Database), obtain a Pro license, and install the new operator as outlined in the installation instructions below.

Installation Steps

Log into the OpenShift UI as an administrator.
Navigate to Operators → Operator Hub; locate and install (if not already installed) the Nexus Repository HA Operator in an existing or new project.
Note
Deploying the operator is not yet complete; you must complete the remaining steps for the operator to be fully operational.
After installing the operator, navigate to Operators → Installed Operators; select the Nexus Repository HA Operator in order to update the custom resource definitions.
Select the NexusRepo tab; then, select the Create NexusRepo button.
Provide a name for your custom resource definitions or keep the default and select Create.
The custom resource definition now appears in a table under the NexusRepo tab.
Select the custom resource definition that you just created.
Within the custom resource definition, navigate to the YAMLtab.
Update the following attributes in the YAML:
1. Set spec.ingress.defaultRule = true
2. If you will have more than one Docker repository, you will need to either use a reverse proxy or subdomain connector. We recommend choosing one of these methods.
  1. If you will use a reverse proxy, you do not need to change anything for spec.ingress.dockerSubdomain or spec.ingress.dockerIngress from their default values. Proceed to step 9d.
  2. If you will use a subdomain connector, set the following:
    spec.ingress.dockerSubdomain = true
3. If you will have only one Docker repository and plan to use port connectors, set the following attributes instead:
  1. spec.ingress.dockerIngress.enabled = true
  2. spec.ingress.dockerIngress.host = <desired hostname>
4. spec.ingress.enabled = true
5. spec.ingress.host = <prefix name>.<openshift cluster hostname>
  1. Use the hostname of your OpenShift cluster with appropriate prefix
6. If TLS is required, set the following attributes:
  1. spec.ingress.tls.enabled = true
  2. spec.ingress.tls.secretName = <tls secret name>
  3. Follow Kubernetes's documentation for creating a TLS secret and Ingress
7. If you have not already done so, convert your license file to Base64-encoded format using a command like the following:
```
$ base64 <license file.lic>
```
8. Add the result of the above command to spec.license.fileContentBase64
9. If you will be using High Availability (HA), set the following:
  1. spec.statefulset.env.clustered = true
10. spec.statefulset.env.jdbcUrl = <postgresql jdbc url>
11. spec.statefulset.env.password = <db password>
12. spec.statefulset.env.user = <db username>
13. spec.statefulset.env.nexusInitialPassword = <intial admin password>
14. spec.statefulset.env.replicaCount =<number of Nexus Repository instances desired>
Select Save.
Select Reload.
In the OpenShift UI, navigate to Workloads → StatefulSets.
Delete the StatefulSet that is similar to "nxrm-ha-59-0-0-nexus repo-statefulset" (as shown in the example below) in order to apply the updated configuration.
Note
After the StatefulSet starts again, it will take few minutes for the pods to be active and running. Proceed to step 15 only after the pods are running.
In the OpenShift UI, navigate to Networking → Routes; the URL for accessing your Sonatype Nexus Repository instance appears in the Locationcolumn.