CircleCI-Public / cimg-postgres

MIT License
8 stars 24 forks source link

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

Closed stig closed 1 year ago

stig commented 1 year ago

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

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!

JalexChen commented 1 year ago

@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 commented 1 year ago

@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.