Question regarding NFS about performance and security

[jaequery]

Question regarding NFS about performance and security

[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!!!

[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: #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.

[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?