Docker Registry

Docker containers and their usage have revolutionized the way applications and the underlying operating system are packaged and deployed to development, testing and production systems. 

The creation of the Open Container Initiative, and the involvement of a large number of stakeholders, guarantees that the ecosystem of tools around the lightweight containers and their usage will continue to flourish.

Docker Hub is the original registry for Docker container images and it is being joined by more and more other publicly available registries such as the Google Container Registry and others.

Nexus Repository supports Docker registries with the Docker repository format for hosted and proxy repositories. You can expose these repositories to the client-side tools directly or as a repository group, which is a repository that merges and exposes the contents of multiple repositories in one convenient URL. This allows you to reduce time and bandwidth usage for accessing Docker images in a registry as well as share your images within your organization in a hosted repository. Users can then launch containers based on those images, resulting in a completely private Docker registry with all the features available in the repository manager.

Docker Port Scalability

The Docker client has strict requirements about how it can retrieve content from a repository (i.e., a registry). These requirements mainly center around the path at which it expects everything to be hosted.

While it is possible to tell the Docker client to use a chosen host from which to retrieve (or to which to upload) images, it is not possible to tell it to use an arbitrary base path where images are stored in a registry. 

To further explain, the Docker client is given a registry to contact by specifying only the hostname + port. It's also given a specific path to an image in that registry. So, for example, it would be given "example:443/some/custom/image" to specify an image. You are not able to specify a registry application path.

Nexus Repository exposes its Docker registries with a repository path of /repository/<repo_name>/ and, by default, and application context path of /.

So, a full Docker image in the repository "docker-hosted" might be accessible at full URL example:443/nexus3/repository/docker-hosted/some/custom/image, which can be broken down as follows:

  • = host name
  • 443 = port
  • /nexus3 = application context path
  • /repository/docker-hosted = base registry path
  • /some/custom/image = specific image path in the registry

There is no way to give the Docker client the application context path or base registry path. Docker needs the registry exposed at the root of the host + port that it is accessing.

This is important because Nexus Repository uses request paths to separate content between different repositories. There are a few potential ways to overcome this Docker limitation:

  1. Using a reverse proxy
  2. Using a subdomain connector PRO NEW IN 3.40.0
  3. Using port connectors
If more than 20 connectors are needed, you must use either a reverse proxy or a subdomain connector.

Note that the Docker client expects secure connectivity (See our  SSL documentation ).

Docker Manifest Lists 

Docker manifest lists allow a manifest to represent support for multiple architectures while maintaining a single "image:tag" reference format. See for more information on docker's schema specification.

The minimum version of Docker that works with Nexus Repository is version 1.8. But please note that Docker is a fast moving project and requires usage of current operating system versions and tools. For example, usage of Red Hat Enterprise Linux 6 is simply not supported. Please use the official documentation as reference and help for your usage.

Topics in this section: