Migrating to 3.71 on a docker-based installation

Sonatype Nexus Repository
, , ,
1

I’m currently running Nexus from the sonatype/nexus3:3.70.1-java11-ubi image.

The documentation available at Upgrading to Nexus Repository 3.71.0 and Beyond is… lacking. It does not describe a scenario where the whole thing is running off of docker.

Attempting to upgrade the image as is causes the docker container to run in an endless loop cycle as it attempts to load the store and fails:

2024-08-13 15:46:18,175+0000 ERROR [FelixStartLevel] *SYSTEM org.sonatype.nexus.datastore.mybatis.MyBatisDataStore - 
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This instance is using a legacy Orient database. 
You must migrate to H2 or PostgreSQL before upgrading to this version. See our database migration help documentation at: 
https://links.sonatype.com/products/nxrm3/docs/unsupported-db.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2024-08-13 15:46:18,176+0000 INFO  [FelixStartLevel] *SYSTEM org.sonatype.nexus.extender.NexusLifecycleManager - Shutdown requested with an exit code of 1
2024-08-13 15:46:18,176+0000 INFO  [FelixStartLevel] *SYSTEM org.sonatype.nexus.extender.NexusLifecycleManager - Shutting down
2024-08-13 15:46:18,178+0000 INFO  [FelixStartLevel] *SYSTEM org.sonatype.nexus.extender.NexusLifecycleManager - Stop KERNEL

However… well, this is a DOCKER based installation. Typically in such a case I’d expect the container to self-upgrade the database, but clearly this isn’t allowed here. So I’d probably need to override the entrypoint and only then start messing with the database, but here I’m missing instructions. Does the new image use H2 or Postgres by default? Is it even configured to use either of these?

PS. I’m really disappointed because the version I’m currently using was the “first” version I started using Nexus from and it seems at that point already Orient was a deprecated database. So… shouldn’t the 3.70 docker images use a newer database when running against a blank drive already? But I don’t recall anything about this in the docker logs… :confused:

3

I am also running the 3.70.1-java11-ubi image but it doesn’t even seem to be 3.70.1
image

4

OK, this one’s really weird. Are you sure you’re running the image you say you’re running?
This is what my info panel shows:

image
image1172×309 10.5 KB

The build TS alone is incorrect.

5

OK, I’ve managed to resolve this.

Here are the steps I took:

  1. Create a database backup via Nexus tasks as normal; take the Nexus docker container offline
  2. copy the db backup to my local Windows machine (for me, personally, this was easier to work with than an endless string of console windows via docker and a Linux docker host)
    The copy process is up to the reader to figure out - in my case my docker-based Nexus deployment was using a mounted drive, so it was easy (i.e. the backup was directly on my docker host drive and I could just copy it using WinSCP)
  3. download the migrator utility from 3.70.x Downloads (for OrientDB)
  4. create another copy (just in case) of the database backup and run java -Xmx16G -Xms16G -XX:+UseG1GC -XX:MaxDirectMemorySize=28672M \ -jar nexus-db-migrator-*.jar \ --migration_type=h2 (modify as required for whichever shell is used; for Powershell I had to specify the jar file using a ./<filename> format)
    Note that I’ve got following regular Java installation from Oracle (for Windows):
openjdk 11.0.10 2021-01-19
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode)
  1. the migrator will create a nexus.mv.db file in the backup directory; only this file is required!
  2. clear out the existing db folder on the docker-mapped Nexus drive, and place the new nexus.mv.db file there
  3. make sure to set the permissions for the nexus.mv.db file to match everything else! In my case I had to set chmod 200:200 nexus.mv.db, but this is dependant on how the docker Nexus drive is configured
  4. if no database changes were made to the docker-based nexus.properties file, then do NOT make any modifications to this file (contrary to the instruction set from Migrating to a New Database)
  5. update the Nexus docker container definition to use the new sonatype/nexus3:3.71.0-ubi image (latest would probably work as well, but I’d rather keep this guide relevant “here and now”)
  6. Start your docker-based Nexus instance

The instance should recognize the new database file and update it accordingly to 3.71.*.

EDIT: A DB migrated this way has some issues; see resolution in the following response.

3 Likes
6

Hi, thanks for the steps. I did exactly this way but I have duplicate error on maven repo deployment. I used normal docker image. What is the difference between 3.71.0 and 3.71.0-ubi?

After DB migration and version upgrade, are you able to deploy on existing repo?

7

From what I can tell the 3.71.0 tag is the same as 3.71.0-java17-ubi and 3.71.0-ubi (see: https://hub.docker.com/r/sonatype/nexus3/tags?page=&page_size=&ordering=&name=3.71 and compare the digest codes).

That said you are correct - after this whole ordeal I’m also getting Duplicate key errors. :frowning:

Quick googling found this thread: Cannot upload after OrientDB to H2 migration: Unique index or primary key violation · Issue #449 · sonatype/nexus-public · GitHub
There seems to be a script there which solves the issue. I’m going to give it a go after breakfast. :wink: Also worth noting that the script author has also provided instructions a few responses further on how to execute this in a docker-based instance.

EDIT: The script from Github appears to work and seems to have fixed the issue.

Instructions for running the script when dealing with a dockerized Nexus:

  1. copy the script to an .sh file
  2. modify the script as needed to point to the docker-based location for NEXUS_DATA and the following NEXUS_BIN:
NEXUS_BIN=/opt/sonatype/nexus/
NEXUS_DATA=/nexus-data/db
  1. bind/mount the created .sh file to your Nexus container and run it by overriding the entrypoint parameter
  2. if all went well then remove the overridden entrypoint and remove the script bind to cleanup
  3. restart your Nexus container as normal
1 Like
8

Thanks for your quick reply. It seems we should wait for next docker release or maybe migrator jar file.

9

That’s up to you. There is a valid workaround (but not official).

I do agree that this is one of the saddest docker-based releases I’ve seen in a while. :frowning: I’ve been working with systems with complex databases such as SonarQube or ElasticStack and I never had such issues with those systems. I’m hoping that from here on out (i.e. after migrating from Orient to H2) things will be a bit less hectic when upgrading…

1 Like
10

Agreed. We started using Nexus thinking it was a decent company with pretty good open source solutions. However, the first surprise comes when we decide to try a Pro version. After that we can’t go back to OSS without googling. Today is the second load of changes. After the container upgrade, we’ve completely broken our Nexus installation.

11

@felixs Was this part of a self-led Pro trial? We definitely advise against using trial licenses in production for exactly this reason. Repository is like plumbing; the Pro features all let you do things that you would have to carefully unwind before the trial expires (HA, group blob stores, group deploy, SAML, etc.) We aim to make sure this is visible in any of the trial messaging, but it seems like we didn’t catch you in time.