search

gliderlabs / resolvable

Host-level DNS gateway for Docker
MIT License
315 stars 37 forks source link

support service records? #17

Open ekristen opened 8 years ago

ekristen commented 8 years ago

thoughts on supporting service records?

tilgovi commented 8 years ago

You mean publishing SRV records for the .docker domain? What would be the purpose? Resolvable knows nothing of services, only hosts. Services are only meaningful to the forward resolvers, such as a consul instance.

ekristen commented 8 years ago

Since resolvable has direct access to the docker daemon, it can easily iterate over ports and exposing them as service records.

A purpose could be so that not only could you find locally running instances of something using the .docker domain, if the service exposes its port of 4000 which is mapped to 32017 then the dynamic port could be resolved as well via a service record.

tilgovi commented 8 years ago

I see what you mean. In my head I guess I'm thinking that common usage has containers accessing one another on the .docker domain over the docker bridge interface, in which case they're bypassing the port mapping anyway. If 4000 is exposed and mapped to 32017 then it's 32017 on the host, but it's 4000 on its interface on the docker bridge subnet.

But maybe others have different usage patterns in mind.

tilgovi commented 8 years ago

I think we need more information here to make a concrete proposal.

Assuming resolvable did provide SRV records, what information should it have?

Normally, an SRV record is _service._proto.example.com. In the case of resolvable, we don't know what services are on what ports. We could adopt the service model of registrator for that, of course. The protocol is available from the mapping.

I still don't know what port number would be correct, though.

Containers can talk to one another on the bridge interface without any port mapping. With the default docker option of --userland-proxy=true, hairpin NAT doesn't work. That means that one container cannot access another container by connecting to the host IP at the mapped port.

We could respond with only the internal port for all exposed ports, and ignore mappings, but this would only work for the host and other containers on the bridge. It would not work for connections coming from other hosts.