Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support service records? #17

Open
ekristen opened this issue Dec 8, 2015 · 4 comments
Open

support service records? #17

ekristen opened this issue Dec 8, 2015 · 4 comments

Comments

@ekristen
Copy link

ekristen commented Dec 8, 2015

thoughts on supporting service records?

@tilgovi
Copy link

tilgovi commented Feb 18, 2016

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
Copy link
Author

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
Copy link

tilgovi commented Feb 18, 2016

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
Copy link

tilgovi commented Feb 23, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants