[feature] Allow discovery to check against existing services in Consul

[gpaggi]

All of our services already register in Consul, together with their health check (script), for service discovery.
I'm looking into deploying them with Nomad but run into an issue with the discovery implementation.

It would be great to be able to configure Nomad, in the service key, to not register the service in Consul and check against an existing health check in Consul. Something like:

service {
  register = false
  check {
     type = "consul"
     serviceId = "mock-test-${NOMAD_ADDR_http}'
  }
}

I'm sure there are other people already using Consul for service discovery who would end up with registering services twice if they were using the current Nomad integration with Consul...

[dadgar]

If your applications are already registering with Consul, then can you not just omit the service block from Nomad?

[gpaggi]

If I do, how is it Nomad going to determine the health of the service? From what I've seen, if I omit the service block, Nomad will only monitor the PID of the service, with no knowledge about its actual health.

[dvusboy]

@dadgar: Put it another way, consul is not meant to take action on the outcome of these checks, but nomad is.

[dadgar]

Currently Nomad registers and deregisters the service/checks but does not use that information while scheduling. Down the line there will be deeper integration (only do a rolling upgrade when the app is healthy, etc). But I understand your ask. I will mark it as an improvement but until we have deeper integrations the net effect can be reached by not having the service block defined in your job.

[gpaggi]

@dadgar Thanks. I was under the impression that Nomad would leverage Consul for health checking after registering the services, but I understand now that's not the case; I'll skip defining the service block in my jobs for now.
I see #876 is open for something similar, albeit for the Docker driver.