Modernize `docker-compose.yml`

[jsma]

• Moved database connection parameters and other environment variables to an environment file
• Added a persistent volume for the database (should solve #207)
• Removed the version number from docker-compose.yml since this is ignored by docker and causes IDEs to attempt to validate
• Added health checks for containers to avoid warnings/errors (and removed "try again" notes from the readme)
• Updated docs to use exec instead of run since the containers should already be running
• Updated base images to latest stable versions (Python 3.12, PostgreSQL 16, and Redis 7)
• Added missing notes about update_index

This was backported from my work in https://github.com/wagtail/docker-wagtail-develop/pull/71

[jsma]

I did not touch the existing uwsgi bits, is there any reason to still have this around? It appears it's a leftover of "production" style configuration but the docker-compose setup is specifically documented as not being suitable for production. Can we remove uwsgi and get back to a basic manage.py runserver?

[gasman]

+1 for dropping the uwsgi setup. It's not entirely clear to me what the original motivation for it was, but judging from 6652c42d09e3f16ee6e7ced48b0043d73a740b2b it was done with some sort of Docker-based hosting platform in mind. I'm pretty sure we're not relying on that for any demo/nightly testing infrastructure - that's all on Heroku (right @RealOrangeOne?)

[jsma]

+1 for dropping the uwsgi setup. It's not entirely clear to me what the original motivation for it was, but judging from 6652c42 it was done with some sort of Docker-based hosting platform in mind. I'm pretty sure we're not relying on that for any demo/nightly testing infrastructure - that's all on Heroku (right @RealOrangeOne?)

It seems to me that the setup here should be strictly focused on spinning up the demo vs creating a development/debugging environment (that's what docker-wagtail-develop is for).

Looking at this a bit more closely, it looks like we could delete both production.txt and development.txt.

Vagrant only installs base.txt, while the virtualenv option instructs to install development.txt, and then of course the docker setup currently uses production.txt. (Confusingly, base.txt also includes django-debug-toolbar)

Only the docker setup needs psycopg3 and django-redis so I could see having a requirements/docker.txt to keep that separate from base.txt. So what I'm proposing is to only have base.txt (pruned of developer tools) and docker.txt in the requirements folder.

[RealOrangeOne]

We still need uWSGI, but correct we don't need the entrypoint. Heroku handles running migrations during deploy for us.

[jsma]

We still need uWSGI, but correct we don't need the entrypoint. Heroku handles running migrations during deploy for us.

Ah, so there is an undocumented heroku path that relies on production.txt and related settings then? I can leave that untouched, but how does that intersect with the docker install instructions? I thought the primary purpose of this project was for folks to easily spin up a demo so they can check out wagtail's features etc. And of course it is also useful for spinning up a vanilla wagtail project to create a simplified test scenario when debugging or contributing to wagtail. I was not aware of a scenario where folks would want to deploy this in a production environment.

Can we keep things simple for the "I just want to quickly demo wagtail on my machine" and have this more or less be the same whether they are doing this via the virtualenv, vagrant, or docker paths? Perhaps a "if you need to deploy this in a production-like environment to showcase to a distributed team over the web, follow these steps" addition to the documentation with a separate compose-production.yaml?