# Install Nexus Repository on OpenShift Only available in Sonatype Nexus RepositoryTM Pro. Interested in a free trial? [Start here](/content/products/repository-pro/trial/index.html). ## Prerequisites You must meet the following prerequisites to install Nexus RepositoryTM using the OpenShift operator: - Running the OpenShift platform with access to RedHat repositories and Administrator privileges - A separate OpenShift project for 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](https://help.sonatype.com/en/system-requirements-for-high-availability-deployments.html "Requirements for High Availability"). ### 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)](https://kubernetes-csi.github.io/docs/drivers.html) 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. Refer to [OpenShift documentation for details on configuring CSI drivers](https://docs.openshift.com/container-platform/4.13/storage/container_storage_interface/persistent-storage-csi.html). #### 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](https://docs.openshift.com/container-platform/4.13/storage/persistent_storage/persistent_storage_local/persistent-storage-local.html) and [Local Storage Operator documentation](https://github.com/openshift/local-storage-operator) 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](https://docs.openshift.com/container-platform/4.13/storage/persistent_storage/persistent_storage_local/persistent-storage-local.html) documentation #### 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 OrientDB Operator The 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. The new operator requires a Pro license. To use the new operator, you need to uninstall the old operator, migrate to PostgreSQL, obtain a Pro license, and install the new operator as outlined in the installation instructions below. See [Migrating to a New Database](https://help.sonatype.com/en/migrating-to-a-new-database.html "Migrating to a New Database") ## Installation Steps 01. Log into the OpenShift UI as an administrator. 02. Navigate to _Operators → Operator Hub_; locate and install (if not already installed) the _Nexus Repository HA Operator_ in an existing or new project. | | | --- | | | Complete the remaining steps for the operator to be fully operational. 03. After installing the operator, navigate to _Operators → Installed Operators_; select the _Nexus Repository HA Operator_ to update the custom resource definitions. | | | --- | | | 04. Select the _NexusRepo_ tab; then, select the _Create NexusRepo_ button. | | | --- | | | 05. Provide a name for your custom resource definitions or keep the default and select _Create_. | | | --- | | | 06. The custom resource definition now appears in a table under the _NexusRepo_ tab. | | | --- | | | 07. Select the custom resource definition that you just created. 08. Within the custom resource definition, navigate to the _YAML_tab. | | | --- | | | 09. Update the following attributes in the YAML: 1. Set the following property. ``` spec.ingress.defaultRule = true ``` 2. If you have more than one Docker repository, you 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 = ``` 4. ``` spec.ingress.enabled = true ``` 5. `spec.ingress.host = .` 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 = ``` Follow [Kubernetes's documentation for creating a TLS secret and Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) 7. If you have not already done so, convert your license file to Base64-encoded format using a command like the following: ``` $ base64 ``` 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 = spec.statefulset.env.password = spec.statefulset.env.user = spec.statefulset.env.nexusInitialPassword = spec.statefulset.env.replicaCount = ``` 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. | | | --- | | | 14. In the OpenShift UI, navigate to _Networking → Routes_; the URL for accessing your Nexus Repository instance appears in the _Location_ column. | | | --- | | | ## Upgrading an OpenShift Operator Upgrading an OpenShift Operator can be done through the OpenShift console or the command-line interface (CLI). Here's a general guide, but always refer to the specific Operator's documentation for any unique instructions: 1. Navigate to Installed Operators: In the OpenShift console, go to "Operators" > "Installed Operators." 2. Find Your Operator: Locate the Operator you want to upgrade in the list. Operators with available updates will typically show an "Upgrade available" status. 3. Initiate the Upgrade: Click on the Operator name. On the Operator details page, you'll usually find an "Upgrade" button or a similar option. 4. Select Channel (If Applicable): Some Operators offer different update channels (e.g., stable, beta). Choose the channel you prefer for the upgrade. 5. Review and Approve: Review the upgrade details, including the new version number and any release notes. Approve the upgrade to proceed. 6. Monitor Progress: OpenShift will handle the upgrade process. Monitor the status to ensure the Operator is upgraded successfully. ## Important Notes - Operator Documentation: Consult the specific Operator's documentation for the most accurate and up-to-date upgrade instructions. - Backup: It's a good practice to back up your cluster or relevant resources before upgrading an Operator, especially in production environments. - Dependencies: Be aware of any dependencies the Operator might have. Upgrading could affect other components in your cluster. Rollback: Have a rollback plan in case issues arise during the upgrade. - Testing: If possible, test the Operator upgrade in a non-production environment first to identify any potential problems.