Skip to main content

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.

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.

Note

Please note that Sonatype Nexus Repository does not currently provide full support for the Open Container Initiative (OCI).

Tasks such as the Docker - Delete unused manifests and images may produce undesired results when run against an OCI image, including unexpectedly deleting some manifests.

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:

  • example.com = hostname

  • 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 Docker Repository Reverse Proxy Strategies

  2. Using a subdomain connector PRO

  3. Using port connectors

Note

If more than 20 connectors are needed, you must use either a reverse proxy or a subdomain connector.

Note

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 https://docs.docker.com/registry/spec/manifest-v2-2/ for more information on docker's schema specification.

Note

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 a reference and help for your usage.