Add more documentation about how nomad and consul works together

[F21]

There are some bits here and there in the docs talking about how consul can be used for service discovery, however it's unclear how it all fits together.

There should be more information regarding this, and perhaps an example cluster where nomad and consul is set up in tandem.

[zrml]

• 1

[sielaq]

I suspect they do not work together yet, but it would be awesome to not to use registartor for that.
+1

[ryanuber]

This integration is in the works and should be functional soon! We will definitely include detailed documentation on the specifics.

[bhameyie]

+1

[djsly]

👍

[defender]

+1

[raykrueger]

👍 Definitely interested in this.

[Dahs81]

👍

[maxenglander]

👍

[defender]

+1

[adamveld12]

👍

[zanedeg]

+1

[marcelocorreia]

+1

[c4milo]

I'm very much looking forward to having this.

[dadgar]

Here you guys go: https://www.nomadproject.io/docs/jobspec/servicediscovery.html

[F21]

@dadgar Are there still any plans to let nomad manage consul?

[dadgar]

@F21: Not in the sense that we will have the Nomad client download or even launch Consul during startup. Instead we will be advocating the usage of a System job that schedules Consul on every node. We will hopefully be able to write a tutorial on this in the near future.

[F21]

@dadgar In the case of running consul as a system job, would consul be in a docker container (with host networking) or would consul be run using exec?

[ketzacoatl]

I think the docs are clear @F21: it's up to the operator to make that all work - and depending on the details in your setup, either could work.

[dadgar]

@F21: Yeah it will depend on your use case. If you are doing script based health checks then possibly with a raw_exec. If you aren't then docker or exec would both work but with docker you would have to set up networking correctly.

[sielaq]

I have created small playground,
so you have all pieces (Scheduler/ServiceDiscover/Proxy-LoadBalancer) in one box
https://github.com/eBayClassifiedsGroup/KomPaaS
enjoy

[ghost]

+1

[borice]

The documentation explaining how Nomad and Consul work together still sucks. Specifically, how you get a nomad service to be found by a different service that depends on it (and get the address and port number that nomad allocated, etc)

These pages need to be improved to explain this, and include examples:
https://www.nomadproject.io/docs/service-discovery/index.html
https://www.nomadproject.io/docs/job-specification/service.html

[c4milo]

@borice if you already know, I'm sure we would all appreciate a PR from you improving the docs :)

[borice]

@c4milo i don't already know... i was trying to learn, but hit a dead end.
It's all trial-and-error for me now.

[borice]

For completeness, I'm trying to understand the following:

I have a nomad service running a mongodb docker container on a random port assigned by nomad.
I have a separate nomad service running an app (perhaps on a different nomad node in the nomad cluster), which needs to be told where the mongodb lives to be able to connect to it.

How do I tell the app in its "service" stanza about the mongodb service? (host and port)

[c4milo]

@borice try what's documented in https://github.com/hashicorp/consul-template#service, since Nomad's template language follows closely consul-template's.

[sielaq]

@borice you have few choices:

1. use proxy/LB thats gonna expose you the static port or domain (https://github.com/eBay/Fabio)
2. your app can talk to consul directly to get ports (many libraries are available)
3. you can start app with consul-template as suggested by @c4milo
4. or you can simply use consul DNS to resolve it, in you startup script.
   for example (assuming that you have consul as a domain, and you have DNS configured with consul):
   PORT=$(dig +short SRV mongo-1.service.consul | cut -d \ -f3)
   assuming that you don't have DNS configured with consul, and consul IP is 192.168.1.1:
   PORT=$(dig +short @192.168.1.1 -p 8600 SRV mongo-1.service.consul | cut -d \ -f3)

but options 3. and 4. are not optimal - whenever your DB gonna be restarted - a different port gonna be chosen
so your app would have to be restarted
if you enforce a static port in nomad - this might work - and thats the desired solution.

If you still prefer to have random ports in nomad's workers, option 1.would be the best:

1. you'r app is agnostic from consul
2. you always have a specific static port on LB (or domain - depends how you gonna balance: layer 4 or 7 - you can choose it in Fabio)
   so in worst case scenario, your app just need to reconnect.

[github-actions]

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.