Hey,

we're running this image in a K8s cluster. We already have >250GB data and this leads to a problem that the 2nd line in the run script (the chown of the /nexus-data) takes ages or even hangs. Then K8s thinks that the pod is not ready in time and will reschedule it.

We could increase the timeout but this is a dirty quickfix that doesn't scale.

An idea is to control the chown line via an ENV variable. So for example
CHOWN_NEXUS_DATA=true could be the default and could be overridden if the chown thing is not needed.

Imho this command should only be run for initial startup and not necessarily on each startup since the files are already owned by the nexus user.

If you agree i could also add a PR for this.

docker pull quay.io/travelaudience/docker-nexus:3.30.1
Error response from daemon: manifest for quay.io/travelaudience/docker-nexus:3.30.1 not found: manifest unknown: manifest unknown

latest available 3.31.1 (official)

latest available in quay.io is 3.29.2 (6 month ago)

it's important as 3.29.2 contains critical vulnerabilities

Hi,

The usage of runsvdir is usefull to being able to restore from a backup but prevent gracefull stop of his childs processes when you try to stop the container.

The docker stop command attempts to stop a running container first by sending a SIGTERM signal to the root process (PID 1) in the container.

If runsvdir receives a TERM signal, it exits with 0 immediately (https://www.unix.com/man-page/centos/8/runsvdir/)

The aftermath of this : you can't gracefully stop nexus when you do any of this actions , because every of this commands send SIGTERM to the root process(runsvdir) :

• kubectl delete
• kubectl scale statefulset --replicas=0
• helm delete
• docker stop

Best regards.

3.26 introduces an import/export capability to Nexus (https://issues.sonatype.org/browse/NEXUS-11468) that would be nice to have. If you want, I can submit a PR to update the Dockerfile for the new version, but I don't know anything about your official process for releasing a new version or testing guidelines. Thanks.

Bump nexus version to 3.9.0

Hi,

Could you explain why we are doing a change owner here on the folder /nexus-data ?
We have more than 15K packages in a cache repo, and we need almost 20 minutes to start the container/service.

Thank you.

And Alpine 3.6.2 while we're at it.

You released an important upgrade a few days ago, but I could not find it in quay to upgrade. Could you release it to https://quay.io/repository/travelaudience/docker-nexus?

Is there any reason why -XX:MaxDirectMemorySize=2703m is not removed from ${NEXUS_HOME}/bin/nexus.vmoptions?

If I set MaxDirectMemorySize in environment variable INSTALL4J_ADD_VM_PARAMS it will be overwritten by the setting from nexus.vmoptions.

see that such issue (fail publish to Quay because of docker rate limits) reproduced several times

#60 (comment)
#65 (comment)

https://quay.io/repository/travelaudience/docker-nexus?tab=info

may be it's possible to automate somehow or control status of publishing?

travelaudience/docker-nexus is developed to not run as a certain user. So it will run as UID 0. This is not preferred in case of security. Maybe there's a chance for a change in further versions?
Thanks
Markus

I am looking for a way to install other bundles into the docker image. Besides extending the base image and do some copy and update features.xml file, do we have another way to do it?

A critical security vulnerability has been found in all versions of NXRM 3 up to and including 3.21.1.

See https://help.sonatype.com/repomanager3/release-notes/2020-release-notes#id-2020ReleaseNotes-RepositoryManager3.21.2

Hi!

Thanks for the image!

Can you release 3.24? https://help.sonatype.com/repomanager3/release-notes

Thanks!

Could you upgrade to Nexus version 3.18.1?

The latest images after 3.29.2 are missing from https://quay.io/repository/travelaudience/docker-nexus?tag=3.13.0_alpine_3.8.1&tab=tags . Please can you publish these? I was trying to upgrade to 3.30.1 but couldn’t find the images anywhere.

Sonatype has official docker container images.

https://hub.docker.com/r/sonatype/nexus3
https://github.com/sonatype/docker-nexus3

Looks like the build of quay.io/travelaudience/docker-nexus:3.29.2 was failed.
Could you please fix it?

Our nexus wants upgrade to the latest version 3.16.2.

The default logback.xml https://github.com/sonatype/nexus-public/blob/master/assemblies/nexus-base-template/src/main/resources/overlay/etc/logback/logback.xml has additional loggers.

These tasklogfile logger block are needed for the Admin clean up tasks added as part of release 3.14.0

2019-07-26 09:51:36,536+0000 INFO  [qtp1610238176-40] admin org.sonatype.nexus.quartz.internal.task.QuartzTaskInfo - Task 'Cleanup service' [repository.cleanup] state change WAITING -> RUNNING
2019-07-26 09:51:36,574+0000 INFO  [quartz-3-thread-6] *SYSTEM org.sonatype.nexus.cleanup.internal.task.CleanupTask - Task information:
2019-07-26 09:51:36,574+0000 INFO  [quartz-3-thread-6] *SYSTEM org.sonatype.nexus.cleanup.internal.task.CleanupTask -  ID: d817a286-5f39-4136-a696-afaffba11a43
2019-07-26 09:51:36,574+0000 INFO  [quartz-3-thread-6] *SYSTEM org.sonatype.nexus.cleanup.internal.task.CleanupTask -  Type: repository.cleanup
2019-07-26 09:51:36,574+0000 INFO  [quartz-3-thread-6] *SYSTEM org.sonatype.nexus.cleanup.internal.task.CleanupTask -  Name: Cleanup service
2019-07-26 09:51:36,574+0000 INFO  [quartz-3-thread-6] *SYSTEM org.sonatype.nexus.cleanup.internal.task.CleanupTask -  Description: Run repository cleanup
2019-07-26 09:51:36,575+0000 ERROR [quartz-3-thread-6] *SYSTEM org.sonatype.nexus.logging.task.TaskLogHome - Could not find a Logback SiftingAppender named 'tasklogfile' in the logback configuration. Please check that the 'tasklogfile' appender exists in logback.xml
2019-07-26 09:51:36,575+0000 INFO  [quartz-3-thread-6] *SYSTEM org.sonatype.nexus.cleanup.internal.task.CleanupTask - Starting cleanup
2019-07-26 09:51:36,623+0000 ERROR [quartz-3-thread-6] *SYSTEM org.sonatype.nexus.cleanup.internal.task.CleanupTask - Failed to run task 'Run repository cleanup'
java.lang.NullPointerException: null
    at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:882)
    at org.sonatype.nexus.cleanup.internal.storage.orient.OrientCleanupPolicyEntityAdapter.get(OrientCleanupPolicyEntityAdapter.java:133)
    at org.sonatype.nexus.cleanup.internal.storage.orient.OrientCleanupPolicyStorage.lambda$3(OrientCleanupPolicyStorage.java:95)
    at org.sonatype.nexus.orient.transaction.OrientOperations.lambda$1(OrientOperations.java:56)
    at org.sonatype.nexus.transaction.OperationPoint.proceed(OperationPoint.java:64)
    at org.sonatype.nexus.transaction.TransactionalWrapper.proceedWithTransaction(TransactionalWrapper.java:56)
    at org.sonatype.nexus.transaction.Operations.transactional(Operations.java:200)
    at org.sonatype.nexus.transaction.Operations.call(Operations.java:146)

Hi,

Please, can you elaborate, in the README for example, on the difference with the official Docker for Nexus?

https://github.com/sonatype/docker-nexus3

As a simple user, it is quite difficult to decide which solution should be used.

It seems that Nexus is unable to detect the right amount of CPUs/Cores.
Before I file a bug upstream, can you please verify that your set up shows the same?
I regularly need bulk delete of blob objects and doing so is always very slow.

Currently using latest which is 3.23 and encountering the following:

This version of Nexus Repository Manager is vulnerable to a critical remote code execution security vulnerability.

We recommend immediate upgrade to 3.25.1 or later, especially if this is a public instance.

I'm happy to do a PR and update the Dockerfile if that helps.

P.S. thanks for publishing this image - great help! :)

Hi!
We try to run nexus cluster in k8s. We use helm-chart oteemocharts/sonatype-nexus 4.0.0 and image quay.io/travelaudience/docker-nexus:3.25.1

In hazelcast documentation we found info about following plugin
https://github.com/hazelcast/hazelcast-kubernetes

Does image quay.io/travelaudience/docker-nexus already include thit plugin for working with kubernetes?
Thank you.

Appreciate you did it with extra feature for production enviroinment.

it is not problem, it is just a culture and policy in the compay. We are not allowed to use alpine as base image for any production applications.

We can run some tools using alpine image for a quick job, but not running application.

Could you give me some hints, if it is possible:

I want to use exist official nexus docker image and add the extra feature as you mentioned in this repo (uses runit to run nexus under a secondary process)