Fork - Consider Replacing HashiCorp Container Mirror

[cipherboy]

The Docker container registry has put steep rate limits in place, so upstream uses a caching registry mirror. I think this is partly because the CI tests refresh the image every time they run. We likely can't add new containers, as the list isn't in a public repository.

We should decide if we're keeping the mirror, if we're replacing it, or if we're just removing it without replacement.

[joewxboy]

Is this need specifically for a registry for the CI/CD process, or would it also include public released container assets?

I'm in the process of applying for our DockerHub account to be recognized as an open source project to remove rate limits, but I don't know if that would apply to the specific case your mention, @cipherboy . For the CI/CD process, do we want to consider using GitHub-based tools, including their registry?

[cipherboy]

@joewxboy This is for CI/CD and local testing of third-party integrations, not (just) for pulling our own images we publish. I don't think open source classification was sufficient as I'd occasionally run into this locally when testing larger changes. Even things like Postgres were hitting the limits for me, which I imagine has to have an OSS account... I suspect it was traffic source IP rate limiting, to encourage organizations (with office presence) to pay for the service (or run mirrors).

Container caching on GitHub, yes, would help this, but we might also need to consider a local cache in that case too.