Question regarding NFS about performance and security

[jaequery]

I have been a long time Dinghy user (4+ years) but the past 5-6 months, I've used Docker for Mac (Experimental) release, which had support for Mutagen and it actually worked pretty well, just up until they decided to drop it and go with gRPC-Fuse which performed almost as slow as the original OSXFS. Now I am having to install a very specific version of the experimental release just to have D4M be usable and that is clearly not an ideal solution.

So I am most likely going to switch back over to Dinghy. But my issue w/ Dinghy was that the containers were outside of the localhost network and that there were lingering question about security. Other than that, Dinghy has been perfectly fine. But at the same time, I was not entirely sure what the downside of Dinghy were and want to clarify.

I've read some security issue and it was brought up again over at D4M when they recently tried exploring NFS as an alternative solution. There is some interesting chat going on https://github.com/docker/roadmap/issues/7#issuecomment-736694100, with many things over my head. Recently what was interesting was that, when they tested, they found NFS w/ inotify to be even slower than OSXFS, which is something I did not expect to hear. They did mention it was for write-heavy workload, which I guess isn't for my case or any of our cases? I'm still not really sure who are the main target audience for D4M.

Also they mentioned about security implication and I know you mentioned this too. But to clarify, are every Dinghy user atm when on a LAN, are they opening up their homedir to everyone on the network to see?

[codekitchen]

That discussion doesn't give any details about how they did the benchmarks, so it's hard for me to comment -- all I can really say is the dinghy implementation of NFS + filesystem events was definitely much much faster at reads and writes than Docker for Mac's solution back when we did the benchmarks. There's some numbers here: https://github.com/codekitchen/dinghy/issues/166

As mentioned in the dinghy README, the NFS daemon only binds on the private interface between the host MacOS and the virtual machine. So no, your files aren't even exposed on the local network.

To be clear, I don't use dinghy myself anymore. I find Docker for Mac plenty performant enough for my current use cases, and it just makes sense to use the standard solution if at all possible. But I've tried to keep the project alive as much as I can, since a lot of people still seem to rely on it.

[jaequery]

@codekitchen it is interesting to hear D4m is performant enough for your use case! Currently D4M doesn't seem to be suitable for any of the web applications such as Rails, Nest.js, etc that have a lot of package files. Even just starting it up takes over 5 - 10 minutes (Dinghy was near bare-metal speed, so it takes just a few seconds). This is on an i9 2.3ghz 16gb memory on an SSD drive. If you do similar work but don't have this problem, I'm curious to know what you may be doing that makes it work for you.

Regarding the NFS security, that is re-assuring. It makes me wonder if the D4M team have explored the solution you have put in, and if so, what the problem were.

I'd like to keep using Dinghy moving forward as it was the easiest to setup compared to some other solutions. As for D4M, it would be the easiest way but I don't see any performance breakthrough happening in the near future. I hold a class w/ many students and it is quite a painful process of getting them to install Docker in a specific way to be performant enough to do Rails/Node projects. It literally scares them away from using Docker.

Would be nice if there is some way for you to either bring back Dinghy or maybe even collab w/ D4M to come up with a solution on this D4M issue we have been plagued for years. From what I can tell, Dinghy is the most 'usable' out-of-the-box solution for me and many developers. It's just was not mainstream for whatever reasons.

[codekitchen]

Yeah most of my projects these days are very small so I just haven't run into any performance blockers. I originally started the dinghy project back when I was working on a very large Rails monolith and we desperately needed a better solution to those same startup time issues.

As for why Dinghy never really got super wide usage, I'm sure that's mostly my fault. I created the project to be used internally by my company, because somebody had to do it, but it's not something I was ever particularly passionate about so I never really tried to get the word out about it, or pushed the idea as far as I could have.

[jaequery]

@codekitchen i must say, that was quite an impressive effort you have made back then. and yes, there could've been a bit more PR and possibly Youtube videos demonstrating the usage explaining the why of combining both nginx proxy, dnsmasq, and nfs. perhaps that could've fueled the fire a bit. but regardless, i appreciate you for coming up w/ this years back when there was no decent solution, i and many others have benefited greatly.

i really hope you can continue to work on this project though, i think it solves a problem for many web developers who are not just dealing w/ performance issues but also those dealing w/ port conflicts running multiple docker containers and wanting a simple 1-click installer for dnsmasq and proxy.

[ryansch]

@codekitchen While we've moved our large Rails monolith (and ancillary phoenix services) to Docker Desktop, we couldn't have gotten here without dinghy. We were avid users across our organization until just a couple months ago. Thank you so much!!!

[ryansch]

Also we continue to use dinghy-http-proxy with Docker Desktop!

[mwalkerr]

@ryansch I'm guessing the performance was the same or close enough after the switch as compared to with using dinghy? Was there any special configuration on top of a standard setup to achieve good results? Were NFS mounts still used for the containers?