Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

postgres and redis container images anywhere but dockerhub #715

Open
BonzTM opened this issue May 29, 2022 · 7 comments
Open

postgres and redis container images anywhere but dockerhub #715

BonzTM opened this issue May 29, 2022 · 7 comments

Comments

@BonzTM
Copy link

BonzTM commented May 29, 2022

Hello,
Is it possible to pull or mirror the centos postgres and redis images anywhere but dockerhub? Perhaps mirrored on Quay?

I've deployed Quay into my cluster as a local mirror of many different repos. It functions well as a workaround for dockerhub api rate limiting, until Quay itself fails to come up due to dockerhub rate limiting.

@flavianmissi
Copy link
Contributor

Hi @BonzTM, maybe this helps? https://docs.projectquay.io/deploy_quay_on_openshift_op_tng.html#operator-customize-images

@BonzTM
Copy link
Author

BonzTM commented Jun 2, 2022

Hi @BonzTM, maybe this helps? https://docs.projectquay.io/deploy_quay_on_openshift_op_tng.html#operator-customize-images

Hello,
This does help, however it is noted: Using this mechanism is not supported for production Quay environments and is strongly encouraged only for development/testing purposes. There is no guarantee your deployment will work correctly when using non-default images with the Quay Operator.

I do not wish for my production Quay instance to be subject to failure if I mis-type a tag, or fail to upgrade one of the container images with a Quay upgrade. If the default postgres and redis were hosted in a container registry that did not impose very low rate limitations, that would be ideal.

@dmesser
Copy link
Contributor

dmesser commented Jun 21, 2022

If you are running on OpenShift, you can use ImageContentSourcePolicy to redirect those image pulls for redis and postgres to your own mirror of those images.

@BonzTM
Copy link
Author

BonzTM commented Jun 21, 2022

If you are running on OpenShift, you can use ImageContentSourcePolicy to redirect those image pulls for redis and postgres to your own mirror of those images.

Thanks Dan,
I have done this as a workaround with the overrides and locally mirrored ImageStreams for now. I am running OKD at home. I will keep on top of the images as the Quay operator advances in version and handle this each time if necessary.

While I think the best solution is to host the centos-redis and centos-postgres images on a different mirror to rid ourselves of the requirements of DockerHub for this operator; if this workaround is the official solution, consider my complaints resolved.

@dmesser
Copy link
Contributor

dmesser commented Jun 21, 2022

The operator is packaged following a philosophy from the OpenShift Container Platform, which is to:

  • hard code container image references and not get those from external configuration
  • refer to the image references via digests

Both concepts allow to reason about the content you are getting and that the component is pulling at runtime, although it makes it a little harder to get the images from somewhere else.

@BonzTM
Copy link
Author

BonzTM commented Jun 23, 2022

The operator is packaged following a philosophy from the OpenShift Container Platform, which is to:

  • hard code container image references and not get those from external configuration
  • refer to the image references via digests

Both concepts allow to reason about the content you are getting and that the component is pulling at runtime, although it makes it a little harder to get the images from somewhere else.

Dan,
Postgres v10 (and newer) and Redis (v5) are hosted on Quay.io already. Is there a reason to not use those and continue pulling from dockerhub?

https://quay.io/repository/centos7/postgresql-10-centos7
https://quay.io/repository/centos7/redis-5-centos7

@dmesser
Copy link
Contributor

dmesser commented Jun 23, 2022

We could certainly look into that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants