Skip to content

Determine the type of container registry to drive future prioritization and user-experience decisions

backend-weight2

Problem to solve

New features only supported by the GitLab Container Registry fork are becoming more common and the necessity to support other registries requires workarounds and fallback options. !23325 (merged) is an example of this.

We need a way to determine whether the registry being used is the GitLab Container Registry or a third-party registry. This allows us to toggle specific features based on the registry type.

Intended users

Further details

Implementation

There are 4 required steps to determine if a self-managed instance is using an external container registry.

  1. Update the Container Registry API to respond to GET /v2 requests with two additional headers:
  • Gitlab-Container-Registry-Version: The semantic version of the GitLab Container Registry (e.g. 2.9.0-gitlab);
  • Gitlab-Container-Registry-Features: A comma separated list of extensions/features that are not part of the Docker Distribution spec (e.g. tag_delete,...).

The HTTP response from a third-party Container Registry to GET /v2/ looks like:

HTTP/1.1 200 OK
Content-Length: 20
Content-Type: application/json; charset=utf-8
Date: Thu, 30 Apr 2020 08:50:01 GMT
Docker-Distribution-Api-Version: registry/2.0

And the response from the GitLab Container Registry looks like:

HTTP/1.1 200 OK
Content-Length: 20
Content-Type: application/json; charset=utf-8
Date: Thu, 30 Apr 2020 08:50:01 GMT
Docker-Distribution-Api-Version: registry/2.0
Gitlab-Container-Registry-Version: 2.9.0-gitlab
Gitlab-Container-Registry-Features: tag_delete
  1. Add a new rake task to Rails that will query this API route and register wether the container registry is the GitLab one (response contains the Gitlab-* headers) or a third-party (no Gitlab-* headers) and save the result to the database.
  2. Omnibus can then call this rake task whenever a self-managed instance is reconfigured: #214251 (closed)
  3. Measure and track this configuration across all available GitLab instances: #199193 (closed)

Database updates

Add 3 new columns to the application_settings database table:

name type description
container_registry_vendor text Possible values of gitlab and other. If the registry responds to an GET /v2/ request with headers like Gitlab-.*, then we set this to gitlab, otherwise it's other. It's worth to make this a text field because in future we may want to determine the type of some third-party registries as well. So we can expand other with specific vendors like e.g. amazon.
container_registry_version text This is the content of the Gitlab-Container-Registry-Version header from a GET /v2/ response (semantic version).
container_registry_features array This is a list of features supported by the registry. It should be set to the content of the Gitlab-Container-Registry-Features header from a GET /v2/ request. Example: [:tag_delete].

Testing with the Container Registry

The GitLab Container Registry has already been updated to reply with the additional headers. This change will be released in 13.0. Meanwhile, to develop/test the GitLab change, one can use the registry.gitlab.com/gitlab-org/container-registry:v2.9.1-gitlab-pre image.

  1. Setup a GDK instance (instructions) with the Container Registry integration (instructions);

  2. No changes are required to test the behavior when using a third-party registry. Versions prior to the unreleased v2.9.1 will not include the new headers on the response to GET /v2/. Therefore, testing with the current v2.9.0 or any version before that will replicate the behavior of third-party registries.

  3. To test the change with the new GitLab Container Registry headers, change the image that your GDK is using to spin the registry container:

    cd <your GDK root, not the GitLab app root>
echo registry.gitlab.com/gitlab-org/container-registry:v2.9.1-gitlab-pre > registry_image
gdk reconfigure
gdk restart

    Confirm that you're using the correct image:

    $ docker ps
CONTAINER ID        IMAGE                                                                 ...
6b1522686d27        registry.gitlab.com/gitlab-org/container-registry:v2.9.1-gitlab-pre   ...

    Try to invoke the registry API with curl -i localhost:5000/v2/. You should see a response with the new headers. You can now test the GitLab change.

Permissions and Security

  • There are no permissions changes required for this change

Documentation

Availability & Testing

What does success look like, and how can we measure that?

  • Success looks like we are able to understand how many instances are using an external container registry, so we can better refine future user experiences.

Metrics

Track the total number of (known) self-managed instances which are utilizing an external container registry, instead of the GitLab Container Registry.

Edited by João Pereira