Comment by atombender | Hacker News Reader

Comment by atombender | Hacker News Reader

While I agree that Vagrant isn't 100%, the biggest source of our issues with Vagrant have actually been with VMware Fusion. VMware has lots of issues with managing its state. 8.x has a long-standing issue with port forwarding rules getting stuck, so some of us downgraded to 7.x just to get productive again.

The whole reason we migrated to VMware, about 3 years ago, was that we were using Virtualbox and being really bothered by the issues with it, things like corruption of files accessed through the shared folder mounts, that weren't being addressed. It's exasperating how brittle this VM stuff is.

Personally, I'd love a slimmer Linux-only solution based on Xhyve or Apple's Hypervisor.framework. I don't really want a Vagrantfile, I just want a low-level tool that I can drive from a wrapper, which we need anyway. Both Docker for Mac and Minikube now uses Xhyve, with great results.

We're slowly migrating our stack over to Kubernetes. Building with Docker for Mac is great, and Minikube seems really promising.

As far as I know, docker for mac isn't actually usable for dev work if you use mounted volumes. Basically it pegs CPU and makes disk access 10-150 times slower than native which makes mounted volumes impossibly slow. A personal example would be building a jar on a macbook native took 11 seconds, takes docker for mac 9 minutes. See https://github.com/docker/for-mac/issues/77 https://github.com/docker/for-mac/issues/668 and a slew of other reports that can all be traced back mounted volume performance.

Moral of the story I moved to linux.

Using Docker for Clojure and JavaScript development here. I actually don't have these issues. There is a performance loss, sure, but not nearly as much as you describe it.

I would say just check out the threads for the sort of experiences people are reporting across pretty much every stack from rails to symphony. In my case above it was actually jvm clojure building an uberjar, probably worst case scenario. REPL was usable because it didn't do a any mounted volume access, just network access.

I noticed that lein-ring with autoreload is magnitudes slower. We now turn it off for microservices not being worked on.

Anyway, I have read a lot about those problems and I hope it gets better at some point - especially for Docker on Windows, which is a pain in the neck for our developers (who now work with a Linux VM running Docker; ...)

Many developer use cases do not demand heavy bind mount file access. For example, incremental builds of static languages typically work fine.

docker/for-mac#77 is related to "bind mount" performance but docker/for-mac#668 is virtual block device performance. Have you posted a reproduction workload that demonstrates the performance problems you are having?

Docker 17.04 includes a `cached` bind mount flag that relaxes consistency of the mount in exchange for significantly reducing guest-host roundtrips especially for inefficient workloads that repeatedly access the same files.

Could you please link to some docs for the cached flag you mentioned? I can't find anything about it.

Documentation for 'cached' is on its way. There'll be a blog post up soon with a friendly introduction, and some representative benchmarks. In the meantime there's a drier but more detailed specification of the behaviour of 'cached' waiting in a pull request here:

  https://github.com/yallop/docker.github.io/blob/d9a57867/docker-for-mac/osxfs-caching.md

We're seeing the same issue. We've been using shared folders with VMware for a long time, which are also slow (but not this slow).

There's a case for keeping the Docker environment stateless and expendable (wipe to restart), and keep certain things (PostgreSQL databases, for example) on the host machine. Currently, that's impossible because of the aforementioned issue.

I haven't tried the "cached" flag since it's still in beta, however.

While not ideal, docker-sync has improved the file access issue substantially:

http://docker-sync.io/

Minikube is working great for us. Makes it easy to run something that's pretty close to a production stack on a dev machine.

Typically with locally-built (dev) images rather than those from the registry that CI writes to, but other than that the k8s manifests are the same.

Reply on news.ycombinator.com