A Dockerfile for Sonatype Nexus Repository Manager 3, based on CentOS. The git repo is https://github.com/sonatype/docker-nexus3.
To run, binding the exposed port 8081 to the host.
$ docker run -d -p 8081:8081 --name nexus sonatype/nexus3
$ curl -u admin:admin123 http://localhost:8081/service/metrics/ping
To (re)build the image, copy the Dockerfile and do the build:
$ docker build --rm=true --tag=sonatype/nexus3 .
Default credentials are:
It can take some time (2-3 minutes) for the service to launch in a new container. You can tail the log to determine once Nexus is ready:
$ docker logs -f nexus
Installation of Nexus is to
A persistent directory,
/nexus-data, is used for configuration, logs, and storage. This directory needs to be writable by the Nexus process, which runs as UID 200.
Three environment variables can be used to control the JVM arguments
JAVA_MAX_HEAP, passed as -Xmx. Defaults to
JAVA_MIN_HEAP, passed as -Xms. Defaults to
EXTRA_JAVA_OPTS. Additional options can be passed to the JVM via this variable.
These can be used supplied at runtime to control the JVM:
$ docker run -d -p 8081:8081 --name nexus -e JAVA_MAX_HEAP=1500m sonatype/nexus3
There are two general approaches to handling persistent storage requirements with Docker. See Managing Data in Containers for additional information.
- Use a data volume container. Since data volumes are persistent until no containers use them, a container can created specifically for this purpose. This is the recommended approach.
$ docker run -d --name nexus-data sonatype/nexus3 echo "data-only container for Nexus" $ docker run -d -p 8081:8081 --name nexus --volumes-from nexus-data sonatype/nexus3
- Mount a host directory as the volume. This is not portable, as it relies on the directory existing with correct permissions on the host. However it can be useful in certain situations where this volume needs to be assigned to certain specific underlying storage.
$ mkdir /some/dir/nexus-data && chown -R 200 /some/dir/nexus-data $ docker run -d -p 8081:8081 --name nexus -v /some/dir/nexus-data:/nexus-data sonatype/nexus3
Hi! If I need install bundle, What should I do?
"Three environment variables can be used to control the JVM arguments
- JAVA_MAX_HEAP, passed as -Xmx. Defaults to 1200m.
- JAVA_MIN_HEAP, passed as -Xms. Defaults to 1200m.
- EXTRA_JAVA_OPTS. Additional options can be passed to the JVM via this variable."
Is this still valid ? For me JAVA_MIN_HEAP and JAVA_MAX_HEAP didn't work as expected.
Here is a different description: https://github.com/sonatype/docker-nexus3
According to your official docs, upgrade from "3.0.2" to "3.1" must take care manually of many little things (https://support.sonatype.com/hc/en-us/articles/231723267-How-to-Upgrade-Nexus-Repository-Manager-3-0-2-to-3-1-0), while on another doc you say with docker you just have to upgrade the image (http://blog.sonatype.com/nexus-repository-3.0-qa). Second one is of course wrong. But handling data within docker container is not that easy, especially since Nexus3 stops during the process thus the container is not accessible anymore...
Do you guys have any good solution to migrate from 3.0.2 to a newer version of Nexus (say 3.2 since it has recently been released...)
The "Persistent Data" section is completely bogus. First off, this container doesn't even start if we mount an external volume to /nexus-data. Clearent solved part of this (https://hub.docker.com/r/clearent/nexus/) but really, it should be sonatype to fix it. Thanks Clearent/@cavemandaveman! Stateless containers FTW!
Besides, there are different kinds of persistent data and there is also non-persistent data! Lock files, pid files, port files and (to some extent) temporary files are not supposed to be persisted! If the service dies suddenly and docker restarts it, we're in trouble if the pid files and lock files from the previous run are still in place because they will prevent the services from starting back up. So they must not be in /nexus-data. Moreover, temporary files and cache files can be saved between container rebuilds/recreates/restarts if that'll save runtime rebuilding cache and whatnot, but that is not the same kind of persistence as the user/permissions database and system configuration files. Temp/cache may be persisted, but there's no point in backing them up. Databases, configurations, user files must be persisted and backed up for disaster recovery.
So all in all, the data in /nexus-data has to be separated in what must be persisted for backup, what may be saved between runs and what must not be kept between runs. These sonatype containers are pretty messed up before that happens.
Had some problems upgrading an instance from 3.0.0 to 3.0.2. When I updated the image in the docker-compose.yml file I was using and restarted, I got a whole bunch of "Could not find artifact" errors.
The solution (from here) was to find the volume I was storing the persistent data in (using "docker volume ls" and "docker volume inspect") and then touching a "clean_cache" file in the volume. I could then start the container successfully.
@parana I have seen this on first run, but this error is no longer present on subsequent runs.
Considering that Sonatype has not responed to a lot of the issues and suggestions, I created a nexus container you can find here: https://hub.docker.com/r/clearent/nexus/ that is built on top of Alpine, uses OpenJDK, supports SSL, does not require prerequisites on the host for volume mounting, has working JVM args, and uses the latest nexus 3.0.1-01 release
I cannot upload files into the repository using the above method. I go to Repositories, but I do not see the "Artifact tab." What did I do wrong?
There is no evidence that Maven is installed. I tried to get it installed in the Docker container. But when inside, I do not have administrator privileges. How do I create a Nexus 3 & Maven Docker container? Would Maven be required to upload files and actually use Nexus 3?
perhaps sonatype could consider my pull request updating this image to using OpenJDK https://github.com/sonatype/docker-nexus3/pull/27
and i think the other repository (sonatype/docker-nexus3) is more up-to-date because it's linked to a automatic build; maybe this respository can be replaced with that one ?
Today I get this error:
2016-09-04 13:57:20,210+0000 WARN [pool-15-thread-1] org.apache.karaf.features.internal.service.FeaturesServiceImpl - Can't update cfg file java.io.FileNotFoundException: /opt/sonatype/nexus/etc/org.apache.karaf.command.acl.feature.cfg (Permission denied) at java.io.FileOutputStream.open0(Native Method) [na:1.8.0_77] at java.io.FileOutputStream.open(FileOutputStream.java:270) [na:1.8.0_77] at java.io.FileOutputStream.<init>(FileOutputStream.java:213) [na:1.8.0_77] at java.io.FileOutputStream.<init>(FileOutputStream.java:162) [na:1.8.0_77] at org.apache.felix.utils.properties.Properties.save(Properties.java:152) [org.apache.karaf.features.core:4.0.4] at org.apache.felix.utils.properties.Properties.save(Properties.java:148) [org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeatureConfigInstaller.updateStorage(FeatureConfigInstaller.java:292) [org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeatureConfigInstaller.installFeatureConfigs(FeatureConfigInstaller.java:107) [org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:1166) [org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:778) [org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089) [org.apache.karaf.features.core:4.0.4] at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985) [org.apache.karaf.features.core:4.0.4] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_77] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_77] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_77] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_77]
Some idea to solve this ?