Rabbitmq was not configured to restart on failures. It does not explain
why rabbitmq crashes (with exit code 255, see issue #80), but this should be sufficient
as a quick fix.
Duplicate "environment" statement in the docker-compose.yml was causing
the first one to be forgotten. Hence, the cms celery worker was running
with LMS settings.
Close #72
HTTPS is now fully supported. The ACTIVATE_HTTPS feature flag needs to
be set. Required domain names are LMS_HOST, preview.LMS_HOST and
CMS_HOST.
Close #46.
Xqueue containers consist of two services: a gunicorn service, that
receives requests from LMS/CMS, and a worker service. I guess the worker
service receives orders from the gunicorn service, through rabbitmq.
(but I'm less than certain about that).
While adding xqueue containers, we refactored the way mysql databases
are created, and how the root password is loaded. Also, we silenced some
options from the configure script.
Images are no longer built locally, Instead, they are downloaded from
docker hub. This completely changes config file organisation. In
particular, we no longer copy configuration files to the original docker
image.
By using variables in the nginx configuration to point to lms/cms, we
allow nginx not to require that lms and cms are up to run. This is
convenient for debugging production settings: just launch an nginx, then
runserver in an lms.
This allows the user to run their own devstack inside the containers.
Yay!
Also, we handle file permissions cleanly: in docker-entrypoint.sh we
chmod the data and edx-platform files to the same UID of the user on the
host machine. No more permission headaches!