1

We use nomad to deploy our applications - which provide gRPC endpoints - as tasks. The tasks are then registered to Consul, using nomad's service stanza.

The routing for our applications is achieved with envoy proxy. We are running central envoy instances loadbalanced at IP 10.1.2.2.

The decision to which endpoint/task to route is currently based on the host header and every task is registered as a service under <$JOB>.our.cloud. This leads to two problems.

  1. When accessing the service, the DNS name must be registered for the loadbalancer IP which leads to /etc/hosts entries like

    10.1.2.2 serviceA.our.cloud serviceB.our.cloud serviceC.our.cloud

    This problem is partially mitigated by using dnsmasq, but it is still a bit annoying when we add new services

  2. It is not possible to have multiple services running at the same time which provide the same gRPC service. If we e.g. decide to test a new implementation of a service, we need to run it in the same job under the same name and all services which are defined in a gRPC service file need to be implemented.

A possible solution we have been discussing is to use the tags of the service stanza to add tags which define the provided gRPC services, e.g.:

service {
  tags = ["grpc-my.company.firstpackage/ServiceA", "grpc-my.company.secondpackage/ServiceB"]
}

But this is discouraged by Consul:

Dots are not supported because Consul internally uses them to delimit service tags.

Now we were thinking about doing it with tags like grpc-my-company-firstpackage__ServiceA, ... This looks really disgusting, though :-(

) So my question is:

  • Has anyone ever done something like that?
  • If so, what are recommendations on how to route to gRPC services which are autodiscovered with Consul?
  • Does anyone have some other ideas or insights into this?
  • How is this accomplished in e.g. istio?
DaDaDom
  • 532
  • 6
  • 16
  • It is totally fine to have dot in tags. It is discouraged in consul docs because consul dns interface lets you resolve service names based on tags so something like reader.database.service.consul is fine but reader.2.database.service.consul is problematic because now consul has no way to know of you want to the db instance with tag reader.2 or with tags reader and 2. – Gufran Feb 25 '20 at 17:54

0 Answers0