rchincha
commented
3 months ago As long as the upstream registry is OCI conformant (at least for pulls), the number of levels don't really matter.
zot's sync/mirror functionality is inspired by and based on git clone behavior.
For example,
1. Upstream -> mirror1
2. Upstream -> mirror1 -> mirror2
3. Upstream -> mirror1 -> mirror2
-> mirror3 /etc ...
Is your feature request related to a problem? Please describe.
In my scenario I have a few kubernetes clusters in various separate AWS accounts in separate regions, with some region overlap between the AWS accounts and some accounts having more than one cluster in each region. All clusters use the same upstream private registry for container images.
In order to reduce traffic to the private registry, we have configured a caching-only mirror in each kubernetes cluster using Zot. However, we would like to do a second "tier" of proxying by placing an additional proxy in the AWS account outside the clusters, with the aim of having this new tier being between the private registry and the clusters. We're looking to use either Zot or ECR to perform this additional role. If we use Zot for both, that might simplify things further.
The documentation shows how we can configure Zot inside each cluster to pull from an upstream registry, which is working well when pulling directly from the "original" upstream registry. However it isn't clear what configuration is needed when the upstream registry is itself also a mirror.
Describe the solution you'd like
Given the scenario of a pull-through mirror cache being available, I'd like to be able to use Zot for a second tier of caching, where it pulls the images from the first mirror. I suspect this is already possible - but it is not clear how to do so.
Describe alternatives you've considered
No response
Additional context
No response