[FR] Rethink container images used in `docker-compose.yml`

[jtru]

Please describe the problem / need you are trying to solve. The repo's docker-compose.yml makes very specific (and at this time, very outdated) choices in terms of which container image versions to deploy in a "production" taiga installation.

For instance, nginx is pinned to the 1.19 image, while the current nginx "stable" (this is the conservative choice with little feature development and basically only security updates) release is at 1.24. The version in with taiga's socker-compose stack use was a "feature" branch/release back in the day, first announced on 2020-05-26. It hasn't had proper security support for many, many moons.

PostgreSQL is pinned to 12.3, which was released by the Postgres development community on 2020-05-14. The very latest PostgreSQL release from major version 12 is 12.17.

I've used both projects extensively for more than a decade by now, and know that their track record concerning backwards compatibility is solid enough to not make this practice required or even recommendable - you miss out on a lot of (potentially) critical bug fixes by not depending on a more flexible, recent image tag.

Describe the feature or the improvement you'd like and what are you trying to achieve.

• The taiga-gateway image should refer to the nginx:stable-alpine image tag.
• The taiga-db image should refer to the postgres:12 image tag (if the Debian version the image is based on matters, which it probably does (unless the images use ICU locale data), which would require using 12-bullseye or 12-bookworm, respectively). A postgresql major version upgrade will be required soonsince 12 is on the way out of upstream support. This will have to handle the use of pg_upgrade for existing, on-disk data. (I am not sure if the container images published by Postgres handle this themselves.)
• The taiga-async-rabbitmq image should MAYBE (I am not familiar with rabbitmq) refer to a more recent image tag, too.

Implementing the first two changes will make taiga deployments more featureful, less prone to bugs, and more secure by any measure.

It might be a good idea to check the content of taiga-specific images for up-to-date dependencies, too.

[jtru]

FWIW, I tried creating a new installation today with the following images used in docker-compose.yml, and observed no problems during (superficial) testing:

• taiga-db: postgres:12-bookworm
• taiga-gateway: nginx:stable-alpine

Please not that taiga-db cannot switch between a -bookworm and any other (such as -bullseye) image without its database being reindexed due to Postgres' reliance on libc-provided locale data/collation ordering. So for existing taiga installations, this would have to at least be clearly documented, if it cannot be feasibly resolved automatically.

taiga-gateway, however, could be painlessly and effortlessly switched to the new(er) image right away, no matter if it's a greenfield or existing deployment.

I also noticed that the container image used for providing rabbitmq-related services logs the following early during init:

WARNING: '/var/lib/rabbitmq/.erlang.cookie' was populated from '$RABBITMQ_ERLANG_COOKIE', which will no longer happen in 3.9 and later! (https://github.com/docker-library/rabbitmq/pull/424) WARNING: 'docker-entrypoint.sh' generated/modified the RabbitMQ configuration file, which will no longer happen in 3.9 and later! (https://github.com/docker-library/rabbitmq/pull/424)

... which suggests some more work would have to be done there to get a newer image release going for taiga-async-rabbitmq.