I've set Docker on my Linux machine and it's working like a charm. Then I had to do the same for my coworkers running OSX, the vbox shared folders are definitely unusable.
Now it's been few days that I'm trying to find the best way to have a two-way sync in order to sync back changes from docker to the OSX folder (eg. when you upload a file and it's saved in the /public folder, otherwise it'll be lost)
So far I've used docker-osx-dev[0] for 1 way sync (with rsync) and it's working nicely.. they also plan to add the support to unison for a 2way sync
I've also found docker-unison[1] but I haven't found a way to have it working correctly
I'd like to try with boot2docker-xhyve, but it only runs on Yosemite and later
At the end of the day though, Docker as a development environment is really bad on OS X until a VM vendor fixes file share performance. I really wish Docker would make it a priority to have decent Mac support.
https://github.com/docker/machine/pull/1358#issuecomment-126...
Virtualbox shared folders are unusable for my purpose (compiling software on Linux).
If you're considering Fusion I'd suggest taking a look at AppCatalyst[1] instead (N.B. I work at VMware, but not on AppCatalyst).
Anybody know what would cause VMWare Fusion (or any VM for that matter) to behave this way?
You end up with broken code. If you are lucky it has a syntax error. If you are not lucky you get mysterious bugs.
The work around is to go back and try re-editing the file to retrigger a sync.
There are lots recommendations to try Fusion over Vbox but I think this issue makes it a wash.
Can you point me in the direction of a bug report or a more concrete example? I'd like to make sure we follow up.
In terms of fixes, ideally I'd like to see a way of marking a container as "volume-only" -- this would then mean a "docker-compose rm" would not remove it, and "docker-compose up" would never rebuild it.
- Its manifest file is more verbose and has a greater toolset [1];
- You can persist content from inside the container way better than simply mounting volumes using docker compose [2];
- Fow now, it relies on VirtualBox (usign debian2docker) but it has a built-in function [3] to sync folders into the container using rsync (significantly increasing performance for file sharing). You can still use VirtualBox Shared Folders if you want to;
- Its built-in DNS server makes you don't worry about port mapping and docker IP issues. You can access your local app running with azk by simply accessing a custom address, like: my-app.dev.azk.io.
[1] http://docs.azk.io/en/azkfilejs/README.html
[2] http://docs.azk.io/en/reference/azkfilejs/mounts.html#persis...
[3] http://docs.azk.io/en/reference/azkfilejs/mounts.html#sync
Now, with ailispaw's dockeroot-xhyve you can even get a VM root image that can be grown on the fly, so you never run out of space on your VM when building large Docker images.
In addition, I'd never recommend Docker Compose to web developers that rely on databases, as quirks with it have caused many a volume-only container to be destroyed and rebuilt, thus defeating the purpose.
[0] https://github.com/ailispaw/boot2docker-xhyve