Purge build deps to shrink the 12.15 image from 2.47 GB to 1.76 GB

[stig]

For our official CircleCI Docker Convenience Image support policy, please see CircleCI docs.

This policy outlines the release, update, and deprecation policy for CircleCI Docker Convenience Images.

---

Description

Purge build deps to shrink image from 2.42 GB to 1.76 GB

The space savings are for the 12.15 image, built locally with this commit compared with the latest published version.

Combine the pg and pg_cron layers to avoid installing & purging build-depends several times.

Gosu is used in entrypoint, so it is not purged.
locales is required by Pg at runtime, so it is not purged.

~/src/cimg-postgres $ docker image ls | awk 'NR==1 || /12.15/'
REPOSITORY           TAG               IMAGE ID       CREATED         SIZE
stigbra/postgres     12.15             635b39e20ee4   11 hours ago    1.76GB
stigbra/postgres     12.15-before      e80aef4f7f05   6 hours ago     2.47GB
cimg/postgres        12.15             2ddb6adf99f3   5 weeks ago     2.42GB

• cimg/postgres is the most recently published that I pulled down from Docker Hub.
• 12.15-before is an image I built from the commit immediately before the one I'm adding here
• 12.15 is with this commit

Reasons

I want to shrink the postgresql image sizes. This should improve spin-up time a little, especially if the image is not in the local Docker Layer Cache. It also helps for local development.

I achieved the space savings by installing & purging build-time dependencies in the postgres and pg_cron installation steps.

Checklist

Please check through the following before opening your PR. Thank you!

• I have made changes to the Dockerfile.template file only
• I have not made any manual changes to automatically generated files
• My PR follows best practices as described in the contributing guidelines
• (Optional, but recommended) My commits are signed

[JalexChen]

@stig - ideally, we would probably want to have build deps installed and removed in one layer. were the space savings for that ever tested? if these are not being changed all that much, maybe it makes more sense to keep the extensions we include in this postgres parent/base image in one layer, especially if it ultimately does not change much

[stig]

@stig - ideally, we would probably want to have build deps installed and removed in one layer. were the space savings for that ever tested? if these are not being changed all that much, maybe it makes more sense to keep the extensions we include in this postgres parent/base image in one layer, especially if it ultimately does not change much

I didn't test that, though I'm happy to give that a go! The main annoyance is that it takes ages to test any new additions, since building postgres is not quick.