Registry

Harbor

To store our Docker images, we’re running our own Harbor instance.

Note

The deployment, and all documentation for Harbor can be found in the GitLab Harbor project.

Registry projects

We’ve several projects in our Harbor, according to the following convention:

• base: Project for our public Base images

• internal: Project for our internal images (e.g. non-product development, web, docs)

• {product name}: Product-specific projects (each product gets its own project)

Hint

We’re distributing our products via (Docker) images to different customers. Thus we’ve decided to have a dedicated registry project for each product, so that we’ve granular access control.

Image retention

Having proper garbage collection, resp. retention is crucial for storage space, and to provide cleaned up repositories.

Our retention for all Docker registries, resp. images is set to the following rules:

1. latest images will always be retained

2. The 10 most recently pushed semantic-versioned images (e.g. 1.2.3) will be retained

3. All other images will retained for 7 days after they’ve been pushed

Note

There are some exceptions, such as the base images, as they’re sometimes named differently (e.g. python:3, or debian:trixie).

Hint

Of course, misconfigured garbage collection can remove some of those “still needed” images. Even so, thanks to our automated pipelines, most images can be easily rebuilt from scratch.