Create a local, on-premise mirror of a namespace's GitLab.com Container Registry
Problem to solve
There are GitLab customers that rely on the SaaS version of GitLab, but internally still have projects or use cases that must operate cut off from the Internet. If the organization is using the registry hosted on GitLab.com, they need the ability to mirror their registry locally, so that their air-gapped projects can still have access to the latest, approved images.
Currently, customers are working around this by using Artifactory as a pull-through cache. However, this approach has several challenges:
- The cache is a SPOF (single point of failure) and if it's down, you are 'dead in the water'
- The time/cost of maintaining a separate service
- It does not share layers
Proposal
Allow organizations to mirror the registry locally, so that they can ensure that both their air-gapped and SaaS hosted projects can reliably push and pull images. This will empower GitLab's Enterprise SaaS customers with a more redundant, highly available registry.
Further details
This proposal is currently blocked. The issue is that we cannot currently partition the GitLab.com database and for security/privacy/obvious concerns we cannot mirror the entire database. However, we are rearchitecting the registry to store image manifests in Postgres instead of object storage. Storing the manifests this way will allow us to better understand which container images are associated with which namespace/group/project. This could allow us to more easily partition the database and mirror it.
There are many details of this issue that will need to be determined. But, this would help our larger, enterprise customers consolidate on GitLab and provide a more reliable registry.
Intended users
What is the type of buyer?
This feature, which mainly targets larger enterprise customers should be in the Premium tier.
Is this a cross-stage feature?
Yes, this will impact the Infrastructure team.