search

devcontainers / templates

Repository for Dev Container Templates that are managed by Dev Container spec maintainers. See https://github.com/devcontainers/template-starter to create your own!
https://containers.dev/templates
MIT License
859 stars 226 forks source link

Pin PostgreSQL version in `*-postgres` templates #227

Open Birdie0 opened 6 months ago

Birdie0 commented 6 months ago

*-postgres templates (ex. ruby-rails-postgres) use postgres:latest image which isn't the best default by 2 reasons:

  1. Using latest tag will cause problems in a case we rebuild container after release of new major version of PostgreSQL, as data generated by different major versions are not compatible and require using dumps, cluster upgrades, etc., simply saying container won't start unless we pin to numbered tag that matches previous major version.
  2. Images that have tags without suffix, like latest or 16, are Debian-based which means it's almost twice bigger than Alpine-based (425MB vs 243MB), in most cases using Alpine-flavored image should suffice.

I suggest switching to numbered tags with -alpine suffix as and it's smaller and would make it more future-safe. Not sure if it's possible, can PostgreSQL version be entered by user in the same way as imageVariant during initialization?

eljog commented 6 months ago

Thank you for creating the issue and explaining the drawbacks of defaulting to the latest tag for postgres image.

The suggestion to allow users to override the tag (similar to imageVarient) makes sense. But we still need to have a default. I am afraid if a tag like 16-alpine can be the new default instead of latest, since that will hard pin the image and would never receive newer major versions unless we manually modify the template. Any thoughts around that?

Birdie0 commented 6 months ago

I think it would be good default, at least a better one. In perspective, pinned version in template would need to be updated every year around September/October when new major version is being released to match. Pinned version also simplifies upgrading to latest minor version by rebuild (not sure if pull is set to always during them, docker pull postgres:16-alpine can be run previously to be safe). Similarly if developer would need new version to utilize newly added features or simply upgrade it with persisting data still stays manual but more controllable.