Sudo chown root:wheel /Library/LaunchDaemons/co. # It copies a plist script to /Library/LaunchDaemons and enables it via launchctl, # so that this alias will be added automatically at boot time in future. # This adds an alias IP to the lo0 interface of the host. #!/usr/bin/env bash # Docker containers that wish to access services running on the host (this mac) # need a known IP address for the lo0 interface, 127.0.0.1 will not work. However, there is a recommended solution: you can add a new IP address to the hosts’ lo0 interface, and access services running on host localhost via that new IP. The default loopback interface ( lo0, 127.0.0.1) isn’t available from within Xhyve-based Docker for Mac containers either. Also, if you have no network access, the interface is inaccessible. Now, you could choose to run host services on all network interfaces ( 0.0.0.0), and point containers to the current IP of the host’s en0, but this requires that you be able to reconfigure your containers every time your mac’s IP changes, and it exposes your host service to your local network. It turns out that this needs a little extra network config on the host. For the proxy to route requests to upstream services, I needed to find an accessible, consistent network interface on the host. I expanded the stack by adding adding a web proxy container, to mimic our production traffic routing locally.
We have traditionally run ruby and nodejs services on our macs, and connected to virtualized databases, which now run in containers. Update: This workaround is no longer necessary as of Docker for Mac version 17.06, which provides a special Mac-only DNS name, which resolves to the internal IP address used by the host.Ī few months ago, I built out a docker-compose-based local development environment for our dev team who had been using a long-in-the-tooth vagrant-based environment to run backend databases.
0 kommentar(er)
