Woo! Got it working enough that it’s now just (from my local Discourse source root directory):
… and I’m running Discourse at localhost:3000! I don’t need ruby, postgress, or redis installed… it’s all coming from the container.
In order to make this work, I did make a couple of changes in discourse_docker:
discourse user creation and
/var/www directory creation from the discourse Dockerfile into base, for reasons that will become clean in #3.
Updated the ImageMagic dependency from 6.9.5-8 to 6.9.5-9. (The -8 version has disappeared from imagemagick.org… perhaps this is something that needs to be vendored?)
Changed the discourse_dev Dockerfile to come from
base, rather than
discourse, so that it doesn’t carry the weight of a full Discourse installation only to replace it with local sources. (I bypassed discourse_fast_switch simply because I don’t quite understand what it’s doing. Discourse appears to need ruby 2.3.0, and that seemed to deal with 2.0.0/2.2.0.)
discourse user NOPASSWD sudoer’s permissions in the discourse_dev image. (I was running into problems with
./bin/docker/bundle install, and this was an expedient fix… and for a development container seems not-so-risky.)
Under the assumption that a development environment should be fairly self-contained, removed the step that moved
/shared/postgres_data out of the way. Postgres had permissions/db-creation issues when I tried mounting a local data directory into place. The downside is that the postgres data now lives completely inside the container, and
./bin/docker/shutdown_dev will cause you to lose everything. I’m personally okay with this for now, but will keep playing with ways to make this work better (e.g. give you the option to mount a volume and persist data across invocations).
redis.template.yml with the ones from the main
templates directory (the ones that the “standlaone” app description use), changing the postgres DB name from
discourse_development. (Ideally, I’d like to see that as a programmatic step, rather than a manual copy, so that the Docker images are auto-updated with each build.) This ensured that the database was set up like Discourse expected.
Right now, the Docker image build is handled by
build.rb, but I’m really, really tempted to drive this via Makefile… but partly that’s just because I understand Makefiles better than I understand ruby.
Also… when using this on my machine, the
ember-data-source pulled in by
./bin/docker/bundle install was 2.3.0.beta.5, which seems to be missing its
dist directory. Updating Discourse’s ruby dependencies seeemed well beyond my pay grade (and experience), so I just manually patched my running discourse_dev container with locally-built dist files. It worked, but that’s clearly not a tenable long-term solution. Sadly the “small” step from 2.3.0.beta.5 to 2.3.0 proper forces ember-source minimum dependency to go from 1.8 to 2.0… and I kept getting an “empty” home page after that.