For example, we have a cluster with some different components, the must known each other in order to work properly.
Manually maintain the links between each other is a little inconvenience, and may lead some mistake.
AFAIK, rancher is using a DNS to resolve links, so I want to know if there is some way to reach each other by DNS name within one stack automatically, like SkyDNS for k8s and Mesos-DNS for mesosphere.
The following picture shows a small size deployment of a mongo shards cluster as a example.
On a related note, different scenario, can I specify what the linked to service should be called?
When I setup a link manually, I can give an alias that it would be known as. Using selector links are great when you have a common “catch all” kind of service, but the trouble is that the other services doesn’t know the name of this service (or rather, it is masquerading as someone else), so I need to have an alias per link in place.
Example:
svc_A talks to ext_B.
svc_X works as (or routes requests to another B service).
now I want svc_A to talk to svc_X (but still using the dns name ext_B), this works when I setup a link to svc_X with an alias of ext_B.
The link can be setup using selectors for the above case in a generic and nice way, except for the alias part. But without the alias, svc_A will continue to talk to ext_B regardless of its link to svc_X. (OK, I’m guessing here, but I couldn’t find anything in the docs that says otherwise, will run some tests too).
Followup question: are selector links supposed to work cross stacks?
I have a dead simple test case, but I can’t see that the link works, in any direction, under any name… (but the two services are not in the same stack).
To answer your other question - about the way to specify the alias for the service link when target service joins via selector. Our service Alias (service of kind dnsService) might be helpful in this scenario:
Service A talks to service B that is of kind service Alias (dnsService)
Then as your service B is the alias service, you can put any service behind it (either by creating a service link manually, or make service X join alias service B using selector way)
Ah, thank you, that would be the rancher way of doing things (and I have been doing that, but manually as a layer of abstraction, rather than simply aliasing the service, but it works equally well here). Didn’t realize I could use the selector links with alias service in that way.
I’ll file a issue if/when I have a reproducible test case showing the issue with cross stack selectors. Thus far it could be due to something else…
