You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would first like to say that I am new to the open source community. I would like to see if I can help tackle this if it seems like a project you're willing to add as it sounds like a fun project to get more familiar with Go and making contributions. Please let me know if there is already a fix for this or an option I may be missing in the documentation.
My team has recently started using Skopeo. It works great for pulling large numbers of images and staging them for "airgapped" image registries. We use the scoped option when syncing images to local device or proxy registry for scanning images, but the output seems like it's missing an option to abstract the registry from the directory structure. Adding an option to abstract the repository from the output could offer more capabilities in regards to Skopeo being used in various automation frameworks to pull images from public registries and push to private registries.
UNSCOPED:
When the --scoped flag is NOT set: (skopeo sync --src yaml --dest dir), the following directory structure is created:
.
└── image:tag
└── image:tag
└── image:tag
This is not ideal when pushing images to a private registry as they are no longer separated into projects and the default image in the resource manifests will need to be changed.
SCOPED:
When the --scoped flag is added to sync images: (skopeo sync --scoped --src yaml --dest dir), the following directory structure is built:
The problem with this is that now I need to move into the registry directories and run a sync from each in order to push all projects to the private registry.
Currently we are moving projects out of the registry directories in a single directory so all projects may be pushed at once.
Staying in the current directory and running a sync will result in the following push to the private registry:
https://private.io/docker.io/project/image:tag
When I would like it to be:
https://private.io/project/image:tag
This process unecessarily complicates pipelines which stage images to be moved to an airgapped environment to be moved to storage used by the automation tools or a private registry.
FIX/FEATURE REQUEST
What I would like to see is an option to use the --scoped option with an additional flag --abstract-registry with an output like this:
This would also introduce a capability to sync from a source yaml and push directly to a private registry destination docker with a single command: skopeo sync --scoped --abstract-repo --src yaml --dest docker sync.yaml https://private.io
I believe this feature would keep the projects associated with images in tact in order to not have to change manifests between environments and helping make the resources more portable.
This is a problem I see fairly often in on-prem kubernetes clusters using their own private registries. There seems to be a similar issue relating to this in issue 854 opened in 2020, but it appears there was some confusion on what the intent might be for this option. The issue says it was fixed in issue 870 but I don't see any changes for what I previously described implemented. Please correct me if I'm wrong.
We shouldn’t keep adding individual mapping options; that would never end. Instead, let the user just specify source/destination repo pairs explicitly.
The current yaml format doesn’t allow that, so we need a new one.
#1531 (comment) is one very rough sketch of what that might look like, and #1792 a start of an implementation effort.
I’m afraid this is not something I can promise to spend a lot of time on short-term.
I would first like to say that I am new to the open source community. I would like to see if I can help tackle this if it seems like a project you're willing to add as it sounds like a fun project to get more familiar with Go and making contributions. Please let me know if there is already a fix for this or an option I may be missing in the documentation.
My team has recently started using Skopeo. It works great for pulling large numbers of images and staging them for "airgapped" image registries. We use the
scoped
option when syncing images to local device or proxy registry for scanning images, but the output seems like it's missing an option to abstract the registry from the directory structure. Adding an option to abstract the repository from the output could offer more capabilities in regards to Skopeo being used in various automation frameworks to pull images from public registries and push to private registries.UNSCOPED:
When the
--scoped
flag is NOT set: (skopeo sync --src yaml --dest dir
), the following directory structure is created:. └── image:tag └── image:tag └── image:tag
This is not ideal when pushing images to a private registry as they are no longer separated into projects and the default image in the resource manifests will need to be changed.
SCOPED:
When the
--scoped
flag is added to sync images: (skopeo sync --scoped --src yaml --dest dir
), the following directory structure is built:. ├── docker.io │ ├── project1 │ │ └── image:tag │ └── project2 │ └── image:tag └── quay.io └── project3 └── image:tag
The problem with this is that now I need to move into the registry directories and run a sync from each in order to push all projects to the private registry.
Staying in the current directory and running a sync will result in the following push to the private registry:
When I would like it to be:
This process unecessarily complicates pipelines which stage images to be moved to an airgapped environment to be moved to storage used by the automation tools or a private registry.
FIX/FEATURE REQUEST
What I would like to see is an option to use the
--scoped
option with an additional flag--abstract-registry
with an output like this:This would also introduce a capability to sync from a source
yaml
and push directly to a private registry destinationdocker
with a single command:skopeo sync --scoped --abstract-repo --src yaml --dest docker sync.yaml https://private.io
This is a problem I see fairly often in on-prem kubernetes clusters using their own private registries. There seems to be a similar issue relating to this in issue 854 opened in 2020, but it appears there was some confusion on what the intent might be for this option. The issue says it was fixed in issue 870 but I don't see any changes for what I previously described implemented. Please correct me if I'm wrong.
EXAMPLE USE CASE:
EXAMPLE
sync.yaml
The text was updated successfully, but these errors were encountered: