dockerhub rate limiting

[kcawley]

We are currently using quay.io to handle docker containers built off of rocker/r-ver:3.6.0 (our container requires the libgfortran3 library or we would have updated to >4.0). We're running into an issue with the docker hub pull rate limits that started at the end of November. I see a (defunct?) repository on quay.io called rocker (https://quay.io/repository/rocker/r-ver). Is this associated with the group that maintains this GitHub repository? If so, it would be a huge help to us to get a successful build that we could use on quay.io and circumvent the rate limits. Or should we find a different solution since the quay.io repo won't be updated? Thanks!

[cboettig]

@kcawley thanks for the ping. Not sure the origins there, don't believe that's us (though it does seem to be responding to git triggers from our repos? We have explored a few different platform integrations since 2012 and the docker universe has seen mergers and acquisitions since then, looks like quay may be connected to (now defunct?) CoreOS project which we used a bit in the early days?

Thanks for the heads up about encountering rate-limiting issues on the new Docker Hub policy. Happy to explore options more seriously if that's a common problem. If anyone has suggestions on this (co-devs or community) I'm happy to discuss, but seems good to avoid fragmentation.

@yuvipanda does your team hit these rate-limits or do you have a workaround or another platform to pull your images from?

[yuvipanda]

Thanks for the heads up about encountering rate-limiting issues on the new Docker Hub policy. Happy to explore options more seriously if that's a common problem. If anyone has suggestions on this (co-devs or community) I'm happy to discuss, but seems good to avoid fragmentation.

Yeah, it's going to become a serious problem soon enough. On GKE and similar, there's an automatic cached mirror so that helps. But everyone else is going to constantly run into issues.

Soon, docker is going to delete images that haven't been used in a while. This will definitely affect a lot of the 'reproducibility' argument for using images.

I'd recommend starting to use another public registry (such as quay.io from RedHat / IBM, AWS's free public registry at https://aws.amazon.com/blogs/aws/amazon-ecr-public-a-new-public-container-registry/, or https://docs.github.com/en/free-pro-team@latest/packages/getting-started-with-github-container-registry/about-github-container-registry). It would also be nice to mirror all current tagged docker image versions to whatever you pick. There's tooling that makes this easy.

My preference is to use quay.io, since that's not controlled by the biggest players in this space now (AWS / Microsoft). However, probably not a bad idea to push to them all.

[eitsupi]

Are you still considering pushing to multiple registries?
In the rocke-versioned2 repository, tags are controlled by docker-bake.json, so in order to push to multiple registries, simply add tags like ghcr.io/rocker-org/r-ver:4.1.1 (automatically generated by the script and written to the bake files) and just change to log in to multiple registries at the same time on GitHub Actions. Like that.
https://github.com/docker/build-push-action/blob/master/docs/advanced/push-multi-registries.md

If we push to multiple repositories, the image will have multiple digests, but since we currently have a reporting system, we can see the digests on other repositories no matter which repository we pull from.
https://github.com/rocker-org/rocker-versioned2/wiki/cuda_a7e41d4adb6f

The easiest is GHCR(ghcr.io), which does not require an additional account.
Other options are listed here.
https://github.com/docker/login-action#usage