Docker Registry stores the Docker images and provides the basic functionalities of pulling, pushing, and deleting the images. In a typical workflow, a commit to your source revision control system would trigger a build on your CI system, which would then push a new image to your registry if the build is successful. A notification from the registry would then trigger a deployment on a staging environment or notify other systems that a new image is available.
Docker Registry is used when the user needs to do the following:
- Tighten control where images are kept
- Own the images distribution pipeline
- Integrate image storage and distribution with the backend development workflow
The important use cases of registry are as follows:
- Pull or download an image: The user requests an image using the Docker client from Docker Registry, the registry in turn responds back to the user with the registry details. Then, the Docker client will directly request the registry to get the required image. The registry authenticates the user with an index internally.
- Push or upload an image: A user requests to push the image, gets the registry information, and then pushes the image directly to the registry. The registry authenticates the user and finally, responds to the user.
- Delete an image: The user can also request to delete an image from the repository.
The user has the option to use the registry with or without the index. Using the registry without the index is best suited for storing private images.
In addition to the preceding use cases, Docker Registry also supports version control for images. It can be integrated with Continuous Integration (CI) and Continuous Development (CD) systems. When a new image is successfully pushed to the registry, then a notification from the registry will trigger a deployment on a staging environment or notify other systems that a new image is available.
In Docker Registry V2, the following new use cases are also supported:
- Image verification: Docker Engine would like to run the verified image so it wants to ensure that the image is downloaded from a trusted source and no tampering has occurred. Docker Registry V2 returns a manifest and Docker Engine verifies the manifest's signature before downloading the image. After each layer is downloaded, the Engine verifies the digest of the layer ensuring that the content is as specified by the manifest.
- Resumable push: It is possible to lose network connectivity while uploading the image to Docker Registry. Now, Docker Registry has the ability to inform Docker Engine that the file upload has already started. Therefore, Docker Engine will respond by only sending the remaining data to complete the image upload.
- Resumable pull: When downloading an image, the connection is interrupted before the completion. Docker Engine keeps the partial data and requests to avoid downloading the repeated data. This is implemented as the HTTP range requests.
- Layer upload deduplication: Company Y's build system creates two identical Docker layers from build processes A and B. Build process A completes uploading the layer before B. When process B attempts to upload the layer, the registry indicates that it's not necessary because the layer is already known. If processes A and B upload the same layer at the same time, both the operations will proceed and the first to complete will be stored in the registry (note that we may modify this to prevent dogpile with some locking mechanism).