Containers accessing each other

[subpardaemon]

Hi,

We have a problem here when compared to dinghy: whereas in a virtualbox/docker-machine/dinghy configuration, services in separate containers are able to access each other just by specifying VIRTUAL_HOST, in a Docker for Mac/dory setup I have to additionally specify explicit links between each other, with external_links, like:

  hub:
    external_links:
      - dory_dinghy_http_proxy:firefox.docker
      - dory_dinghy_http_proxy:testrunner.docker

For some reason the default seems to be a restrictive proxying policy. Is this a bug? Is there an option to set this?

Thanks!

[FreedomBen]

Hi @subpardaemon ! There is no reason for the restrictive proxying policy. I've been all consumed with client work (which is a good problem to have during this economy) and haven't been able to test out possible solutions.

I would be very open to a PR to fix this issue. Given that it's hurting people, if nobody is willing/able to send a PR I'll try to give it some attention soon.

Also see #36

[subpardaemon]

actually, i've done some digging, and it looks like a docker-machine vs docker for mac issue, as a colleague who uses dfm and dinghy-http-proxy experienced the same problems.

it looks like the network policy of docker-machine is fundamentally different from both docker daemon (linux) and dfm.

unless explicitly stated, anything.docker by default is resolved to 127.0.0.1 within containers. this is in line with the dns resolution being done by dnsmasq on the host machine, as that also resolves to 127.0.0.1. now, however, if external_links is used, name resolution is affected as something.docker becomes an alias to dory_dinghy_http_proxy.mynetwork_default, which points to an ad-hoc created address within the container's host network.

i don't know what docker-machine does regarding routing, but i'll check with a few colleagues who work with that.

[tedivm]

I got this working. The trick is to add an alias to 127.0.0.1 on the host machine and then use that alias ip address for the DNS resolver. The containers will see that the IP address isn't local and route up to the host, and then the host will capture and redirect.

So this one liner-

sudo ifconfig lo0 alias 172.17.0.1

And then update your dory config-

  dnsmasq:
    enabled: true
    domains:               # array of domains that will be resolved to the specified address
      - domain: docker     # you can set '#' for a wilcard
        address: 172.17.0.1 # return for queries against the domain

Now the containers will get 172.17.0.1 as their result and will route to the proxy container.

[subpardaemon]

@tedivm 's solution works. however, it causes another issue, see in this thread: https://apple.stackexchange.com/questions/386721/how-to-stop-mdnsresponder-from-using-90-100-cpu-continuously-forever-on-catalin . and this particular issue hit us after we started using the localhost alias method.

we're now stuck between the proverbial rock and the hard place. @FreedomBen , is there a chance to solve this without the localhost aliasing? it should not be that difficult, given that the resolver can still reside without issues on 127.0.0.1 and maybe the web proxy could be used from a docker-native IP address?

[subpardaemon]

i have found a solution that is much better than "external_link"-ing all stuff and is not dependent on the localhost alias method. it has a shortfall -- there is no WHATEVER_PORT to 80 mapping, and requests do NOT go through the dory_http_proxy (so no https certificate etc), but name resolution works.

services:
  webone:
    image: nginxdemos/hello
    environment:
      VIRTUAL_HOST: webone.docker
    networks:
      default:
        aliases:
          - webone.docker
  webtwo:
    image: nginxdemos/hello
    environment:
      VIRTUAL_HOST: webtwo.docker
    networks:
      default:
        aliases:
          - webtwo.docker

so, essentially, it creates an alias to the service under the same hostname. it does not work for wildcard domain names, it does not work if the exposed service is not on port 80 (unless you do some extra work and differentiate between internal (from-container) and external (from host, like browser) usage.

[subpardaemon]

I got this working. The trick is to add an alias to 127.0.0.1 on the host machine and then use that alias ip address for the DNS resolver. The containers will see that the IP address isn't local and route up to the host, and then the host will capture and redirect.

So this one liner-

sudo ifconfig lo0 alias 172.17.0.1

And then update your dory config-

  dnsmasq:
    enabled: true
    domains:               # array of domains that will be resolved to the specified address
      - domain: docker     # you can set '#' for a wilcard
        address: 172.17.0.1 # return for queries against the domain

Now the containers will get 172.17.0.1 as their result and will route to the proxy container.

A quick update to this: Compose V2 networks have stricter isolation and peg the 172.17.0.1 address as a possible Compose network address thus filtering it between containers. This makes it impossible to call through the proxy from a container to another. The fix is simple, though. Just not use the private IP address range that Docker Compose might recognize as a Compose network address. Choose an address from the 192.168.x.x range or the 10.x.x.x range for your localhost alias address and Dory should be working fine again.