We have set 500 as maximum number of threads in Nexus (version 3.12.1) but we are getting some problems to set our Docker repositories because when Nexus starts we can read in the log a message like this:
*2019-03-18 06:33:54,142+0100 WARN [jetty-main-1] SYSTEM org.sonatype.nexus.bootstrap.jetty.ConnectorManager - Could not start connector: DockerConnectorConfiguration{repositoryName=10014.TSFPLUS.docker.hosted, scheme=http, port=10014} java.lang.IllegalStateException: Insufficient configured threads: required=507 < max=500 for QueuedThreadPool@qtp1684411209{STARTED,8<=137<=500,i=0,q=54}
We would like to know which objects generate threads because we have created a lot of repositories (maven, NuGet, Npm) and it is possible that a lot of them are not used, so If these kind of repositories create threads in the start process, we could delete some of them to get more free threads to Docker repositories.
Increasing jetty threads is not the answer here, it sounds like you have far too many docker connectors configured. If you have a large number of repositories a reverse proxy should be used, as described here:
We have consulted to our IT team and they have said that it is difficult define a “reverse proxy” for each Docker repository because of the amount of Docker repositories in our Nexus instance.
No, there is no other solution. Docker repositories must run on web context path “/”. This limitation is imposed by the docker format, not by Nexus Repo. But because of this limitation Docker repositories must either use a different hostname or port. The built in mechanism uses different ports, but this won’t scale beyond a few dozen repositories, the Jetty web server is not designed to simultaneously listen on hundreds of ports. A reverse proxy will be needed.
Or alternatively, you could come up with a design for repository usage that does not require so many repositories. You’ll find that scales a lot better than trying to use hundreds of repositories, and is easier to manage. The way to do that is to use content selector privileges to slice up a docker repository, creating namespaces that each team can use.
The blobs are docker layers, and they can (and often are) shared between multiple docker images. This sharing of layers is the reason why docker is an efficient format for storing VM’s. The upshot of this is that you can’t restrict access to layers. So you’ll need to create a content selector privilege that allows access to all layers. Additionally, you need to allow access to “/v2/” for docker login, and “/v1/search” for search".
So you’ll need a content selector privilege like this that allows access to the things everyone needs:
path =~ "/v2/|/v2/blobs/.*|/v2/search/.*"
After this, you can selectively allow access to manifests and tags by using content selectors like this:
