dory

dory copied to clipboard

Hi,

Dinghy for OS X, has a feature where you can connect back to your host machine from within a docker container.

https://github.com/codekitchen/dinghy#dns

You can also connect back to your host OS X machine from within a docker container using the hostname hostmachine.docker. This connects to the virtual network interface, so any services running on the host machine that you want reachable from docker will have to be listening on this interface.

We have multiple microservices running on different networks, when one of my backends tries to communicate with another I get this error - cURL error 6: Could not resolve host: microservice-2.docker (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)

I am using Ubuntu 18.04.

All my coworkers use MacOS with dinghy and it works for them.

Is there a way to make this work with dory?

Thank You

Hey @akki-io . Sorry for the delayed response. I skimmed your question when you posted it but then got busy and forgot to follow up. Apologies.

The way I always handled services calling each other was using the container name. It is annoying to have different hostnames depending on whether you are on the host or in a container tho.

It shouldn't be that hard to get something working tho. I will think on it a bit. Is this something you are still trying to get working?

First, Thank you for your work on dory! We are also very interested in this feature. It would be great if you find a solution.

To make sure I understand how it would need to work, is the following statement accurate?

hostmachine.docker should resolve to the host machine's IP address on the docker interface for the particular docker network.

This wouldn't allow you to use someservice.docker from two different docker networks, but it would allow you to access any service running on the host machine that are bound to that network interface (in practicality this would be anything bound to 0.0.0.0).

I need this feature too. Let's say, we have 2 services: serviceA.docker and serviceB.docker. Accessing these services from the host's browser is ok. But when they try to connect to each other, that's the problem. ServiceA.docker cannot resolve the ServiceB.docker address, and vice versa.

I can work around the issue by adding an "extra-hosts" in the docker-compose.yml like this:

    extra_hosts:
      - "ServiceB.docker:${HOSTIP}"

However, it's cumbersome and require everybody to put their own $HOSTIP in the .env. It'd be great if dory can do that automatically.

Thanks @ltvan . I have an idea of something we can try.

I was also investigating this issue in the last couple of days.

This works properly with dinghy because dinghy sets dinghy-http-proxy's dnsmasq to resolve *.docker hostnames to the docker's virtual machine ip address which is in that setup accessible from the host machine and the containers also. In every other cases (Linux, Docker for Mac) dinghy-http-proxy's dnsmasq is configured to resolve *.docker hostnames to 127.0.0.1, which works properly on the host machine since it access the proxy's published port on localhost, but doesn't work inside a container because the container itself cannot access the http-proxy on localhost.

Anyway if you want a fast workaround you can set dnsmasq from dory's configfile to resolve everything to your host machine's ip (which is also accessible from the containers) this setup would be able to handle domain names from the both host machine and from the inside of the containers.

Anyway if you want a fast workaround you can set dnsmasq from dory's configfile to resolve everything to your host machine's ip (which is also accessible from the containers) this setup would be able to handle domain names from the both host machine and from the inside of the containers.

The way dinghy seems to work is that it defines a subnet for its own services (something like 192.168.99.0/24) on the host and the proxy server runs on that. Since the default networking policy is for the containers to see the whole of the host network, and *.docker is proxied via a host in this network, it means the IP address *.docker resolves to is visible and connectible from within the containers.

Dory on the other hand resolves to 127.0.0.1 which is always routed to the lo network interface within the containers. However, external_links allows tying dory_dinghy_http_proxy into the local network where it gets an address of its own within the local network.

There are two problems with this approach:

• it necessitates writing extra "external_links" parts in the docker-compose yamls
• since dory_dinghy_http_proxy becomes tied to the compose network, using --remove-orphans blocks network removal -> I've just had a headscratcher for the last 3 hours just because of this

Setting the IP to the local IP is a temporary solution at best as that keeps changing from time to time. The best solution would be to open our own local subnet for the proxy (maybe even for dnsmasq) and use that instead of 127.0.0.1.

Or, as an alternative solution, address: !host (or something like this) could make it so that dory uses the host IP as an address, and would restart dory whenever this IP changes. One thing is for sure, 127.0.0.1 from within the containers will not work, and should not work either.

I posted a somewhat simple solution to this in another issue-

https://github.com/FreedomBen/dory/issues/39#issuecomment-884417408