Closed Chaostheorie closed 4 weeks ago
As an example of running a registry locally with HTTP, an excerpt from an omnibus config for the registry:
registry_external_url 'https://registry.gitlab.cobalt.rocks'
gitlab_rails['registry_enabled'] = true
gitlab_rails['registry_host'] = "registry.gitlab.cobalt.rocks"
gitlab_rails['registry_port'] = 443
gitlab_rails['registry_api_url'] = "http://127.0.0.1:6050"
registry['registry_http_addr'] = "127.0.0.1:6050"
registry['debug_addr'] = "127.0.0.1:6037"
Edit: To clarify, this is what I would expect to be possible with the services.gitlab
module. The configuration above is taken from the live setup used for gitlab.cobalt.rocks
with a TLS-terminating NGINX.
I seem to have misunderstood the use of keyFile and certFile.
Describe the bug
The current NixOS module for GitLab, available under
services.gitlab
, requires one to specify an SSL certificate for GitLab's container registry.This doesn't reflect GitLab's own configuration, to the extent that the registry can be configured without HTTPS.
This is specifically a problem when one tries to serve a GitLab registry behind a TLS-terminating reverse proxy. Such a setup is IME rather common when running GitLab + GitLab registry on a single server behind, e.g., NGINX.
Steps To Reproduce
Steps to reproduce the behavior:
services.gitlab.registry.enable
services.gitlab.registry.{issuer,certFile,keyFile}
are used and not optionalExpected behavior
Make
services.gitlab.registry.{issuer,certFile,keyFile}
optional withlib.types.nullOr
and default asnull
. Afterward, adjust GitLab module to:It should be noted that specifying any of
services.gitlab.registry.{issuer,certFile,keyFile}
probably should require all of them.Notify maintainers
Pinging members of GitLab team based on
meta.maintainers
: @globin @krav @talyz @yayayayakaAdd a :+1: reaction to issues you find important.