mantl / mesos-consul

Mesos to Consul bridge for service discovery
Apache License 2.0
338 stars 95 forks source link

how are multi-port jobs handled? #5

Open brentley opened 9 years ago

brentley commented 9 years ago

https://github.com/CiscoCloud/mesos-consul/blob/master/mesos/mesos.go#L121

Looking at this, I am not clear how a job/service that has multiple ports will be registered. How will they be differentiated when it comes to service registration in consul?

Thanks for the work so far!

ChrisAubuchon commented 9 years ago

They are currently registered with the same service name but with a different service ID. The service ID is built as "::"

Example:

Test service registration files:

test1.json:
{
  "ID": "test1",
  "Name": "test",
  "Address": "127.0.0.1",
  "Port": 80
}
test2.json
{
  "ID": "test2",
  "Name": "test",
  "Address": "127.0.0.1",
  "Port": 443
}

Registered via:

# curl -X PUT -d @test1.json localhost:8500/v1/agent/service/register
# curl -X PUT -d @test2.json localhost:8500/v1/agent/service/register

Some dig'ing:

# dig +noall +answer @127.0.0.1 -p 8600 test.service.consul ANY
test.service.consul.    0   IN  A   127.0.0.1
# dig +noall +answer @127.0.0.1 -p 8600 test.service.consul SRV
test.service.consul.    0   IN  SRV 1 1 80 default.node.vagrant.consul.
test.service.consul.    0   IN  SRV 1 1 443 default.node.vagrant.consul.
memelet commented 9 years ago

This doesn't seem a good fit for when the ports are dynamically allocated. There would be no way for the client of the service to distinguish between the services. It would be nice to have a mechanism like like registrator, where environment variables (or some kind metadata that can be defined in mesos) are used to name the services.

ChrisAubuchon commented 9 years ago

My intention was/is to use Mesos task labels as the "registrator environment variable" replacement. Unfortunately there doesn't seem to be a way to get port mappings out of Mesos. To use an example app from the CiscoCloud/microservices-infratstructure project:

{
  "container": {
    "type": "DOCKER",
    "docker": {
      "network": "BRIDGE",
      "image": "keithchambers/docker-hello-world",
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ]
    }
  },
  "id": "hello-world",
  "instances": 1,
  "cpus": 0.1,
  "mem": 128
}

This is the information that we get from Mesos:

{
  "executor_id": "",
  "framework_id": "20150615-175443-16777343-5050-629-0000",
  "id": "hello-world.6d13f5eb-1389-11e5-a693-f63bd36ba682",
  "labels": [],
  "name": "hello-world",
  "resources": {
    "cpus": 0.1,
    "disk": 0,
    "mem": 128,
    "ports": "[4001-4001]"
  },
  "slave_id": "20150615-180504-251789322-15050-8375-S0",
  "state": "TASK_RUNNING",
  "statuses": [
    {
      "state": "TASK_RUNNING",
      "timestamp": 1434391819.31373
    }
  ]
}

All we get is the final port. Nothing to map back to the containerPort which is what we need.

memelet commented 9 years ago

And mesos returns two ports when the container only declared one.

stevendborrelli commented 9 years ago

As an FYI. registrator has just implemented docker label support: https://github.com/gliderlabs/registrator/pull/192

This is definitely an area where Mesos needs to export more information from the containers.

ChrisAubuchon commented 9 years ago

It only returns the one port. The ports entry is a range. It says that the task is using all of the ports from 4001 to 4001. So just 4001.

stevendborrelli commented 8 years ago

@brentley @memelet FYI, in https://github.com/CiscoCloud/mesos-consul/pull/35, mesos-consul added support for DiscoveryInfo.

a-nldisr commented 7 years ago

We can confirm that DiscoveryInfo allows registration for multiple ports. We use configured Aurora to allow this, its working for us.