* Update Dockerfile for Debian Bullseye release
The previously used base image `python:3.7` was changed to now use
Debian Bullseye. This lead to installation issues of `libenchant-dev`
(see #31).
This is now fixed by upgrading the installation command for `libenchant`
to `libenchant-2-dev` (see also https://pkgs.org/search/?q=LIBENCHANT).
Additionally, to avoid similar issues in the future, the Debian version
of the base image is now defined in the `Dockerfile`.
* Upgrade Python base image from 3.7 to 3.8
Automatic container restarts are not necessary in a development context.
Also, working on multiple projects with these settings only leads to
an extreme load on the dev machine, because all the containers from
all the projects are starting when the Docker engine is started.
* Update the README with instructions on getting bakerydemo to use the PostgreSQL database from the adjacent container
* Corrected formatting in README
* Automated setting up bakerydemo to use the postgres service from our docker-compose
* Broke out the initial database stuff into a separate one-time script.
Also enhanced the .dockerignore file to make image builds a lot faster, and added .idea to the .gitignire, so that PyCharm projects won't get added to the repo.
* Reworked the database and Wagtail installation setup
In order to improve the development experience while using docker-wagtail-develop, I reorganized how the database setup is done, and how and when Wagtail gets installed into the python environment inside the docker container. Plus a few other changes.
1. Database. The migration and initial data load steps are now done once, by the user, during initial setup (setup-sb.sh), rather than happening at the start of every `docker-compose up`. This is possible because the postgres data is already being stored in a Docker Volume, so it persists across container executions.
2. Wagtail is now installed into the 'web' docker container by the Dockerfile, rather than docker-compose. This lets Docker skip that step if nothing has changed in Wagtail since the last build (admittedly, not super common, given that this project is for developing Wagtail), and generally makes the whole process a lot cleaner.
3. I added a bunch of stuff to .dockerignore, which significantly cuts down on the 'web' and 'frontend' images filesizes and build times.
4. I gave each of the three containers specific names, so that they can be more easily executed into for things like running manage.py commands or other OS stuff. This resulted in the connect string for the postgres DB needing to be tweaked.
5. I changed the 'frontend' container's copy command for the node_modules folder to use the -u flag, which allows cp to skip any files that haven't changed since the last time the copy was run. This *dramatically* speeds up the startup of the 'frontend' container on all but the very first execution (which does the initial copy into the host's wagtail folder).
I really wanted to find a way to put node_modules into a Docker Volume, but since you can't write to Volumes during the image build process, that unfortunately negates any value-add that we might have gotten from their use in this case.
Thibaud Colas