Dependency proxy for GitLab docker registry
Problem to solve
- On premise installations of GitLab need a way to access docker images from external registries locally in order to use Auto DevOps or to be considered as a feasible option for e.a. federal/government customers.
- Needing to managing multiple registry sources does currently add unneeded overhead.
- Relying on external or even multiple external upstream registries creates availability/dependability concerns.
- This defines the first step for the proxy packages category &486
Our docker on-premise registry is to act as a proxy to upstream registries.
Basically, users will instead of referencing the external url needed to fetch and download the docker images use a GitLab instance dedicated URL. The process will otherwise mostly be left untouched for this first installation.
Users will be able to use the proxy functionality of the project's local docker registry through making use of the same urls as were already used. The effects will be automatic, except for being visible in the job log.
docker run [options] <registry URL>/<namespace>/<project>/<image> [arguments]
image: "<registry URL>/<namespace>/<project>/<image>"
The user is able to turn it
on/off in the ci/cd settings of the project. The setting will be
off by default (so we can measure usage data by needing users to explicitly turning it on).
Local registry image retention policy
We can start out with a set default such as
Local registry storage limits
It will count against the same soft (10GB) size restriction for registry on GitLab.com, as part of the repository size limit.
What does success look like, and how can we measure that?
- Auto DevOps will be usable on on-premise installations
- External registries images can be down/deleted without jobs failing taken that the image has been downloaded before.
- The feature will be turned on by at least X% of people using pipelines