Available in Nexus Repository OSS and Nexus Repository Pro
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.
Nexus Repository Manager Pro and Nexus Repository Manager OSS support Docker registries as 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:
- example.com = 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:
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.
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:
- SSL and Repository Connector Configuration
- Proxy Repository for Docker
- Docker Repository Reverse Proxy Strategies
- Docker Subdomain Connector
- Hosted Repository for Docker (Private Registry for Docker)
- Grouping Docker Repositories
- Content Selectors and Docker
- Docker Authentication
- Accessing Repositories
- Pulling Images
- Pushing Images
- Pushing Images to a Group Repository
- Scaling Repositories
- Foreign Layers
- Docker Content Trust