Closed EdmondFrank closed 2 years ago
Hi @EdmondFrank, thanks for your contribution to pg_auto_failover!
Maybe the base image can also use the ARG parameter to avoid installing all the pg versions.
I though that using the same base image for all the Postgres major versions would be an overall win, because there is then a single image to build and maintain and we share it later. You seem to think that specialising at this level is a win despite having to now generate 5 different images. Can you expand on your thinking here?
(I'm sure I'm missing the overall picture, and I would like to get it thanks to your work here, that's a good opportunity)
Hi @EdmondFrank, thanks for your contribution to pg_auto_failover!
Maybe the base image can also use the ARG parameter to avoid installing all the pg versions.
I though that using the same base image for all the Postgres major versions would be an overall win, because there is then a single image to build and maintain and we share it later. You seem to think that specialising at this level is a win despite having to now generate 5 different images. Can you expand on your thinking here?
(I'm sure I'm missing the overall picture, and I would like to get it thanks to your work here, that's a good opportunity)
Thanks @DimCitus reply. In my opinion, specifying Postgres major version with ARG first can speed up the first build, and avoid changing the dockerfile when a new Postgres major version needs to be supported.
And I don't think it is very practical to integrate all versions of a base image. When a new version is added, the entire base image still needs to be rebuilt. But if each base image is independent, adding a new version can still reuse the old built image.
(I'm not sure if my opinion is correct, maybe it's a one-sided consideration).
Maybe the base image can also use the ARG parameter to avoid installing all the pg versions.