Roles to enable running the forum in a docker container.
That means that instead of installing a Ruby environment, doing a git checkout of cs_comments_service, running bundle install (which potentially breaks if a ruby dependency has updated to an incompatible version), etc. it essentially does a docker pull edxops/forum and docker run. Of course, that means that we need to have docker installed, but that's a direction that we want to be going, so that will be useful for more than just the forum in the future.
Some notes:
had to name the role for installing docker docker_ce because there's already a docker role in there (that doesn't really do anything; assume it has something to do with how edx builds images).
defines a DOCKER_FORUM boolean variable that we can put in server-vars.yml. If true, it installs the forum this way, in a docker container; if false, deploys it the old way. Defaults to false.
the forum_docker role is basically copied from forum (to make sure all the config stuff is preserved) with the ruby bits then replaced with docker bits.
out of the box, I don't think this would work on a basic tier without some additional configuration (to expose the Mongo/Elasticsearch ports to the docker container). But we aren't doing those for Hawthorn anyway.
This goes straight to using systemd to manage the forum service rather than supervisord. I could be convinced to do that differently, but 1) I'm just more comfortable configuring systemd services and 2) supervisord just seems like an extra layer of configuration and potential breakage so I'd rather avoid it if possible. For the most part, it should just mean that you use systemctl start/stop forum_docker instead of /edx/bin/supervisorctl start/stop forum and access logs via journalctl.
Converting from the old approach to this approach on an existing deployment involves a couple steps:
set DOCKER_FORUM to true in your server-vars.yml
run /edx/bin/supervisorctl stop forum, then remove /edx/app/supervisor/conf.d/forum.conf, and run /edx/bin/supervisorctl reload. This stops the forum and stops supervisor from trying to manage it. (doing this before deploying the docker version prevents them from competing for the unix/TCP socket).
run a deploy
I've tested this out on the hawthorn sandbox and everything seems to work fine there. I think I've got everything set up so it should work on environments that use TCP ports rather than local unix sockets (eg, Tahoe), but that hasn't really been tested yet.
Roles to enable running the forum in a docker container.
That means that instead of installing a Ruby environment, doing a git checkout of
cs_comments_service, runningbundle install(which potentially breaks if a ruby dependency has updated to an incompatible version), etc. it essentially does adocker pull edxops/forumanddocker run. Of course, that means that we need to have docker installed, but that's a direction that we want to be going, so that will be useful for more than just the forum in the future.Some notes:
docker_cebecause there's already adockerrole in there (that doesn't really do anything; assume it has something to do with how edx builds images).DOCKER_FORUMboolean variable that we can put inserver-vars.yml. If true, it installs the forum this way, in a docker container; if false, deploys it the old way. Defaults to false.forum_dockerrole is basically copied fromforum(to make sure all the config stuff is preserved) with the ruby bits then replaced with docker bits.systemctl start/stop forum_dockerinstead of/edx/bin/supervisorctl start/stop forumand access logs viajournalctl.Converting from the old approach to this approach on an existing deployment involves a couple steps:
DOCKER_FORUMtotruein yourserver-vars.yml/edx/bin/supervisorctl stop forum, then remove/edx/app/supervisor/conf.d/forum.conf, and run/edx/bin/supervisorctl reload. This stops the forum and stops supervisor from trying to manage it. (doing this before deploying the docker version prevents them from competing for the unix/TCP socket).I've tested this out on the hawthorn sandbox and everything seems to work fine there. I think I've got everything set up so it should work on environments that use TCP ports rather than local unix sockets (eg, Tahoe), but that hasn't really been tested yet.