"Staging" covers the meaning of what is actually happening better than
"deploy". I want to keep "deploy" for actually deploying onto a production
server.
- Ubuntu 17.10 → 18.04.
- Python 3.6.3 → 3.6.6.
- Use `DEBIAN_FRONTEND=noninteractive` to prevent prompts during
installation.
- Install `tzdata` in the base image as it's required by subimages.
- Correctly set maintainer in Dockerfile.
This radically changes the way we deploy to the production server, as a
Git checkout is no longer required there. All the necessary files are
now inside the docker image. As a result, /data/git should no longer be
mounted as a Docker volume.
- Renamed docker/build.sh → docker/full_rebuild.sh
This makes it clearer that it performs a full rebuild of the Docker images.
- Full rebuilds should be done on a regular basis to pull in Ubuntu
security updates.
- Removed rsync_ui.sh, we no longer need it. Other projects can also
remove their rsync_ui.sh.
- Moved deploy.sh → deploy/2docker.sh and added deploy/2server.sh
This docker container uses the Blender Cloud image, but a different entry
point. It is not intended to be network-reachable from the outside world.
All it needs are connections to the databases (mongo, redis, rabbit).
This replaces bash with the docker command, freeing memory and
automatically returning the exit code of the docker command as the exit
code of the shell script.
1_base: builds a base image, based on Ubuntu 16.10
2_buildpy: builds two images:
2a: an image that can build Python 3.6
2b: an image that contains the built Python 3.6 in /opt/python
3_buildwheels: builds an image to build wheel files, puts them in ../4_run
4_run: the production runtime image, which can't build anything and just runs.
