Easy Networking with Vagrant and VirtualBox

From Wiki4Intranet
Jump to: navigation, search

When we are playing with vagrant boxes on VirtualBox, we should use three network adapters for each box. What, why, what problems and how to deal with it? Lets discuss.

NAT

  • NAT-adapter, should be everyone by default.

Vagrant box with NAT

  • can see external internet
  • isolated from any other vagrant boxes
  • can be accessed outside only by portforwarding throught host box. That is "control" SSH port of guest mapped to some (2222 or other unpriviliged) port of host, 80-guest to 1080-host, etc. So website inside guest box can be accessed by http://localhost:1080.

You can ask vagrant about these ports:

>vagrant port  tms-ubuntu                                                                                                          
The forwarded ports for the machine are listed below. Please note that                                                                                                       
these values may differ from values configured in the Vagrantfile if the                                                                                                     
provider supports automatic port collision detection and resolution.                                                                                                         
 
    22 (guest) => 2206 (host)                                    

Vagrant manages SSH-ports, trying to avoid collisions, so you can always get inside guest box by «vagrant ssh» without any knowledge about port forwarding. Vagrant also used NAT-adapter and this SSH-port for provisioning-by-ssh (shell, ansible, …). But you should manage all other ports.

Pro
  • NAT-adapter always available[1];
  • Simple and enough for simple web project with one external web-port.
Contra


Private network

Internal virtual network for bunch of guest boxes inside host.

Pro
  • Here we can get several interacted boxes ("db"-role, "webapp"-role, "mock-testing"-role…) — they can see each other and external internet.
Contra
  • We have to manage networking for guest boxes:
    • IP-addressing — to give guest boxes non-intersecting IP-addresses
    • DNS — give a names to box and make that all guest boxes know each other.
  • Guest boxes can be accessed from host, but invisible outside — impossible to get access[2] to these boxes from LAN — for demo, testing, bug investigation, etc.

Public network

Actually, network bridge with one of host network adapters[3].

Pro
  • IP-address get get from DHCP-service on local, corporate or home network.
  • Can expose guest box on local network — demo, bug-hunting, even some useful public service.
Contra
  • For intercommunication of vboxes private network more useful than public. Because we can manage names/IP-addresses and vbox IPs are independent from unstable DHCP. So public network should be addition, not substitution of private one.
  • For bridging with Vagrant we have to know external network adapter name. Yes, it possible to specify Vagrant several network adapters, but impossible to use regexps or wildcards. So impossible to enoumerate
  • Для бриджевания, надо знать название адаптера. Ну, на самом деле там можно предложнить на выбор несколько названий адаптеров, но сейчас же в каждом дистрибутиве линукса свой принцип формирования имен. И он динамический! Нельзя использовать wildcardы, сказать, блин, забриджуй меня хоть с каким-нибудь первым попавшемся работающем ethernetом, будь он хоть "eth0", хоть "eth31", хоть «enp0s31f6»[4], а ведь еще винда у некоторых… Аналогичная проблема при разворачивании сделанных packerом образов на машинах пользователей — там она тоже будет настойчиво просить выбрать адаптер.
  • По умолчанию, созданные vagrant-ом виртуалки, даже забриджованные с реальным сетевым адаптером, почему-то не видны из других сегментов локальной сети! Т.е. если вдруг достался IPшник 10.200.9.70, то виртуалка будет видна из 10.200.9.nnn, но не видна даже из 10.200.8.*.

WTF??!!


References

  • Can be disabled if we specify "adapter=1" in specification of any other guest network adapter. But why?
  • Without ssh-tunnels-portforwarding etc
  • Usually with ethernet-adapter, because most desktop has no WiFi, and most WiFi-adapter cannot be bridged.
  • Это вот у меня сейчас тут
  • [ List view ]Comments

    (no items)

    Please login to comment.