Container image virtual registry: push/pull endpoints API
🗒️ Goal
This issue is for the API endpoints required so that clients can pull objects from the container image virtual registry.
We have a few challenges:
- Authentication. Docker clients will use a specific login flow. For this part, we don't have any choice given that the virtual registry lives in the same host than the dependency proxy for container images. Thus, we have to reuse the dependency proxy authentication service.
- Fixed url structures. Docker clients will not use a prefix and compute accessed urls from there. Instead, it will take the host, append
v2and then append whatever we have on the docker command. Thus, we can't really target the GitLab API endpoints (/api/v4) because docker clients, will use av2prefix:/v2/api/v4. This doesn't look great. Instead, we're going to use the same approach as the dependency proxy: use rails controllers mounted on the correct urls.
| Route | Notes |
|---|---|
| GET /v2/virtual_registries/containers/:registry_id/*image/blobs/:sha | Get a blob from the registry object |
| POST /v2/virtual_registries/containers/:registry_id/*image/blobs/:sha/upload | The upload endpoint required for the workhorse assisted uploads |
| GET /v2/virtual_registries/containers/:registry_id/*image/manifests/:sha | Get a manifest from the registry object |
| POST /v2/virtual_registries/containers/:registry_id/*image/manifests/:sha/upload | The upload endpoint required for the workhorse assisted uploads |
Notes:
- We have mainly two
GETendpoints. - Since we're going to use the
dependencyproxylogic of workhorse, we will need anuploadendpoint to upload the file from the upstream. We don't need any specific suffix here and/uploadwill work well. - Note that, contrary to the dependency proxy for container images, we don't have the
/authorizeendpoint. We will use one recent update from thedependencyproxylogic: the instructions received by workhorse will already include the data that/authorizewould return. - On the
dependencyproxyoptions, make use of theRestrictForwardedResponseHeadersoption to build an allow list of headers that can be forwarded from upstreams. (The precise allow list needs to be investigated).
🛠️ Implementation plan
- Container image virtual registry: database models (#548783 - closed) • Adie (she/her), Radamanthus Batnag • 18.5 • Needs attention
- Container image virtual registry: cache entry s... (#549103 - closed) • Radamanthus Batnag • 18.5 • On track
- Container image virtual registry: upstream serv... (#549104 - closed) • Adie (she/her) • 18.4
- Container image virtual registry: handle file r... (#549134 - closed) • Adie (she/her) • 18.6
- Container image virtual registry: manage APIs (... (#548794 - closed) • Adie (she/her) • 18.5 • On track
-
Container image virtual registry: push/pull end... (#549131) • Radamanthus Batnag • 18.6
👈 - Container image virtual registry: performance r... (#549136) • Unassigned • Backlog
- Container image virtual registry: documentation... (#549138) • Adie (she/her) • 18.6
- Container image virtual registry: additional fe... (#549470) • Unassigned • Backlog
Edited by 🤖 GitLab Bot 🤖