Publishing image on other container registries

[surrealchemist]

Since docker now rate limits pulls from their registry, it would be helpful to have other sources the image is published to

Expected Behavior

I would like to be able to have the container image available somewhere other than the official docker registry.

Current Behavior

The image is only available directly from docker and they will rate limit you if you use it too much.

Possible Solution

Publish the same image to other registries such as quay.io managed by Redhat, or ECR public registry for use in AWS https://gallery.ecr.aws

Context

I currently have a container set up with a pipeline via aws copilot that builds and pushes to ECS. After being rate limited the pipeline fails so we can't update our application via git push, blocking development.

[surrealchemist]

I think another solution would be to get the repository marked with one of the categories that excludes it from rate limiting:

Docker Official Image
Verified Publisher
Sponsored OSS

I don't know the process to become a verified publisher, if that is an option.

[mistraloz]

Hello @surrealchemist. There is also ghcr.io (registry of github) as we doing for https://github.com/thecodingmachine/docker-images-nodejs/pkgs/container/nodejs

But we use lot of versions, and add a new registry will require lot of addition data transfer. So we should be reasonable and identify the right way to manage it. In addition 100 pulls per 6 hours is a lot (maybe an issue in your ci/cd process ? Why you do not use a cache registry in your own infra ?).

BTW, the option to become a sponsored OSS partner of dockerhub is a good option. We can evaluate it at the end of this year. And if you want to adjust the CI/CD to publish a version inside ghcr.io, you can. Or if as a workaround you want to create a sync registry in quay.io or aws, you can too (just, to not use "thecodingmachine" name, use your own instead).

[surrealchemist]

Thanks for your response.
I'll have to see. It was puzzling to me how we even hit it honestly, because we did not to a lot of commits. I was thinking maybe these aws code pipeline runners are on shared IP resources. Most of our images I have switched over to other sources just to eliminate the chance of it happening.

It might be more worthwhile to dedicate some cycles to creating my own custom image from scratch for our Moodle needs. I was pointed to this image after I was told the official Moodle one was not created for production use. The Bitnami one also does a bunch of bootstrapping which I don't want. Seems like this app has way too many different ways of configuring it so the images tend to install a bunch of features we will never use.

[mistraloz]

True, from AWS instance, you use shared ips (but we use AWS too in our own CI/CD without issue - as i now).
About images weight, I'm working on a new image v5 based onto official image php with alpine variant. I don't know yet when it's will be available for production use (probably end for this year).

If you prefer to use your own image, you can use https://github.com/mlocati/docker-php-extension-installer (excellent way to manage lot of extensions). Our own images will manage some additionnal features per example to allowing auto config for php.ini, integration with apache, node, supercronic, ... And in V5 we will add php fpm (+apache in the same container) and change ours recommandations to advice usage of the slim version by default (the fat one should be used only for local dev or lazy deployment : in regular process we should build from slim one to have a light and efficient image).