![Osx Osx](/uploads/1/2/5/4/125489348/848991148.png)
I’m trying to install Discourse locally using the relatively new Docker for Mac. This is the error I’m getting while trying to rebuild for the first time: /launcher rebuild app Ensuring launcher is up to date Fetching origin Launcher is up-to-date cd /pups && git pull && /pups/bin/pups -stdin /usr/local/bin/docker: Error response from daemon: Mounts denied: er.com/docker-for-mac/osxfs/#namespaces for more info. R/discourse/shared/standalone/log/var-log are not shared from OS X and are not known to Docker. You can configure shared paths from Docker - Preferences. File Sharing. See 888ba058ad2b2c2e797e1d298183472aa7c75f29deb2344a0ffec9e7d987927f.
Thankfully, Docker for Mac recently released a user-guided caching feature as part of their ongoing initiative to address performance issues related to Implementing User-guided Caching. In order to use this functionality, you need to be running Docker for Mac 17.04 Edge, which will then enter the.
FAILED TO BOOTSTRAP. please scroll up and look for earlier error messages, there may be more than one Maybe I need to share some folder first? Is anyone trying to run it like this?
Got it working enough that it’s now just (from my local Discourse source root directory):./bin/docker/bootdev./bin/docker/bundle install./bin/docker/rake db:migrate./bin/docker/rake admin:create./bin/docker/rails s 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:.
Moved the 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 perhaps this is something that needs to be vendored?). Changed the discoursedev 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 discoursefastswitch 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.). Gave the discourse user NOPASSWD sudoer’s permissions in the discoursedev 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/postgresdata 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/shutdowndev 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). Replaced discoursedev’s postgres.template.yml and 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 to discoursedevelopment. (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 discoursedev 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. And the second part (the discourse proper, bin/docker command-line tools) are also available as a PR:. My favorite part about all of this is how easy it made development (from the README): Step-by-step It should be as easy as (from your source root):./bin/docker/bootdev -init # wait while: # - dependencies are installed, # - the database is migrated, and # - an admin user is created (you'll need to interact with this)./bin/docker/rails s Yup two commands: one to start the container, and one to kick off Discourse. (Although full disclosure there’s still that caveat about the ember-data-source gem, but even that has a bootdev command-line helper.).
Doing dev work in docker on a mac may be workable! Rails Boot Slowdown Host 5.64 Virtual Box 6.15 9% Virtual Box + Docker 8.78 55% Docker Mac (cached) 11.2 98% Docker Mac (uncached) 15.7 178% Note: for Docker setup on virtual box has gems are in AUFS and working directory in a mounted volume.
![For For](/uploads/1/2/5/4/125489348/872505731.jpg)
On mac the working directory is a cache mounted volume. It is likely performance would improve if overlay was used or gems are mounted on the host to avoid virtualized file system.