Default container registry for Scaleway cluster

Hi, we are using Qovery managed Scaleway cluster and trying to deploy our applications as containers. We noticed that during startup all the images are being mirrored to default Scaleway registry, which takes much time and is inconvenient in our case. Is there a way to change that default container registry so we could avoid that mirroring step at all? We would like to use the same container registry in all our cluster and push images directly to it.

Hi @km1414,

As of today, it’s not possible to change the default container registry.

One possibility would be to push directly your images into your clusters registries, to skip the image mirroring (we have recently delivered it: Karpenter open beta, Label/Tags customization support, skip mirroring on same image registry, access to older application logs...)

1 Like

Ok, thanks. Can you provide some more details about how do we push images directly to cluster registry (in this case Scaleway)? Can’t easily find that in documentation.

When Qovery is running on your infrastructure, it requires an image registry to store the images built via the Qovery CI and to mirror the images deployed from a 3rd party container registry.

Hi @Melvin_Zottola, while there is a good case for image mirroring we are not deploying from 3rd party registries. Qovery is pushing images from one ECR to another which is useless in our case. Is there an option to disable image mirroring completely?

1 Like

@km1414,

I need to dig more & make a fix on our side to let you benefit of the “avoiding mirroring feature”. I tested on my side last friday and had some inconsistent behavior, due to some image format pattern on our side (specific for Scaleway).
I ping you once this is done

@prki,

Yes on AWS this is already available.

  1. Create a container registry on Qovery side with the URL pointing to your cluster registry, it must be of the form https://$ECR_HOST/$REPOSITORY_NAME , i.e https://123456789.dkr.ecr.eu-west-3.amazonaws.com/custom-nginx. As the image name is specified in the container registry URL, each different image name you’re using should have its own container registry on Qovery.
    You can find your cluster registry URL by looking at your deployment logs, we indicate in Deployment Status Report from where the image is pulled.

  2. Update each of your container / job to use this new container registry

  3. Redeploy them, you should see in the deployment logs this log line indicating no mirroring is done:

That’s great! Now we would like to disable image mirroring on Scaleway as well. We are using our own 1st party registry even if it’s on another cloud provider.

Today the only solution we can propose to disable image mirroring would be to push directly your images to the scaleway registry (Default container registry for Scaleway cluster - #2 by Melvin_Zottola)
Still WIP to have the same behavior as for AWS (Default container registry for Scaleway cluster - #5 by Melvin_Zottola)

@km1414, @prki

Skipping image mirroring is now available for Scaleway container registry as well.
In a similar way as for AWS, you need to:

  1. create a container registry pointing to your cluster registry, it must be of the form https://$SCW_HOST/$REPOSITORY_NAME. The URL host depends on your cluster region, i.e for a pl-waw cluster the host would be https://rg.pl-waw.scw.cloud/$REPOSITORY_NAME

  2. Update each of your container / job to use this new container registry.
    The image name on Qovery side should follow the pattern:$REPOSITORY_NAME/$IMAGE_NAME => with an image stored on Scaleway registry having this pull url rg.pl-waw.scw.cloud/repository/nginx the image name to indicate is repository/nginx:


  3. Redeploy them, you should see in the deployment logs that the mirroring has been skipped

Hello,
As per me to avoid this and streamline your workflow, you can configure your applications to use a preferred container registry consistently across your cluster. This approach allows you to push images directly to your chosen registry, eliminating the need for mirroring and optimizing deployment times effectively.