Using your existing Nexus IQ configuration and key-store inside a Docker image - Sonatype Lifecycle & Repository Firewall - Sonatype Community

Using your existing Nexus IQ configuration and key-store inside a Docker image

post by kmatthews on Jan 25, 2019

Having successfully transitioned my native host deployment of NXRM to run inside a docker container (see here), I decided to embark upon the same process for my IQ server.

My objective is to run IQ Server in a docker container, whilst retaining existing scan results and configuration established through deploying IQ on my native host machine. I also need to reference the same key-store and config.yml, thus ensuring a seamless transition from native to docker container deployment.

I referenced the /sonatype/nexus-iq-server instructions to achieve my objective.

The command to run IQ inside a docker container and achieve the aforementioned objectives is:

docker run -d -p 8070:8070 -p 8433:8433 --name nexus-iq -v /native-host-install-dir/sonatype-work/clm-server:/sonatype-work -v /nxrm-native-host-install-dir/etc/ssl/:/etc/ssl -v /native-host-install-dir/:/etc/nexus-iq-server -e JAVA_OPTS="-Ddw.sonatypeWork=/sonatype-work" Kevins-MBP.home:18080/sonatype/nexus-iq-server

The nexus related arguments are explained below:


post by mworthington on Jan 26, 2019

It is probably worth mentioning that these middle three steps may not apply to everyone.

The main takeaway from these three is that the default docker image is set to use the config.yml stored in /etc/nexus-iq-server, and ignores the one in /opt/sonatype/nexus-iq-server/ alongside the IQ Server jar file which is typically the location that admins coming from a local install are used to customizing.

A second takeaway is that the default configuration does not include SSL, and while you can override config.yml settings with environment variables, it is difficult or not possible to add SSL in this way.

The default sonatypeWork folder in the docker image is in fact /sonatype-work. This differs from the sonatypeWork location from the zip bundle where it is set to a relative location meant to reside in the install directory where the zip is extracted. When using the same config.yml inside of the docker image, as described in the fourth item, you will need to reset this using a Java Option when starting the container. Alternatively, adjust your sonatype-work volume mapping to the relative location in the container.