codekitchen / dinghy

faster, friendlier Docker on OS X. Deprecated.
MIT License
2.12k stars 109 forks source link

Make unfs and dns optional #253

Closed nbr closed 7 years ago

nbr commented 7 years ago

Add :dns_disabled

Disable DNS/HTTP proxy altogether by setting :dns_disabled: true in ~/.dinghy/preferences.yml, or by passing --no-dns flag on CLI. Note that disabling DNS will force HTTP proxy to be disabled.

Add :unfs_disabled

See https://github.com/codekitchen/dinghy/pull/232

Display services as disabled

This helps to differentiate crashed services from disabled services. Uses contributions from https://github.com/codekitchen/dinghy/pull/232.

Example:

$ ./bin/dinghy status
   VM: running
  NFS: running
 FSEV: disabled
  DNS: disabled
PROXY: disabled

Your environment variables are already set correctly.

Fix fsevents_disabled reset issue

When :fsevents_disabled: true in ~/.dinghy/preferences.yml, after running dinghy create or dinghy up, that value will be reset to false. Preferences#update was being passed {fsevents_disabled: !fsevents, ... }, where fsevents returns a FseventsToVm object (thus it is trivially truthy).

codekitchen commented 7 years ago

This looks reasonable, thanks. I'm curious what the use case is though? From my perspective it seems like if you don't want the DNS or UNFS enabled you'd be better off just using Docker for Mac, so I must be missing a use case.

Also, are you using something else in place of UNFS where the fsevents forwarder still makes sense to run? It was designed pretty specifically around how the UNFS sharing works, so I'm not sure it makes sense to run fsevents if unfs is disabled, but maybe it works well enough with some other fs sharing solution?

nbr commented 7 years ago

This looks reasonable, thanks. I'm curious what the use case is though? From my perspective it seems like if you don't want the DNS or UNFS enabled you'd be better off just using Docker for Mac, so I must be missing a use case.

Also, are you using something else in place of UNFS where the fsevents forwarder still makes sense to run? It was designed pretty specifically around how the UNFS sharing works, so I'm not sure it makes sense to run fsevents if unfs is disabled, but maybe it works well enough with some other fs sharing solution?

For DNS, the use case is to use https://github.com/FreedomBen/dory instead, which has built-in integration with dinghy and will also work on Linux and Docker for Mac.

For UNFS, the intention is to make it possible to use other FS sharing solutions, which may or may not have better performance than UNFS. It is currently not possible to experiment.

As far as I can tell, fsevents_to_vm is still useful for other NFS solutions, e.g. using macOS nfsd as the server.

Regarding Docker for Mac, for my application the performance of NFS is still superior to their volume mounting solution, and I have found dinghy to be the most stable option for using NFS and Docker.

codekitchen commented 7 years ago

Cool, sounds reasonable. If you do experiment with using the OS built-in NFS server, be careful of the security implications, since it doesn't listen on just the virtual networking interface like dinghy's unfs3 solution does. Thanks for the PR.