Please use the github-issue queue so we do not carry this topic offtopic.
I confused myself with docker_sync and docker-sync. I removed the old gem (docker_sync) and added a new one docker-sync
Install it gem install docker-sync
I fixed the task issue, it was a special issue when running docker-sync from not a thor directory. Sorry.
Be aware, the start syntax has been simplified
I added Unison support with 0.0.5, so you can try out both implementation named in this thread ( rsync and unison ).
You can chose, per sync point, which strategy to use - so you can also combine rsync and unison depending on the folder you want to sync for your project, which can make a lot of sense
Just gave docker-sync a go. Incredible work and Symfony 3 is now loading in 300ms while in debug mode. A small note for anyone giving it a go, ensure you name the sync something new. I named mine the same as a container name and ran into some conflicts.
@eugenmayer You are right, iâll keep the issues to github, sorry.
Just tried it out the new version tho. An excellent work around for now, many thanks!
Hi! Can you show please your docker-sync file? Iâm in troubles with permissions for user. I get âPermission deniedâ because the user is xfs, not www-data.
My absolute last comment on this in this thread, since people will get annoyed, out of good reasons, listing to arbitrary âthird part tool issueâ in this thread. This thread is for performance issues with docker for mac shared http://docker-sync.io is just a tool to solve that.
If you want any help on your issue, use github issues and please, read the docs.
I will not answer on any âhow do i do / i have this issue with docker-syncâ in here anymore, i will gladly assist you on github though.
My apologies to all listing to this âofftopic stuffâ - wont happen again.
Part of documentation says: âAdjust your docker-compose.yml as explained hereâ. For me this kind of requirement disqualifies that solution. Itâs not portable (what if part of the team uses linux?) and feels like dirty hack.
Alternative workarounds are always valuable discussion, but if a moderator could split those posts into a separate topic, that would be ideal. Even before that discussion picked up, this topic had multiple times the views and comments of any other thread in this forum, so thereâs definitely a large audience here interested in hearing about progress against osxfs itself.
To that end, and hopefully to bring us back on topic: if the Docker for Mac team could afford some time to give us an update on progress being made here, the target performance metrics to hit public release, etc., that would be wonderful to hear! Thereâs a bit of negativity in this thread, but my team is incredibly floored to use this as long as the performance versus our current solution doesnât prohibit their workflow
time dd if=/dev/zero of=test.dat bs=1024 count=100000
100000+0 records in
100000+0 records out
102400000 bytes (102 MB) copied, 26.133 s, 3.9 MB/s
real 0m26.141s
user 0m0.130s
sys 0m1.980s
wihout volumes
time dd if=/dev/zero of=test.dat bs=1024 count=100000
100000+0 records in
100000+0 records out
102400000 bytes (102 MB) copied, 0.270396 s, 379 MB/s
real 0m0.273s
user 0m0.010s
sys 0m0.260s
When people test, can you specify which image youâre using. Iâm interested to know if some images are affected more than others. Itâd be interesting to track.
I also suggest adding read-performance, since this matters a lot and actually is one of the main reasons the applications are running that slow ( as some mentioned above )
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):
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.
@philm I tried this but it has one severe problem, at least on my machines. Try renaming a file on your host machine. That rename ultimately does not propagate. I donât know if it is osxfuse or unison falling down in this case, but that made this approach a non-starter for me and I switched back to running unison locally and connecting over a socket.
Interesting - seems to work for me when doing a âmvâ via a docker-compose exec session. Would you mind posting your Dockerfile, docker-compose.yml, and runtime command/script (and anything else you think is helpful) either here or in a private gist? Would love to help you debug it.
@philm yes, that works fine, but can you try from OSX? The issue is when going through osxfuse. If you do a mv from within the container itself via exec it works as youâd expect.
