Container registries tend to support the Docker Registry HTTP API, allowing their users to rely on the same tools to operate them. However, some implementations have their peculiarities and limitations. Thus, you have to take into account their specifics when using them as part of your CI/CD toolchain. That is exactly what happened when we decided to improve the way our werf GitOps utility manages the lifecycle of images.

In this article, we will discuss the main peculiarities of Docker Registry implementations supported by werf as well as resulting improvements in our tool.

Storing images

As you know, you need a registry to store and distribute Docker images. Strictly speaking, a registry is just a service to store various repositories (AWS ECR, Azure CR, Docker Hub, and so on). The repository stores images grouped by name.

When building applications and/or deploying them to Kubernetes with werf, you can use --images-repo and --images-repo-mode parameters. They allow you to specify where and how (in a single or multiple repositories*) application images will be stored in the registry.

* You can learn more about these parameters (including the problem definition and history of development) in our “Monorepo/multirepo support in werf (and what does it have to do with Docker Registry?)” article.

The --images-repo parameter can be either a registry address or a repository address. In essence, its value serves as the basis for composing the name of an image and not necessarily specifies the repository where the images will be stored (take a look at templates below to clarify this point).

The --images-repo-mode parameter supports two values that define the template for composing the final image name:

• IMAGES_REPO:IMAGE_NAME-TAG is a template for the monorepo mode;
• IMAGES_REPO/IMAGE_NAME:TAG is a template for the multirepo mode.

#container-registry #werf #docker #docker-registry