hashicorp / consul

Consul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.
https://www.consul.io
Other
28.41k stars 4.43k forks source link

Consul translate_wan_addrs not working #5225

Open hemachandsai opened 5 years ago

hemachandsai commented 5 years ago

Hi,

We are trying to split our backend architecture into micro services with api-gateway consul. I had tried to setup consul server and two clients. Whenever i fire a dns query from my localmachine to aws instance(server) with query name as servicename.service,consul it always resolves to that instance private ip.I had passed translate_wan_addr to true that didn't help,Then i had also tried passing the public ip with advertise-wan flag then it is being show in api response as tagged wan address but even then the dns response resolves to private ip.Here are the follwing attachments that might help. api dns

hemachandsai commented 5 years ago

One workaround i found is to place the public ip manually in service config under adress as key. Then it resolves to public Ip i had mentioned but this doesnt address my issue as the public IP is not static.

mkeeler commented 5 years ago

@chandu379 I think this might be a case of unclear documentation. On the DNS side of things the translate_wan_addrs configuration will cause return the wan address of the node only if making a cross DC request.

So if you have two datacenters dc1 and dc2 and you lookup webslave.service.dc2.consul against a consul instance configured to be in dc1, then the addresses returned will be wan addresses. If you make the same query against an instance configured to be in dc1 then the lan address gets returned.

Currently it looks like there is no way to retrieve the wan address via DNS the way you want to do it.

hemachandsai commented 5 years ago

Thanks for the reply @mkeeler If that is the case please help me with these:- 1)If we have consul sever and client sitting in same dc, then when a app makes a request to consul server it checks the dns registry and responds the feasible service corresponding to the query 2)If we cannot return the wan IP how can a outside client communicate with the service residing along with consul agent? I hope i made it clear enough!

hanshasselberg commented 5 years ago

The solution to the outside client problem is usually some kind of load balancer or proxy, that provides access to these instances that are not available to the outside client.

mkeeler commented 5 years ago

@chandu379 To elaborate on what @i0rek said, a typical use case is to run a load balancer or proxy to take wan traffic and give it to the right service (potentially splitting traffic among various instances of the same service). The load balancer/proxy would have LAN access and could use Consul's DNS to determine where to make its connections.

However, I can see the utility in having the ability to expose WAN addresses via DNS to outside clients.. I am marking this as an enhancement request for now and will leave the issue open for any further comments from yourself and the community as a whole.

hemachandsai commented 5 years ago

Thanks for the help.

hemachandsai commented 5 years ago

A small query though:- I read from hashi corp webiste that consul also does those few of loadbalacing stuff(like calculations seeing which instances received more traffic and resolving to others accordingly and also few of latency calculations). Iam thinking may be if the backend architecture is not so huge, we can also leverage consul as a load balancer as it had good knowledge regarding the active services.It would be great if it can resolve local service ip's to their public ip's so that users can reach it directly without a need of load balancer. Thanks again for your support !!

mkeeler commented 5 years ago

I agree that in that case it would be advantageous to have a way to get the services public IP via DNS.

I think the best way to accomplish this would be with updates to prepared queries. We could add a prepared query configuration for which tagged address to use when the query is being executed via the DNS interface. The query could look like:

{
  "Name": "my-query",
  "Service": {
    "Service": "foo",
    "OnlyPassing": false,
  },
  "DNS": {
    "TTL": "10s"
    "TaggedAddress": "wan"
  }
}

This would require creating prepared queries (or prepared query templates) for the services you would want to expose but I think it would be the preferred solution to trying to find a way to fit tagged addresses into the fqdn in the DNS interface.

This does not currently exist in the prepared query language but shouldn't be too hard of an implementation. At this time the Consul teams' priorities are going to be on other things but we would be happy to have someone in the community submit a PR for it.

hemachandsai commented 5 years ago

@mkeeler i would love to do that and of done this would be my first contribution to open source community.Can you please help me out to get this kick started(i mean the areas of the source code i have to start exploring)?

hemachandsai commented 4 years ago

Hope, you are doing well. In case we are using consul with a load balancer or a proxy as suggested by @i0rek, I guess we have to use consul templates to sync available node config with the proxy or lb. In this scenario how will the proxy or lb retrieve the public IP's of available nodes from consul catalog? Is this a special scenario where the template would be able to retrieve public IP's for non cross dc located services I mean the ones with in the same dc?

Peter2121 commented 3 years ago

A possibility to retrieve WAN addresses, configured for services, would be interesting for us too. The idea is to use Consul to manage public DNS records for load-balancers (reverse proxy), so when Consul detects that a reverse proxy service is dead - the public DNS zone would be changed to avoid connecting clients to this reverse proxy. It could be achieved rewriting public DNS queries and redirecting them to Consul. The problem is that Consul returns private IP addresses...