search

adlogix / docker-machine-nfs

Activates NFS on docker-machine
MIT License
794 stars 104 forks source link

Improve configuration/clean-up of the /etc/exports file #24

Open tonivdv opened 8 years ago

tonivdv commented 8 years ago

The configuration and cleanup of the /etc/exports file should be improved. Using the technique of Vagrant could be a good approach:

# VAGRANT-BEGIN: 21171 5b8f0135-9e73-4166-9bfd-ac43d5f14261
"/path/to/vagrantfile" 172.28.128.5(rw,no_subtree_check,all_squash,async,anonuid=21171,anongid=660,fsid=3382034405)
# VAGRANT-END: 21171 5b8f0135-9e73-4166-9bfd-ac43d5f14261

We should probably use the docker-machine name and would be something like:

# DOCKER-MACHINE-NFS-BEGIN: machine-box
/Users 192.168.99.100 -alldirs -mapall=501:20
# DOCKER-MACHINE-NFS-END: machine-box

Things to keep in mind:

ogizanagi commented 8 years ago

Using the whole network should do the trick. Here is what I use manually:

# /etc/exports

"/Users/Ogi" -alldirs -mapall=Ogi -network 192.168.99.0 -mask 255.255.255.0
tonivdv commented 8 years ago

@ogizanagi Can you elaborate what this does, and how it improves it all?

ogizanagi commented 8 years ago

It'll allow you to not care about docker-machine ip, which would be in the whole 192.168.99.0/24 range anyway, by allowing any IP from this network to mount the given /Users/Ogi NFS share.

tonivdv commented 8 years ago

@ogizanagi Ok I see. That could indeed be much easier approach. What are the downsides according to you, if any?

ogizanagi commented 8 years ago

Actually I don't know any downside, but I'm not a system expert :) This is the configuration used at SensioLabs/Blackfire. You can find a great post about it here: http://blog.blackfire.io/how-we-use-docker.html (Now have to be tweaked for docker-machine, but that's the exact same thing)

tonivdv commented 8 years ago

Thanks for the article. I'll investigate the -network option. Now I'm almost done with #17 , which automatically adds a solution for this too.

ckortekaas commented 8 years ago

For what it's worth adding an entire C class (even private) subnet isn't such a great idea for some use cases. For example my organisation uses the entire private ranges up, 192., 10. and 172.* (a large university). So if the default sharing behaviour was this wide it could open up a share far too much for developers who don't understand networking very well.

Also it seems like docker-machine doesn't seem to change the ip between restarts, even though it warns you it might. Even destroying the vm and creating a new one seems to reuse the same ip every time.

tonivdv commented 8 years ago

For what it's worth adding an entire C class (even private) subnet isn't such a great idea for some use cases. For example my organisation uses the entire private ranges up, 192., 10. and 172.* (a large university). So if the default sharing behaviour was this wide it could open up a share far too much for developers who don't understand networking very well.

That's what I was afraid off.

Also it seems like docker-machine doesn't seem to change the ip between restarts, even though it warns you it might. Even destroying the vm and creating a new one seems to reuse the same ip every time.

Unfortunately that's not the case :( ! Assume you created and start a 'machine', you will be default get the ip 192.168.99.100 . If you create and start another machine, it will get 192.168.99.101. If now you stop both, and you first start the second created machine, it will now get the ip 192.168.99.100 .

I got this a lot but found a work around while reading issue https://github.com/docker/machine/issues/1709:

192.168.98.100
docker-machine create -d virtualbox --virtualbox-hostonly-cidr "192.168.98.1/24" m98

192.168.97.100
docker-machine create -d virtualbox --virtualbox-hostonly-cidr "192.168.97.1/24" m97

192.168.96.100
docker-machine create -d virtualbox --virtualbox-hostonly-cidr "192.168.96.1/24" m96

If there's no other machine with the same cidr, the machine should always get the .100 IP upon start.