Publishing image on other container registries about docker-images-php HOT 4 OPEN

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.

from docker-images-php.

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).

from docker-images-php.

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.

from docker-images-php.

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).

from docker-images-php.