Currently `yarn start` (which uses the webpack-devserver) doesn't work from inside the Vagrant VM, since: a) It binds to port 5000 which isn't exposed via virtualbox port forwarding b) It binds to the loopback adapter rather than 0.0.0.0, so even with port forwarding set up wouldn't work anyway The only reason (b) doesn't also affect Django runserver/gunicorn, is that varnish is being used inside the VM like so: Host port forwarding of port 8000 (bound to loopback only) -> guest port 80 (where varnish is listening on all adapters) -> forwarded to port 8000 on loopback adapter One option would be to use varnish to reverse proxy both the Django and webpack side, however: * that wouldn't work nicely with docker in the future * it would mean having different proxy configs for the "full stack vagrant" vs "develop UI only outside vagrant by pointing to stage/prod" use-cases * it's yet another package to install/config as part of provision A better option is to remove varnish entirely and directly connect to runserver/gunicorn/webpack-devserver from the host. Unfortunately overriding the bind address from 127.0.0.1 to 0.0.0.0 for each of these is a pain, since: * for runserver you either have to add a CLI option every time or add a custom runserver command (see https://code.djangoproject.com/ticket/27537) * for gunicorn you can set the `PORT` environment variable (which also changes the bind host to 0.0.0.0), however webpack-devserver then picks this up too, so requires more hacks to stop them clashing * for webpack-devserver, if you bind to 0.0.0.0 you have to set a bunch of other options so it knows the real hostname, which is a pain with neutrino v4. Plus you then have to make sure you don't bind to 0.0.0.0 in the "running outside of Vagrant" case, since that would be insecure. As such for now the easiest way to solve this looks to be a hack involving iptables to route all incoming traffic to the loopback adapter.

Comment on attachment 8864944 [details] [treeherder] mozilla:vagrant-port-forwarding > mozilla:master Wow, this is really intricate! Thanks for remedying this!

Commits pushed to master at https://github.com/mozilla/treeherder https://github.com/mozilla/treeherder/commit/4735e9d4341bc70350da6d9990b37a7770e21383 Bug 1362443 - Vagrant: Replace varnish with iptables rule By default webservers like Django's runserver, gunicorn or the Webpack devserver only bind to the loopback adapter (127.0.0.1) and so are not accessible from outside the Vagrant / virtualbox VM, since port forwarding only forwards traffic to the non-loopback adapters. Previously varnish (which listened on `0.0.0.0`) was reverse proxying traffic to runserver/gunicorn, however we need to now do so for webpack-dev-server on another port too. Doing both with varnish adds complexity, and we don't actually need any of varnish's other features, so ideally want to stop using it. Rather than having to override each webserver to bind to all adapters (using the IP `0.0.0.0`), it's possible to forward traffic to the loopback adapter using iptables NAT PREROUTING rules. This is still secure so long as the Vagrantfile port forwarding uses a `host_ip` of `127.0.0.1`. To prevent this "Martian packet" traffic from being blocked, `route_localnet` must also be set to `1`. See: https://unix.stackexchange.com/questions/111433/iptables-redirect-outside-requests-to-127-0-0-1 By default neither sysctl or iptables settings are persisted across reboots, and fixing that requires more complexity (eg installing the iptables-persistent package and handling config changes during provision). As such, it's just easier to re-run the commands on each login since they take <30ms. https://github.com/mozilla/treeherder/commit/6da808245d0330ef733356f67e0bc6f964954b46 Bug 1362443 - Vagrant: Forward port 5000 for webpack-dev-server This allows running the dev server from within Vagrant, in case people don't have a nodejs environment on the host. After this lands users must run `vagrant reload --provision` to pick up the changes to `Vagrantfile`.

I've posted to the Treeherder mailing list about the need to `vagrant reload --provision`: https://groups.google.com/forum/#!topic/mozilla.tools.treeherder/VTMQ_XH1j7o