Frontend and config changes to django-app-template

[thomaswhyyou]

• Fix Vagrantfile configuration so that it actually runs.
• Clean up docker-compose.yml for explicitness in volume option, so it gets rid of deprecation warning
• Add docker-compose-dev.yml for development purposes
• Add root url with custom front pages
• Edit README accordingly to replace references to node with django.

[geoffscott]

@thomaswhyyou I'd like to break this up into much smaller PRs that each reflect one conceptual change. One for serving static content. One for interactive debugging. I think those were the two main theme's, right?

Regarding static content, I don't think it's a good idea to move the static folder up one level. For instance, what would happen if the reverse proxy needs to be deployed on a different physical server than the django server? Alternatively, look at Docker's ability to mount the volumes of another container. You'd need to configure this in the docker-compose.yml file for development and in the Dockerrun.aws.json file for staging and production.

Philosophically, I've been trying to keep the DevOps tools to a minimum, and I haven't yet seen a need to add Ansible, so let's hold off on adding it (or any other new tools) until we literally can't proceed without doing so.

Another principle that I've followed is that I'd like the dev environment to as closely as possible reflect staging and production. This means you should develop against nginx+uwsgi+django. But I think you can run django to auto-reload and to drop into a debugger in this config. You'd just need to be able to run the right django-admin.py commands inside the djangoapptemplate_appsvr_1 container. I think you can do this the same way that you would open a shell inside of the running container using a command like this: 'docker exec -i -t djangoapptemplate_appsvr_1 /bin/bash'.

There should be one and only one docker-compose.yml file in a project, since it's sole purpose is to stand up the dev environment. Let's follow the principles above and revisit how to get interactive debugging working.

[geoffscott]

@thomaswhyyou check out this and see if there's anything in there that will help with interactive debugging: https://docs.djangoproject.com/en/1.8/ref/django-admin/

[thomaswhyyou]

@geoffscott Geoff many thanks for the feedback, I appreciate you taking the time to write up. I will give it another go the first thing in the morning, in smaller chunks as you suggested. Some thoughts on your feedback below.

• Regarding one and only docker-compose.yml: I understand your position, I will remove the other. For interacting debugging, from what I researched last week, I didn't see an obvious way to do it while having django run behind nginx+uwsgi; django-admin command you referenced above is in fact what I used in the other docker-compose file (http://bit.ly/1ELr39X) to run the app directly, as "manage.py" is a built-in wrapper around "django-admin.py" with some convenience.
• Regarding /ansible folder in .gitignore: Again I understand your position, I will remove it.
• Regarding /static folder: This one I think was a misunderstanding, and really my fault for it. "one level up" was a reference and relative to what I did before the commit, not what you had originally. In fact there wasn't any static folder to begin with. In any case, I don't quite understand your point about the reverse proxy - unless you are serving static/media files off remote endpoints like S3, nginx needs to have access to these files in its box regardless of where the static directory resides? As you mentioned above, "nginx" container in docker-compose.yml indeed requires "volumes_from" "appsvr" container, as is already (http://bit.ly/1FuxXvb). I simply created a static directory at the location nginx was configured to find (http://bit.ly/1OthU61); of course this can be configured anywhere else.

Happy to discuss more in person! Thanks again, and I will revert back with new commits in the meantime. Thomas