With the announcement of JFrog Container Registry, I wanted to share several thoughts about some patterns and best practices regarding container registries.

Use multiple repositories

In many organizations there are clear and well-defined policies regarding permissions. In some companies, members of one team can’t access the images of other teams (in some cases they shouldn’t even be aware of the existence of those projects)

Although you could probably define fine-grained permissions based on image names/paths, an easier and more maintainable approach would be to define it by repositories!

Use Build Promotions

The main idea here is to ‘promote’ your builds (images) to more mature repositories as your artifacts graduate through the CI/CD pipeline.
This means having different repositories for the different CI/CD phases (e.g., dev, qa, pre-prod and prod).
Then, your runtime (e.g., K8S cluster) should pull images only from a production-level repository.
This best-practice goes hand-to-hand with the previous one of having multiple repositories.

Always use Virtual Repositories

A virtual repository is an aggregate of one or more repositories. It allows you to manage this group while providing your clients (developers, build jobs and consumption sites) a single and stable URI.
When always exposing your repositories through virtual ones (even when you have a single repository) you essentially guarantee that maintenance will not require changes on the consuming side (jobs, developers, etc.…).

Always Publish Build-info

If your container registry supports it, always publish build information along with the image you build.
For example, dependency information about what actually resides in the image itself.
Let’s discuss an example:
Suppose you are building a Java web application (WAR file) and put that in a Docker image.
Your Docker image doesn’t have a direct dependency on the Java application. In Docker, dependencies are always in the form of Docker layers.
Having in your build information the dependencies themselves (i.e., the Java application and its own dependencies) will greatly help with traceability, scanning and management of the process.

High Availability

Well, I can’t finish the discussion of container registry best practices without mentioning HA.
You should be aware that your K8S cluster becomes quite unusable if it can’t access the container registry.
It is though, extremely important to connect your runtime container environments to a stable, enterprise grade, Docker registry that provides High Availability.