Sort of like this thread: Upstream with service tags
In my environment, we have hundreds of environments. We want to be able to specify that services within one environment can find other instances of the same service within that environment. Before consul, we’ve used a subdomain to manage this, e.g. rx3-someservice.testing.covermymeds.com routes only to the instances of someservice within the rx3 environment.
I can see that we could give our services some ServiceMeta like environment=rx3, then create a prepared query using regexp+templating to resolve rx3-someservice to someservice where ServiceMeta.environment == rx3
However, my hunch is that using a prepared query precludes me from being able to use the L7 routing features (something I also want to take advantage of). If that isn’t true, I would love some information about how those features interact with each other (does the prepared query come before L7 routing? After?)
If not, the suggestion was to use a service resolver. Is it possible to force a service resolver from the upstream definition? i.e. for my rx3 instances, I would define my upstreams as pointing to the rx3 subset.
Otherwise, I’m not quite sure how to make this work. I can see that generally you’re meant to use a service-router to select the appropriate subset, but in my case there are no query parameters, headers, or path elements that would indicate the right subset. I need to define the criteria at the upstream definition level rather than by selecting something about the query my app is producing.
One thought I had was to define the upstreams with a prefix, sort of like how the prepared query interface works, and then use a regex within the router definition. e.g.
Name = (.*)-(.*)
Destination {
Service = "${Matches[2]}"
ServiceSubset = "${Matches[1]}"
}
