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 Add docker-compose volumne #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 wagtail/docker-wagtail-develop#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]

.env is not just used for the Docker setup - if we make this change, it's going to break the virtualenv setup instructions, since we've not told people to set up a Postgres database there (and, of course, we'd rather not make that a requirement). Maybe there should be a separate .env.docker.example?

[jsma]

Ah good call, my brain is full of docker at the moment and lost site of the other install options. FYI, I'm wrapping up much more extensive docker compose "modernization" work over in wagtail/docker-wagtail-develop#71 which I'll backport here once complete.

[gasman]

+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?)

[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]

Question: Why are we removing the default settings?

[jsma]

I moved DJANGO_SETTINGS_MODULE to .env/.env.example (although it points to the dev settings in this PR). DJANGO_DEBUG was not used anywhere.

[RealOrangeOne]

I think we should still keep the production default in the Dockerfile.

[jsma]

If there are undocumented use cases that require production-like settings and packages, could that be addressed by someone else who is aware of these scenarios in a separate PR? I can only work from the documented use cases in the readme, which has this to say about the docker compose setup:

bakerydemo/readme.md

Line 112 in cd09104

**Important:** This `docker-compose.yml` is configured for local testing only, and is _not_ intended for production use.

The readme.md makes it sound like all paths for starting the demo are equivalent and only a matter of preference, but per my previous comment:

• Gitpod installs requirements.txt which is essentially just an alias for requirements/production.txt
• Vagrant installs requirements/base.txt
• Docker Compose installs requirements/production.txt
• Virtualenv installs requirements/development.txt

Either the readme needs some reworking or the configurations should be consistent with each other and with the readme. The simplest starting point for demo purposes is to install base.txt (and perhaps an extra file for docker to install the redis/psycopg3 libs).

For anyone who wishes to submit a PR to bakerydemo, they'll need to install development.txt (removing the -r base.txt from that file) in a virtualenv on their host so that they can run ruff etc. on their changes before submitting a PR (the contributing docs needs a note about installing pre-commit).

[RealOrangeOne]

Nit: || exit 1 should be a noop

[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?