Running Discourse on Docker for Mac

I was trying to say that -v "discourse-sync:/src:nocopy" should not be changed, otherwise the source code would be mounted to a different directory in the container. This explains why neither rails nor bundler could find the source code. :man_facepalming:


D’oh :wink: Brilliant, thank you! Having this up and running makes dev work so much easier! :slight_smile:

I owe you a :beer:

1 Like

Be sure to do a PR to discourse making this config optional so we both document and make switches for it.


So I had it working for a few minutes. Then I noticed that files weren’t actually syncing after making changes. Figured I’d try a docker-sync clean and do the whole thing again. I do the same steps we just went through, but again, I get the Gemfile not found message. However, this time I haven’t renamed src to discourse. :crazy_face: Not sure what is happening here.

I’ve even tried renaming the discourse folder to src to match your code exactly, but it still won’t work.

Is there a way to check if the source code is mounted to the right directory?

Is there a way to check if the source code is mounted to the right directory?

d/shell into the container and check manually? docker-sync on macOS is not quite stable (judging from its GitHub issues), but I’ve rarely had problems myself.

I added the docker-sync related functionalities to Discourse and pushed it to a branch on my fork:
xrav3nz:dev/docker-sync. Would you like to try it out instead? docker-sync is integrated into boot_dev and shutdown_dev, and all the existing docker scripts should continue to work.

I’ll PR the changes into core if everything looks good for the next few days.


Nice! Unfortuntely, even on your branch I get “Could not locate Gemfile” :confused:

in /discourse: $ ./bin/docker/boot_dev --init
Using source in: /Users/jorgen/Dropbox/Design/2018/discourse
Using data in:   /Users/jorgen/Dropbox/Design/2018/discourse/data/postgres
          ok  Starting native_osx for sync discourse-sync
unison: stopped
unison: started
     success  Sync container started
          ok  Starting native_osx for sync postgres-sync
unison: stopped
unison: **ERROR (spawn error)**
     success  Sync container started
     success  Starting Docker-Sync in the background
Installing gems...
Could not locate Gemfile

There is a “spawn error” near the end there…not sure if that has anything to do with it.

Could you try d/shutdown_dev && docker-sync clean && rm .docker-sync/daemon.log && d/boot_dev, and PM me the content of .docker-sync/daemon.log? Please do not add the --init option just yet, since that will obfuscate the log.


Ah, I had forgotten to do a docker-sync clean after switching to your code, it seems to work as it should now :slight_smile: Thanks again :smiley:


Sorry but I am having trouble understanding the setup process to get Discourse working locally with Docker for Mac. I’m not that great with Docker yet, so bear with me.

The first thing I did was run:
docker pull discourse/base:release

That downloads fine. Then I create a container by running:
docker run --discourse -d discourse/base:release

What’s the next thing I want to do after that?

I see the instructions here:

I can’t do docker exec -it discourse /bin/bash because the container doesn’t stay running after I run it.

Thanks for the assistance!

Hi @xrav3nz - thanks for doing this work. I find macOS/Docker/Discourse runs very slowly compared to Linux/Docker/Discourse

I tried using your branch but got the following on `d/boot_dev --init`: pg_dump: [archiver] could not open output file "/src/db/structure.sql": Permission denied Any recommendations?

Update - it appears to have worked after retrying the boot_dev command. Unsure what caused the original problem.


TL;DR: the Docker for Mac delegated/cached volume mount is consistently ~3x faster now, and much more stable than docker-sync. I’d be happy to PR a change when I’m sure this does not introduce new problems.

I’ve been running into more and more problems with docker-sync lately. Unfortunately, I don’t understand enough of it to figure out what exactly is wrong. :disappointed:

I tried out the different mount options from Sam’s post a year ago,

  • docker-sync

    ❯ /usr/bin/time d/rails r 'puts'
    2.71 real         0.07 user         0.02 sys
    3.11 real         0.07 user         0.02 sys
    2.99 real         0.07 user         0.02 sys
  • default (consistent) i.e. -v "$SOURCE_DIR:/src"

    ❯ /usr/bin/time d/rails r 'puts'
    13.74 real         0.06 user         0.01 sys
    13.73 real         0.06 user         0.01 sys
    14.44 real         0.06 user         0.01 sys
  • delegated i.e. -v "$SOURCE_DIR:/src:delegated"

    ❯ /usr/bin/time d/rails r 'puts'
    4.77 real         0.07 user         0.01 sys
    5.39 real         0.06 user         0.07 sys
    4.86 real         0.06 user         0.01 sys

I have been using the delegated mount for the past two weeks, and have yet to ran into any problems. Even though docker-sync is still the most performant, delegated/cached is stable and consistent, and it’s already fast enough (~3x faster than the default) for me (running tests and localhost).


Sure send through a pr, looks great

1 Like

That’s great news!

I tried to get docker-sync working but struggled. Having another option comes as a relief!

Here’s the PR :wink:

I know; I too have spent too much time debugging docker-sync than I care to admit. This new approach, albeit not as fast, requires zero additional effort to setup and is quite stable from my own experiences!


I finally installed Discourse on my Mac… but it is hell to slow…like I’m taking super slow (20 sec a page).
So my question:

  1. Is this a docker issue or a discourse code issue?

Anyone having the same issue?

1 Like

It’s a Docker for Mac issue. Setting up Discourse natively on your Mac for development will improve performace drastically.


Maybe Discourse shouldn’t use Docker at all? I do not see the advantage. Seriously it’s just an extra layer and debugging containers will become a pain. Just saying.

Docker standardises the environment around the running app and sandboxes it from the host.

It would be a nightmare for the Discourse team to support self-hosted installations without Docker, as the host environment and config would vary wildly between Discourse instances - particularly between Mac and Linux for example.

Docker results in a small performance hit in Linux (admittedly larger on Mac) but the advantages are huge for a open-source project like this with a distributed development team and thousands of self-hosted instances.

If you want to run an app at any kind of commercial scale (e.g, using Kubernetes for cluster orchestration), you need to containerise your app in order to abstract all the implementation details away from the orchestrator.

1 Like

I don’t use Docker in my dev environment (albeit on Ubuntu). It’s actually probably more work to do it the way I do it as it’s a pain to rebuild from scratch.

Back at you @cmoi,

Just installed a new setup, for dev, on my mac (for development, see post #44 above) and it is very fast. No problems at all.

Regarding your other question

@cmoi says…
Maybe Discourse shouldn’t use Docker at all? I do not see the advantage. Seriously it’s just an extra layer and debugging containers will become a pain. Just saying

We run discourse in docker in production and staging, and it is great. One reason is that it takes a fraction of the time and effort to set up in docker than it does “on the metal”. It is also much easier to restore in the event of a server crash in docker.

So, there are many reasons to run in docker (in production), without question.

However, for plugin development, I finally switched to a “bare metal” setup without docker and I can see already that loading and reloading plugins, debugging and all that fun stuff is going to be much faster and more fun, outside of docker, for sure.