add skydock functionality directly in skydns?
Closed this issue · 7 comments
With kubernetes support we write into etcd. This is new functionality for SkyDNS, but now that we do it, well can (ans should probably) also incorporate skydock func. into SkyDNS.
This brings an interesting question up: there is no "standard" service definition, but there are a lot of service discovery tools built around etcd/consul,etc. We should propose one and use that.
Adding SkyDock directly is a good idea. @crosbymichael - your thoughts? One less binary/container to run & maintain.
Ya, i think it would be good. It's hard to expect people to run, skydns, etcd, and skydock just to get discovery working.
As for a standard service definition: msg.Service ? We can even use Key: a pathname is not too bad I would think.
Isn't a service def. at its core an IP + port? At least that's how you reach it. In SkyDNS we now have
- Key/Path
- Port
- Host (name or ip), should resolve to an IP in the end
So how would you describe this in internet terms, as something like an URI, where Key/Path is encoded as the domain name, port is trivially added to that, because we already have a syntax for it. The only bit not accounted for is Host.
srv://Path/Host:Port[:Priority][:Weight]
Where Path is an domain name, Host is either a domain name or an IP address on Port is port number.
Some examples which use names from the README:
srv://1.rails.staging.east.skydns.local/service1.example.com:8080
srv://6.rails.staging.east.skydns.local/[2003::8:1]:8080
srv://6.rails.staging.east.skydns.local/[2003::8:1]:http-alt
srv://4.rails.staging.east.skydns.local/[10.0.1.125]:8080
Basically encoding a SRV record as an URI.
Yeah, I guess i was over-reaching when I was thinking about “service definitions”. I was thinking of all of the above, plus things like “service provided” “description”, etc. Generally that metadata probably isn’t necessary, and you should ignore my earlier comments. I was thinking more in terms of the “discovery” part of service discovery.
On Oct 18, 2014, at 5:34 AM, Miek Gieben notifications@github.com wrote:
Isn't a service def. at its core an IP + port? At least that's how you reach it. In SkyDNS we now have
Key/Path
Port
Host (name or ip), should resolve to an IP in the end
So how would you describe this in internet terms, as something like an URI, where Key/Path is encoded as the domain name, port is trivially added to that, because we already have a syntax for it. The only bit not accounted for is Host.service://Path/Host:Port[:Priority][:Weight]
Where Path is an domain name, Host is either a domain name or an IP address on Port is port number.Some examples which use names from the README:
service://1.rails.staging.east.skydns.local/service1.example.com:8080
service://6.rails.staging.east.skydns.local/[2003::8:1]:8080
service://6.rails.staging.east.skydns.local/[2003::8:1]:http-alt
service://4.rails.staging.east.skydns.local/[10.0.1.125]:8080
Basically encoding a SRV record as an URI.—
Reply to this email directly or view it on GitHub #94 (comment).
We're removing kubernetes supports, which I assume just write to ectd now? (Didn't look at the code). If so I so no reason to fix this issue. That way skydns can stay lean and mean and just do DNS.
agreed - closing