We replace the custom script wait-for-greenlight by dockerize: it is a
generic tool that allows for different services to be up. Also, on day,
it will allow us to generate config files dynamically (maybe).
We explicitely set the MySQL connection port, even if it is the default
one. I don't think this solves anything, but it's a good idea to
set the port explicitely, generally speaking.
This is not a security issue because ports 8000-8001 are not open to the
world; it should also drastically simplify the life of many people. See
for instance issues #30 and #34.
Also, we allow access to nginx on hostnames "localhost" and
"studio.localhost" for lms and cms, respectively. Again, this will
remove much of the confusion for many users.
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.
XModule could not be found because the compiled package could not be
found in edx-platform/common/lib/xmodule. This was due to the fact that
build operations realised after a VOLUME statement are ignored if they
affect the content of this volume (although it's not mounted during
build, of course). This is not a bug, it's a feature of the VOLUME
statement :)
Demo course about pages were not available (and probably many other
pages as well) because the preview url was the same as the real url.
Kudos to @dannielarriola for solving this!
Close issues #11#7.
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!
