Re:Show HN: Postgres Docker image with common extensions
by angelico on Monday September 06, 2021 @03:39AM
(#28431382)
Hi! I'm one of the contributors to the repo. Just to clarify, our Docker image [0] only contains the latest version of Postgres (13) and the common extensions listed out here [1]. All the other features such as this [2] and this [3] are only available in the AWS EC2 or DO droplet images. We're currently updating the README to make that clearer :-)
[0]: https://hub.docker.com/r/supabase/postgres
[1]: https://github.com/supabase/postgres#extensions
[2]: https://github.com/supabase/postgres#enhanced-security
[3]: https://github.com/supabase/postgres#additional-goodies
Re:Show HN: Postgres Docker image with common extensions
by frafra on Monday September 06, 2021 @03:56AM
(#28431478)
Hi! I have just seen the commit on README.md, thank you for clarifying that :)
The image runs postgres directly indeed, but in the entrypoint, and then keeps it open using tail -f /dev/null. That, together with Ansible, makes it pretty peculiar image :)
Re:Show HN: Postgres Docker image with common extensions
by sofixa on Monday September 06, 2021 @03:15AM
(#28431268)
When you run the "fat" container in an orchestrator that's less of a problem, because Kubernetes, and Nomad, can have as many health checks as you want to determine the health of all the things running inside.
But yes, generally it's not considered a good practice.
Re:Show HN: Postgres Docker image with common extensions
by debarshri on Monday September 06, 2021 @03:35AM
(#28431364)
I think it is problem. For eg. Let's say the healthcheck is on the main postgres process but the side processes crash, it will create a problem. You will have a container running in degraded status. So yes, It is very problematic. In practice, I have seen this kind of setup create lot of weird and unexpected behaviors.
Re:Show HN: Postgres Docker image with common extensions
by avereveard on Monday September 06, 2021 @07:32AM
(#28432673)
Health checks are better than just to rely on whether the process is running anyway
Wouldn't be better to run the same image with different commands or have one image for each service? Logs are usually written to stdout/stderr in containers, so they can be gathered, aggregated, stored etc. by Docker or Kubernetes and handled with the tools you like the most, without having to share log volumes across services and having multiple ways to handle and rotate logs to maintain.