Integrated resiliency in GitLab for use of container images hosted in public or private container registries
Problem to solve
A key component of CI pipelines is typically the use of container images. These images, as we know, can be hosted on public or private container registries. However, now that production critical CI pipelines are dependent on these registries, customers need simple to use mechanisms to mitigate the risk of a failure to connect to a registry.
For example, a public container registry can be affected by a DNS outage resulting in the CI pipelines not executing as the required container image cannot be pulled. Or, a private registry, if not architected to be fully resilient and self-healing can also impact critical CI jobs if there is a failure.
Proposal
Integrate into GitLab a first-class solution that enables an administrator to immediately transition all pipelines associated with a GitLab group to use a different container registry. So that an administrator can move all pipelines to a given registry with one change.
Further details
Create two new special purpose variables, called CI_REGISTRY_PROXY_URL
and CI_REGISTRY_PROXY_PASSWORD
that are always expanded by the runner in front of the image name in the .gitlab-ci.yml
. For example, writing:
image: alpine:latest
would always act as if it were written
image: ${CI_REGISTRY_PROXY_URL}${CI_REGISTRY_PROXY_PASSWORD}alpine:latest
- If left blank, the default settings on the runner systems would be used.
- Or they can assign the variable a value at the group or project (or namespace?) level in the GitLab UI.
Risks/downsides
The main downside here is that this is a powerful change that can be imposed in a confusing and non-obvious way and might lead to some very challenging situations to debug.