Skip to main content

Installing Sonatype Nexus Repository Using the OpenShift Operator

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

Prerequisites

You must meet the following prerequisites to install Sonatype Nexus Repository using the OpenShift operator:

  • Running the OpenShift platform with access to RedHat repositories and Administrator privileges

  • A separate OpenShift project for Sonatype Nexus Repository

  • A PostgreSQL database accessible to the OpenShift cluster

  • 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.....
  • Meet the System Requirements for High Availability Deployments.

Storage

The default configuration uses an emptyDir volume for storing Sonatype Nexus Repository logs. However, we recommend configuring dynamic provisioning of persistent storage based on your deployment environment.

Cloud Deployments (AWS, Azure)

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

For Red Hat OpenShift on AWS (ROSA), CSI drivers for dynamically provisioning EBS volumes are installed by default; view the storage classes in your cluster web console.

OpenShift Service on AWS storage class

Refer to OpenShift documentation for details on configuring CSI drivers.

On-Premises Deployments

  1. Attach separate disks (i.e., separate from the root disk) to your worker nodes.

  2. Follow the OpenShift local persistent storage documentation and Local Storage Operator documentation to install the Local Storage Operator.

  3. 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

  1. 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 was sunsetted on December 15, 2023. 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

  1. Log into the OpenShift UI as an administrator.

  2. Navigate to Operators → Operator Hub; locate and install (if not already installed) the Nexus Repository HA Operator in an existing or new project.

    OperatorHub screen shot

    Complete the remaining steps for the operator to be fully operational.

  3. After installing the operator, navigate to Operators → Installed Operators; select the Nexus Repository HA Operator to update the custom resource definitions.

    Installed Operators screen
  4. Select the NexusRepo tab; then, select the Create NexusRepo button.

    Installed Operators NexusRepos tab
  5. Provide a name for your custom resource definitions or keep the default and select Create.

    Create NexusRepo form
  6. The custom resource definition now appears in a table under the NexusRepo tab.

    NexusRepo tab in OpenShift UI
  7. Select the custom resource definition that you just created.

  8. Within the custom resource definition, navigate to the YAMLtab.

    YAML tab within operator
  9. Update the following attributes in the YAML:

    1. Set the following property.

      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 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:

      spec.ingress.dockerIngress.enabled = true
      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 the appropriate prefix

    6. If TLS is required, set the following attributes:

      spec.ingress.tls.enabled = true
      spec.ingress.tls.secretName = <tls secret name>

      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>

      Add the result of the above command to spec.license.fileContentBase64

    8. If you will be using High Availability (HA), set the following:

      spec.statefulset.env.clustered = true
    9. spec.statefulset.env.jdbcUrl = <postgresql-jdbc-url>
      spec.statefulset.env.password = <db-password>
      spec.statefulset.env.user = <db-username>
      spec.statefulset.env.nexusInitialPassword = <intial-admin-password>
      spec.statefulset.env.replicaCount =<number-of-instances>
  10. Select Save.

  11. Select Reload.

  12. In the OpenShift UI, navigate to Workloads → StatefulSets.

  13. Delete the StatefulSet that is similar to "nxrm-ha-59-0-0-nexus repo-statefulset" (as shown in the example below) to apply the updated configuration.

    Note

    After the StatefulSet starts again, it will take a few minutes for the pods to be active and running. Proceed to the next step after the pods are running.

    Statefulsets list
  14. In the OpenShift UI, navigate to Networking → Routes; the URL for accessing your Sonatype Nexus Repository instance appears in the Location column.

    Routes screen