Switch away from Bitnami chart for PostgreSQL

[GaryGSC]

As announced a few days ago in Bitnami's pinned Issue and directly on the PostgreSQL chart's README, Bitnami's charts will break for anyone not paying Broadcom for use of container images hosted at the formerly-free location:

Q: How can I get continued support for Helm charts? A: If your deployed Helm chart is failing to pull images from docker.io/bitnami, to ensure continued support and access to security updates, we recommend subscribing to Bitnami Secure Images

This project currently supports the Bitnami charts ecosystem, but seeing as that now costs $5k/mo. for a minimum of 12 months, I no longer consider that a reasonable stance.

I wish I had a good alternative to suggest, but I don't see any at the moment.

[robbat2]

@GaryGSC Do you consider https://cloudnative-pg.io/ to be a good replacement?

[ChrisJBurns]

@robbat2 I don't think we'd want to offer up CloudNative PG either as it would complicate the installation process for backstage. In production systems, it's recommended to go with a more managed Postgres instance, the Postgres Helm Chart that comes with the Backstage Helm Chart was only really intended to be able to get people up to speed quickly in Kubernetes.

[ChrisJBurns]

CC'ing @vinzscam @tumido and @sabre1041 here incase they have solved the Bitnami issue in other OSS projects that use the Postgres Chart.

[tumido]

As far as I understand this, the change is about the container images located at docker.io/bitnami/* only and doesn't necessarily involve changes to the chart itself, correct? The bitnami/postgresql chart is solid, quality work and well done piece of code. I would prefer if we could keep it. I propose we just switch to using any other Postgres image.

There's plenty of alternatives available:

• Official PostgreSQL image, Alpine based: https://hub.docker.com/_/postgres
• Centos based one: https://quay.io/repository/sclorg/postgresql-15-c9s
• Fedora based one: https://quay.io/repository/fedora/postgresql-15 etc.

I don't expect that there should be a ton of necessary changes, all PostgreSQL container images should have pretty similar needs. I guess all that remains is that we (as a community) pick an image we would prefer to be the new default and migrate to it.

[ChrisJBurns]

@tumido Appreciate the input, I'm not learned on the recent Bitnami changes. I'll mark this thread as unread so I can come back to it and figure out an alternative image. I suppose there may be some devil in the details around the current deployments and what it would mean. I'll know more when I find some time to do some digging.

[tumido]

I suppose there may be some devil in the details around the current deployments and what it would mean.

That may be the case. However if I swap 1 image that runs PostgreSQL version X.Y by a different image running the same PostgreSQL version - I would assume zero breakage, if the database ends up mounted in the proper spot. 🙂

Another thing is that one can argue that the image was always configurable and the image we use as the default is nothing "certified" or "production grade" anyways. It's community best-effort image. That means - if somebody relies on specific images or certified builds or whatever, they've most likely already substituted the image by something else that they fully trust/control.

Another question is how much of a breaking change (and associated X release of the chart) this will be, if we "just" swap the image while maintaining the same PostgreSQL version. I don't expect it to break.

And yet another option for a workaround - we can always reupload the current PostgreSQL image somewhere else, or even "fork" the image. The Dockerfile is Apache licensed. However I would like to avoid this step if we can. It's unnecessary overhead. Though if the time schedule is tight and we need to have a different default image as an interim solution, I think this would be viable strategy.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.