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

How to map a subset of a registry using standard maps? #117

Open
jperville opened this issue Aug 14, 2024 · 0 comments
Open

How to map a subset of a registry using standard maps? #117

jperville opened this issue Aug 14, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@jperville
Copy link

jperville commented Aug 14, 2024

Hello @phenixblue ,

Thank you for writing this very useful mutating webhook, which I would like to use to implement deploying our company app in an airgapped cluster.

I am struggling to configure standard maps to swap multiple subpaths of the same registry into different registries.

What I expected:

I would like to configure the following maps like this:

default::
registry.gitlab.com/myorganization/clients::192.168.122.1:2000/myorg/apps
registry.gitlab.com/myorganization/platform/docker::192.168.122.1:2000/myorg/core

And to see the following results:

original image swapped image
registry.gitlab.com/myorganization/clients/myclient/apps/myclientapp:1.0 192.168.122.1:2000/myorg/apps/myclient/apps/myclientapp:1.0
registry.gitlab.com/myorganization/platform/docker/app-deployer/operator:1.0 192.168.122.1:2000/myorg/core/app-deployer/operator:1.0
registry.example.com/unrelated/image:1.0 registry.example.com/unrelated/image:1.0

Sadly, the current implementation does not recognise my maps and systematically returns the original image name (since it does not recognize the syntax for myregistry/subpath if subpath != library).

What I did next which was close but not good enough:

I tried the following configuration:

default::
[REPLACE]registry.gitlab.com/myorganization/clients/*::192.168.122.1:2000/myorg/apps
[REPLACE]registry.gitlab.com/myorganization/platform/docker/*::192.168.122.1:2000/myorg/core

This was almost what I wanted except that I lost the "relative path from the original prefix" information.
This resulted in conflicts in the swapped image names.

For example:

original image swapped image (incorrect)
registry.gitlab.com/myorganization/clients/myclient/apps/myclientapp:1.0 192.168.122.1:2000/myorg/apps/myclientapp:1.0
registry.gitlab.com/myorganization/clients/myotherclient/apps/myclientapp:1.0 192.168.122.1:2000/myorg/apps/myclientapp:1.0

Or worse:

original image swapped image (incorrect)
registry.gitlab.com/myorganization/clients/myclient/apps/myclientapp/api:1.0 192.168.122.1:2000/myorg/apps/api:1.0
registry.gitlab.com/myorganization/clients/myclient/apps/myotherclientapp/api:1.0 192.168.122.1:2000/myorg/apps/api:1.0

In both examples above, we have two different source docker images yet the swapped image is the same (collision).
I cannot afford collisions so I ended up with the 3rd configuration below.

What I end up trying (for now):

I ended up configuring the following maps:

default::
registry.gitlab.com::192.168.122.1:2000/myorg

This produces the following results:

original image swapped image
registry.gitlab.com/myorganization/clients/myclient/apps/myclientapp:1.0 192.168.122.1:2000/myorg/myorganization/clients/myclient/apps/myclientapp:1.0
registry.gitlab.com/myorganization/platform/docker/app-deployer/operator:1.0 192.168.122.1:2000/myorg/myorganization/platform/docker/app-deployer/operator:1.0
registry.example.com/unrelated/image:1.0 registry.example.com/unrelated/image:1.0

This technically works (the swap does not produce collisions) but I hate the extra long docker image paths.
I wish that I could get them shorter, as in my original proposal.

Would you accept some unit testing for your project, specially to test the different swapping algorithms?

Environment:

  • Kubernetes version (use kubectl version): v1.28.11
  • Cloud provider or hardware configuration: kubespray
  • Others:
@jperville jperville added the bug Something isn't working label Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant