I have a question regarding DNS and consul : I have two datacenters up and running, both hosting a mesh gateway and two services, use case is pretty simple : I want serviceA-dc1 to be able to talk to serviceB-dc2 through the DNS name ( e.g. , from my serviceA-dc1 , typing something like curl serviceB-dc2.service.dc2.consul) but this hostname is resolved by the local IP of my service (10.6.0.2) and obviously serviceA-dc1 doesnt have this route.
I’m well aware of the upstream mechanic but I am pretty sure I am missing something, is it really the only way to have a proper cross-dc communications between my envoy-proxies ?
You will need to configure your application to connect to the address (typically localhost / 127.0.0.1) and port that you declared when you defined the upstream for your service.
There is a feature request for Consul to make proxies discoverable via DNS.
I recommend upvoting the issue to express your interest, and subscribing to it to stay updated on the status of that request.
So as I understand, from a given service I have no other choice than mapping an upstream per service I want to reach. That implies configuration to be changed dynamically (e.g. my service now requires a new database so I have to update my service configuration)
I tried to have a specific container that would register all of my service definition/configurations to the agent of dc1 but I noticed that service resolvers (even though they include a datacenter and the agents cross dc are federated) are still registered to the agent of dc1:
kind = "service-resolver"
name = "mysvc"
redirect {
service = "mysvc"
datacenter = "dc2"
}
Would still be registered on dc1, when mysvc tries to register to the agent of dc2 with :
consul connect envoy -sidecar-for mysvc
But I get the following
==> No sidecar proxy registered for mysvc
Is there any way to centralize proxy configurations as well as service definition cross dc?