Provide images at a non-rate limited repo such as quay.io

[brokenjacobs]

With the recent docker hub rate limiting, it would be very handy to build an 'official' alpine base image on another repository without rate limiting, such as quay.io.

Docker does not provide a path to pay for docker hub in a way that it can be used from quay.io builds, or builds on other registry services. Until that happens, the base image for alpine on docker hub cannot be used to build new images on services such as quay.io, as you will get rate limited randomly when pushing.

[tianon]

FWIW, quay.io has a rate limit also: https://docs.quay.io/issues/429.html

(It has for a long time, IIRC)

[brokenjacobs]

interesting. so "Less rate limited" in the title might be more appropriate?

[westwind-sc]

We just need one of the maintainers to fill in https://www.docker.com/community/open-source/application. Then docker hub will not apply the rate limiting on the image.

[ncopa]

I think that filling in the open-source application will increase the rate limit for the alpine org itself? not for other users using the alpine image?

[westwind-sc]

https://www.docker.com/blog/what-you-need-to-know-about-upcoming-docker-hub-rate-limiting/

And non-commercial open source projects can apply for a sponsored Open Source Docker account by filling out this application. No pull rate restrictions will be applied to namespaces approved as non-commercial Open Source projects.

[saurabhladhe]

would be great to have this resolved soon, its causing airflow kubernetespodoperator to fail when creating a sidecar https://github.com/PolideaInternal/airflow/blob/97e18a76bf28667a8d8673ce52ade7b1fb674b0b/airflow/kubernetes/pod_generator.py#L48

[westwind-sc]

How about provide images via ghcr.io ? Some softwares already start provide official images via ghcr.io, for example: https://github.com/orgs/aquasecurity/packages/container/package/trivy

[Drugoy]

Please, consider at least just having more than 1 registry used for official images due to docker pushing logic about how it treats it's own registries to the docker code and it causes problems.

One example of such problems is having corp.proxy that intercepts requests and re-signs them with own certs.

A simple solution in this case and, say, quay.io is adding quay.io to the list of insecure-registries in /etc/docker/daemon.json

The same won't work with official docker registries (even if you list them all (registry.docker.io, registry-1.docker.io, auth.docker.io) and it's hard to even find the list of official docker registries, because in the docs all the examples omit hostname, as it is assumed to be official registry in that case.

[joebowbeer]

There are several alpine images published to AWS ECR Public Gallery but none that are clearly official.

public.ecr.aws/micahhausler/alpine:3.13.5

[jaecktec]

there is for example an ubuntu on aws, which is really nice. Would be nice to see alpine as well :)

[thielepaul]

as a workaround, one can use the google mirror: mirror.gcr.io/library/alpine

[Nitive]

There is no guarantee that image will be available at mirror.gcr.io/library/alpine because it's not exactly a mirror but rather a cache proxy

[adamhgriffith-uofu]

Docker is sunsetting Free Team organizations in April (FAQ). With that in mind, are there any plans to add Quay.io as a second registry in the near future?

[tianon]

The image maintained at https://hub.docker.com/_/alpine is not on a "Free Team" account, and thus is not affected by that.

Additionally, in the interim since this issue was first opened, all the Docker Official Images have been officially mirrored to ECR Public (see https://gallery.ecr.aws/docker -> https://gallery.ecr.aws/docker/library/alpine).