Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sync to multiple registries #1785

Open
jduepmeier opened this issue Oct 20, 2022 · 4 comments
Open

sync to multiple registries #1785

jduepmeier opened this issue Oct 20, 2022 · 4 comments
Labels
kind/feature A request for, or a PR adding, new functionality stale-issue

Comments

@jduepmeier
Copy link

I like to sync images from various registries to multiple other registries.

Today I use the skopeo sync command with a yaml file for the source but I must use different calls to sync the images to the different target registries.
The problem here is that the images must be pulled several times.

It would be nice to define the target registries in a yaml file like the one for the source registries.
Then the command can fetch the images once.

I thought about storing the images first in a directory but this means i need more local disk space.

@mtrmac
Copy link
Collaborator

mtrmac commented Oct 20, 2022

Thanks for reaching out.

Well, that’s an ~unavoidable trade-off: Currently skopeo sync is streaming copies, i.e. it does not require any disk space, but then two copies from the same source to different destinations read from the source twice.

Alternatively, it could copy from source to disk once, and once from disk to each of the destinations.


I can just imagine a streaming implementation that reads from the source once, and pushes data to both destinations simultaneously (at the speed of the slower one) — but that would be very different copy implementation than the one we use now. It could plausibly be built, using an indirection ImageDestination that collects multiple actual destinations and distributes every write to them…

It’s not something that exists and it feels a bit tricky to make that reliable. I’m a bit doubtful that this fairly unusual case warrants that effort and risk — it’s worth tracking at least.

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@mtrmac mtrmac added the kind/feature A request for, or a PR adding, new functionality label Dec 7, 2022
@github-actions
Copy link

github-actions bot commented Jan 8, 2023

A friendly reminder that this issue had no activity for 30 days.

Copy link

A friendly reminder that this issue had no activity for 30 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A request for, or a PR adding, new functionality stale-issue
Projects
None yet
Development

No branches or pull requests

2 participants