Service Discovery Integration #219
Conversation
…ances on the same node
| // can be taken in this back-end. Specifically, the IP address of the Nomad | ||
| // agent does not need to be used, because Consul has this information | ||
| // already and may even be configured to expose services on an alternate | ||
| // advertise address. |
There was a problem hiding this comment.
I may be misreading this but I'm not sure this is a safe assumption to make. Since nomad may be managing tasks across multiple IPs and those services will be bound to a specific interface, the IP is actually important. Even if nomad or consul is listening on a particular IP, tasks are not necessarily registered on the same IP.
| // context can be used from this function for internal node information | ||
| // such as IP address. The allocID can be used to uniquely identify the | ||
| // same task running multiple instances on the same node. | ||
| Register(allocID, name string, port int) error |
There was a problem hiding this comment.
I think we may want a richer struct as well here, so that the entire allocation and task can be pushed in.
|
Closing this out for now - we are thinking of an alternate implementation that will improve on what this PR provides. |
|
Is there any eta for when consul integration will make it into master? |
|
@poll0rz: We will be bringing Consul integration in Nomad 0.2 which is due within the next couple of weeks. We want to get the experience right because it is a critical feature! Thanks for the patience! |
|
@dadgar Is the plan to run consul on top of nomad (essentially managed by nomad) or to run consul along side? |
|
@F21 Nomad will support either workflow but we're aiming to manage it for you by default. |
|
I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
This implements an additional layer on Nomad clients, which can manage registering and deregistering tasks in a discovery back-end like Consul. This includes Consul integration as well.
I think we may be able to make some adjustments here and in other areas to make this experience nicer.
What currently works:
One slightly strange detail is that by default, service registration entries have a long name, like
job1-group1-task1. I've added a field to override this in the jobspec at the task level so that you can still get names likedb,web,redis, etc., however, this opens up the possibility of overlapping names.