Skip to content

Container image virtual registry: upstream services

🗒️ Goal

Create the service that will check with upstreams if a relative path exists or not.

In the virtual registry, upstreams logic, we don't really walk the ordered list. Instead, we chunk it to the call upstreams in parallel. We do so using the typhoeus gem (the hydra part).

This issue is to implement a similar service but for container images. Accessing container registries is a bit more complex than just presenting a token. The authentication flow is based on getting a temporary token (or better said registry bearer token). See &6061 (comment 2558409831).

Here are the needs:

  • We need a service that mimics this one.
  • For the authentication part, focus on support long lived tokens for layer 1. See &6061 (comment 2558409831).
    • This part should be embedded in the upstream model so that the check upstreams service doesn't need to know about all the authentication details.
  • If valuable, cache temporary tokens. Checking an upstream multiple times should lead to get the registry token only once. A redis cache could be useful here.
  • Make sure that the most important aspect of the service is followed: upstreams are in an ordered list. Thus, returning which upstreams has the requested file means that all the previous upstreams were either down or answered an unsuccessful response.
  • This being a low lever service, user permissions don't need to be checked. They will be in the parent service.

🔮 Other considerations

Take this opportunity to centralize the logic, functions or aspects with the Maven virtual registry objects.

🛠️ Implementation plan

Edited by 🤖 GitLab Bot 🤖