In other words docker for mac is completely unable for it’s primary use case Docker you make me laugh and cry.
Does docker on windows suffer from the same problems?
In the meantime, for the millions of developers with mac laptops that can’t immediately switch over to linux laptop, and want to use containers for local development environment to build java/node/ruby/php apps. What’s the current best option?
I completely agree, I’ve ran into the same performance issue with VirtualBox using NFS with Drupal projects (switched to rsync, then switched again to a plugin called gatling-rsync-auto – for performance reasons).
I would like to see D4M include a de-facto solution (docker-sync seems like the best option to me) so that end users aren’t forced to spend countless hours researching to come to the same conclusion.
I gnashed my teeth for about 24 hours on this problem before coming to a simple solution for my case: simply don’t sync when not necessary. I’m sure this doesn’t work for everyone – but in case your issue is analogous:
I set up a development environment including traefik, ember-cli and some data services. Ember-cli has the package directory mounted and uses ember serve to serve. It takes 8-10 times longer set up this way. However, mounting the ./tmp and ./dist subdirectories as tmpfs volumes gives me almost all the time back.
I like to mention that there is still the docker-toolbox which does not experience these performance issues. I use it for some php projects and the loading times are 5 to 10 times faster using virtualbox and even faster using vmware fusion.
But it is. I used boot2docker a year ago and i can confirm that is was so slow that i used nfs instead. But the newer virtualbox versions have better shared folders which in my experience are on the same level as nfs shares. As I said, I have symfony and typo3 projects running with docker on a mac. I tested a typo3 project with 5200 php files and cache disabled (although still not all are used for a request).
This is the an apache benchmark result for a page with docker for mac:
Percentage of the requests served within a certain time (ms)
100% 2735 (longest request)
This is the same request with the same benchmark and the same configuration but using docker-toolbox:
Percentage of the requests served within a certain time (ms)
100% 880 (longest request)
I don’t have php 7 natively installed and I can’t easily reproduce this environment natively… I could try to start docker completely within a linux vm but I think my point is already clear. I would try the docker-toolbox.
EDIT: I thought I add some information: I used docker for mac Version 1.13.1-rc1-beta40 and docker-toolbox with the vmware fusion driver.
Well, this thing is irritating - true, but I don’t think that it makes Docker for Mac useless.
Actually I use docker-compose + docker-sync in a project where other team members are Linux users and it’s not that bad.
I even wrote an article about how some things may be tweeked (thanks to this thread and few more on github) http://espeo.eu/blog/docker-for-mac-performance-tweaks/
If You can live with few small quirks then Docker for Mac is pretty usable… for eg Java guys in my company are happy with 1.13
I have to agree. Can be better, yes… but already really useful… yes. I use for all Drupal 7/8 sites with a my own custom UNISON container approach to managing this particular issue, and have no other issues. I’m looking forward to this being resolved, but doesn’t actually get in the way of any development work.
It still works fine if you aren’t sharing a large number of files in a volume. But for example, our test suite takes 20x as long running in docker vs not so people no longer run tests in docker for development.
I am concerned Docker has gone completely silent on this. I would like to know if this issue is being actively worked? I’m guessing not or we’d have gotten a recent update.
Hi everyone. A few months ago I encounter NFS limitation when I need to restore a database file with size more than 300MB. NFS simply time out when in use. So, I switched to use docker-sync instead. For the databases, I use named volumes and only pull the files out as a backup rather than mounting the data folder using NFS / osxfs / vboxsf. So, now I don’t use NFS or any shared folder anymore. The development synced to named volumes using unison wrapped by the docker-sync gem.
For those who struggle with the slowness of the available shared folder, try docker-sync and see if it help you in your work with docker.
Hey, I have used D4M for months now for Symfony and eZ Platform projects. I looking forward to testing the new :cached option or Docker when released. I don’t really like docker-sync as it duplicates everything… but anyway, why would you use NFS for your database? I have used D4M with DB bigger than that. But my database does not mount anything from the host.
To me, D4M should be used only to share the code between the container and the host for development purposes and that is it. I am also sharing the cache for PhpStorm plugins and some configuration files.
But other than that everything else should be in the container (no mount on the host) and then the perfs are native.
The biggest concerns using docker-sync were host-dependencies - and that has been removed - there are no host dependencies any longer - just a gem on your system ruby. No brew, unison or unox.
In addition to that, no filewatchers are used anymore, so no crazy CPU usage. OSXFS is used in a away that the OSX->sync-container sync is done using the low level implementation of OSXFS, but the mount into your app container is done using a live-copy - that gives you native performance while having a 2-way sync without hazzles.
Tried every option and landed with this one. Making use of docker-sync (currently using 0.4.6) is by far the fastest solution. The real difference is noticeable especially with PHP applications. Would really like to see that the Docker team looks into integration this the Docker core somehow
This issue has started for me in the last day for no apparent reason. I did
update to the latest Docker this week but problems did not occur directly
afterward. Still happens after fresh shut down and start (mostly).
Version 17.09.0-ce-mac35 (19611) Channel: stable a98b7c1b7c
macOS 10.12.6 (16G29)
I have a strong feeling that it is related to mounted volumes, but I’ve not been able to prove 100%.
UPDATE: I created an A/B test to replicate using a repo with README: