The most portable option is still to run your container with the IP address injected as a configuration, e.g. If you want your external/internet address, you can query a remote service like: curl Įach of these have limitations and only work in specific scenarios.
If you are running in a cloud environment, you can check the metadata service from the cloud provider, e.g. With the 20.10 release, the alias can also work on Linux if you run your containers with an extra option: docker run -add-host :host-gateway. *$/\1/p'"įor current versions of Docker Desktop, they injected a DNS entry into the embedded VM: getent hosts | awk '' *$/\1/p'Īn example showing this with host networking in a container looks like: docker run -rm -net host busybox /bin/sh -c \ From this question the following works for me e.g.: ip route get 1 | sed -n 's/^.*src \(*\).
If your container is running with host networking, then you can look at the routing table on the host directly to see the default route out. There are different options depending on your specific situation: The network is namespaced to just that container by default, and details of the host are protected from the process running inside the container which may not be fully trusted. Why would this be so difficult? Because containers will, by design, isolate the application from the host environment. Allowing the user to inject this gives you the most portable design. as an environment variable or config file. Instead you have the person running the container inject an external hostname/ip address as configuration, e.g. The standard best practice for most apps looking to do this automatically is: you don't. Make sure the IP you use doesn't conflict with something on your own network. That's why I used 192.168.* in the example above. In my case, this showed inet 127.0.0.1/8 which means I couldn't use any IPs in the 127.* range. So check the loopback interface inside the container if you have trouble: sudo ip addr show lo One thing to be careful about is that the docker container won't send traffic to the parent host if it thinks the traffic's destination is itself. When you are finish using this IP, you can remove the loopback alias like this: sudo ifconfig lo0 -alias 192.168.46.49 Now when traffic comes into your Mac addressed for 192.168.46.49 (and all the traffic leaving your container does go through your Mac) your Mac will assume that IP is itself. In my case I wanted to connect to a remote xdebug server: telnet 192.168.46.49 9000 You can then test the connection from within the docker container with telnet. This is of course a pain if this IP address ever changes, but you can add a custom loopback IP to your Mac that the container doesn't think is itself by doing something like this on the parent machine: sudo ifconfig lo0 alias 192.168.46.49 This should show you the IP of your Mac on its current network and your docker container should be able to connect to this address as well. For example if you run this from the parent machine run: ipconfig getifaddr en0
All outgoing traffic however, is routed through your parent host, so as long as you try to connect to an IP it recognizes as itself (and the docker container doesn't think is itself) you should be able to connect. On Docker for Mac the docker0 bridge does not exist, so other answers here may not work. For prior versions of Docker for Mac the following answer may still be useful: Update: On Docker for Mac, as of version 18.03, you can use as the host's IP.
0 kommentar(er)
