Add Docker Compose files

[pandringa]

This automates the instructions from the readme inside the Dockerfile, then also creates a docker-compose.yml file that can build both the postgres image and the web server together.

The settings.py is copied into the Docker image to customize the settings for the Django server, so place any Django config edits in this file.

To use, just run docker-compose up -d

[steven-king]

@leetrout take a look at what @pandringa did while I was teaching!

[pandringa]

Now that I take a second look at it though, the one downside is that it doesn't mount the local filesystem as a volume onto the container, so it's trickier to edit the files. If you want to have the whole class use this, we should set up a volume on the host with the source code, rather than using the "startproject" command in the Dockerfile

[leetrout]

Excellent work @pandringa! 🙌 🎆

Yep- compose is the end goal I just felt like it was good to show what it's automating away so there's (hopefully) less magic and a better appreciation for the automagic bits when we get to it 😂

we should set up a volume on the host with the source code, rather than using the "startproject" command in the Dockerfile

Good catch on the volume and as I'm sure you saw - very easy to configure within compose. VERY important for the database before anyone starts using this and loses their work!

While Django project layouts are static enough to have a common skeleton running the setup command this way (via docker run with the bind mount) was to demonstrate how to get started (following along with the tutorial). Running it in a container with a bind mount should have the same end-effect as running it locally before hand with the benefit of putting the production-equivalent environment first.

I would suggest continuing to use docker run for one-off command runs so the homogenous environment is used for everyone. As the project continues to grow there will be more and more commands that need to be ran (migrate, collectstatic, etc) and the container's environment is ultimately what will be deployed.

Also- if you've not ran into this already, beware.... even though the project is mounted in to the container using the same virtualenv inside and outside of the container could lead to problems with binary wheels and/or extensions that get compiled against the OS libs (think libffi and other crypto libs) and they will potentially break if installed in the venv in macos and used in linux or vice versa.