Here’s what I’m doing locally to get past this problem. It’s a variation of the above but using the unison binary inside my Docker image / container without the need to run another executable on the host machine.
I have a shared volume mount pointing to /app and use Unison to sync files to /running, which is where the app server is looking. Since /running is not volume mounted, it doesn’t suffer from the performance issues that inspired this thread.
First, my app’s Docker image also installs a newer version of the unison and unison-fsmonitor libraries from a repo I found (the Ubuntu 14.04 version is a bit stale and had some issues):
RUN wget -q https://github.com/TentativeConvert/Syndicator/raw/master/unison-binaries/unison-2.48.3 -O /bin/unison \
&& chmod +x /bin/unison
RUN wget -q https://github.com/TentativeConvert/Syndicator/raw/master/unison-binaries/unison-fsmonitor -O /bin/unison-fsmonitor
&& chmod +x /bin/unison-fsmonitor
The Dockerfile also adds my local files and does an initial sync:
ADD . /app
RUN unison -auto -batch -ignore 'Path .git' -silent /app /running
My docker-compose.yml references a custom shell script:
And my start script does this:
unison -repeat watch -auto -batch -ignore 'Path .git' /app /running &
cd /running && bundle exec rails start
Notice the unison executable is being launched as a background process.
The reason I like unison is because of its bi-directional sync. If my app generates a file that I need to look at in my code editor or Web browser, it’s automatically located where I need it to be. I haven’t run into any permissions issues or other significant problems, but curious if the above technique works consistently for others.