3 ms·

Docker is a fragmented mess network wise if you need to support developers on both windows and macOS. Also, docker requires hyper-v and admin privs on Windows.

Docker is a fragmented mess network wise if you need to support developers on both windows and macOS. Also, docker requires hyper-v and admin privs on Windows. And you can't run VirtualBox with hyper-v active so you need to choose either of the two options. Granted, you could run Docker in virtualbox but it wouldn't be very clean.

spilk 9y ago
The whole Hyper-V thing with the default Docker for Windows stuff has put me off - is there a workaround to go back to using a VirtualBox VM again? I do a fair amount of development on Windows machines along with Mac/Linux so I need something that works consistently among all those platforms. Vagrant is filling the void for some of those projects since it just works with no fuss on Mac/Windows/Linux without forcing me to use Hyper-V.
- tmzt 9y ago
  You can still run Docker Machine (part of the old Toolbox) for VirtualBox support. minikube/minishift can also be used as docker VMs and download up to date iso images automatically.
- yebyen 9y ago
  Absolutely, you can boot your preferred distribution for running Docker on[1] (using Vagrant even! setting the provider to VirtualBox), forward the port that Docker is running on (2376?) to your physical host/localhost[2], and set a few variables on the client machine to get your docker client talking to that ("remote") docker daemon[3] [1]: https://coreos.com/os/docs/latest/booting-on-vagrant.html https://coreos.com/os/docs/latest/booting-on-vagrant.html [2]: https://www.vagrantup.com/docs/networking/forwarded_ports.html https://www.vagrantup.com/docs/networking/forwarded_ports.ht... [3]: https://docs.docker.com/machine/reference/env/ https://docs.docker.com/machine/reference/env/ Or, as tmzt mentioned, minikube and minishift will also let you set --vm-driver=virtualbox on start. Those are nice even if you don't want to use Kubernetes (but there are plenty of options.)
yebyen 9y ago
I use Minikube with the VirtualBox driver, and it is the only way that I have been able to deal with my slightly unusual networking requirements and do local dev with Kubernetes. VirtualBox lets you forward ports from within the VM to your localhost directly, bypassing iptables and any default routes. Our network uses a "no-split-tunneling" VPN, so most of the Docker networking solutions are completely unusable for me. Kubernetes fortunately provides easy ways to enumerate the services that you intended to expose (via ingress, or similar) so it's absolutely trivial to script forwarding every exposed service or ingress to the localhost IP. I still am editing /etc/hosts file if I ever need to use a host-based route, and I have some interesting issues with SSL certificates that sometimes did not have the server name that I expected on them, but for the most part this works great for me. I am a Mac user and showed my coworker who is a Windows user, we tried to do the same thing on his machine and it was even easier because there is no notion of privileged ports below 1024. So, it works the same way but with one less workaround.
- yebyen 9y ago
  > only way that I have been able to deal with my slightly unusual networking requirements TBH they are not at all unusual. They are best-practices networking requirements.

spilk 9y ago

The whole Hyper-V thing with the default Docker for Windows stuff has put me off - is there a workaround to go back to using a VirtualBox VM again? I do a fair amount of development on Windows machines along with Mac/Linux so I need something that works consistently among all those platforms. Vagrant is filling the void for some of those projects since it just works with no fuss on Mac/Windows/Linux without forcing me to use Hyper-V.

tmzt 9y ago
You can still run Docker Machine (part of the old Toolbox) for VirtualBox support. minikube/minishift can also be used as docker VMs and download up to date iso images automatically.
yebyen 9y ago
Absolutely, you can boot your preferred distribution for running Docker on[1] (using Vagrant even! setting the provider to VirtualBox), forward the port that Docker is running on (2376?) to your physical host/localhost[2], and set a few variables on the client machine to get your docker client talking to that ("remote") docker daemon[3] [1]: https://coreos.com/os/docs/latest/booting-on-vagrant.html https://coreos.com/os/docs/latest/booting-on-vagrant.html [2]: https://www.vagrantup.com/docs/networking/forwarded_ports.html https://www.vagrantup.com/docs/networking/forwarded_ports.ht... [3]: https://docs.docker.com/machine/reference/env/ https://docs.docker.com/machine/reference/env/ Or, as tmzt mentioned, minikube and minishift will also let you set --vm-driver=virtualbox on start. Those are nice even if you don't want to use Kubernetes (but there are plenty of options.)

yebyen 9y ago

I use Minikube with the VirtualBox driver, and it is the only way that I have been able to deal with my slightly unusual networking requirements and do local dev with Kubernetes. VirtualBox lets you forward ports from within the VM to your localhost directly, bypassing iptables and any default routes. Our network uses a "no-split-tunneling" VPN, so most of the Docker networking solutions are completely unusable for me. Kubernetes fortunately provides easy ways to enumerate the services that you intended to expose (via ingress, or similar) so it's absolutely trivial to script forwarding every exposed service or ingress to the localhost IP. I still am editing /etc/hosts file if I ever need to use a host-based route, and I have some interesting issues with SSL certificates that sometimes did not have the server name that I expected on them, but for the most part this works great for me. I am a Mac user and showed my coworker who is a Windows user, we tried to do the same thing on his machine and it was even easier because there is no notion of privileged ports below 1024. So, it works the same way but with one less workaround.

yebyen 9y ago
> only way that I have been able to deal with my slightly unusual networking requirements TBH they are not at all unusual. They are best-practices networking requirements.