Docker work-flow improvements

[hdoupe]

This PR aims to make the process of working with PolicyBrain's Docker containers a little easier. The development and deployment structure for PolicyBrain is beginning to solidify. Now is the time to make it easier to develop and deploy with this new infrastructure. Here are some goals for this PR:

• only tag the PolicyBrain version in one place
  • currently the PolicyBrain version is hardcoded in two Dockerfiles, docker-compose.yml, the three back-end and one front-end image on dockerhub (where the images are pushed once they are tagged), the PolicyBrain webapp/settings.py file, and the git history.
  • It is difficult to remember to keep all of these tags in sync and it is easy to be lazy and not update the tag in one part of the app when another part of the app is updated in an unrelated way.
• scripts for building and publishing all images
• scripts for building and running all images
• need to find a flow that makes it easy to develop and quickly see changes without re-starting and re-building a bunch of docker images.

If all of these goals are accomplished, then PolicyBrain will be very close to a place where it can be put on an automated build and deploy system. This is very exciting for me because I would get to save a lot of time by not manually deploying the webapp. More importantly, it is exciting for anyone who develops the webapp or reports bugs found in it because the changes can be seen in production much more quickly.

@Abraham-Leventhal, @lucassz, @andersonfrailey if you have any ideas related to this issue I'd be happy to hear them. Even after this is merged, feel free to open up issues around how the process for running PolicyBrain locally could be made easier.

[hdoupe]

I'm going to use the Makefile added in PR #900 while I'm developing over the next few days. I think this will help identify which commands are missing and which commands can be improved.

[hdoupe]

Whoops, looks like this was automatically merged with #910 since changes here were merged into #910. The upshot of the changes here are that all images can be tagged, built, and pushed via a command like:

TAG=v1.7.0_rc1 VERSION=test make dist-build -e TAG=$TAG && \
    make dist-push -e TAG=$TAG && \
    make web-build -e TAG=$TAG && \
    make web-push -e TAG=$TAG -e VERSION=$VERSION

There are still some ways where workflow can be improved. For example, I found myself using the following command pretty frequently while working on the worker node app in #910:

cd .. && \
    make dist-build -e TAG=$TAG && \
    cd distributed && \
    docker-compose rm -f && \
    docker-compose up

Perhaps, there could be another Makefile in the distributed directory. I'm not sure what the protocol for chaining together Makefile commands is.

@martinholmer I got the idea to use Makefile's here from you. Thanks for the inspiration. The use of a Makefile has streamlined development significantly. Also, it was pretty easily to develop the first iteration of this file.

Do you have any thoughts on the Makefile merged here? Or, any ways that it could be improved?