5 ms·

>Use DNS-based discovery instead of /etc/hosts #19198 This will end well...

by thejosh 11y ago

raimille1 11y ago
This is when you specify you want a user defined network and want to rely on docker networking. I'd give it some time before using that in production and use your own DNS/Service Discovery mix.
snorii 11y ago
Could you explain why? Simply from a learning perspective. I just don't know why and would like to know.
- bpchaps 11y ago
  Because /etc/nsswitch.conf exists to do exactly what's needed here. Now there's an extra layer of need-to-know that adds confusion. I can almost guarantee that there's going to be a major outage somewhere, someplace because of this change.
CSDude 11y ago
It uses DNS for only discovering the other containers within the same custom network, if query is not found the DNS redirects the queries to your own DNS server, I don't see how it can be worse than /etc/hosts solution.
- ChristianBundy 11y ago
  Exactly, obviously /etc/hosts will still take precedence, but instead of munging your /etc/hosts when starting a container you can just use their DNS server. I don't see a problem with this.
ossreality 11y ago
Apparently no one else has been paying an ounce of attention... And you get downvoted for it. The HN way! https://github.com/docker/docker/issues/19474 https://github.com/docker/docker/issues/19474 Least of all you're forced to go through their DNS server which doesn't support TCP. Boy, this is absolutely going to fuck people. Because I bet a bunch of people are going to run Go containers in 1.10 engine. And guess what happens when you send a Go app a DNS response, in UDP format, that is larger than 4096 bytes? You get a panic and crash! Woohoo! And yes, there are DNS servers that incorrectly throw out UDP DNS responses larger than 4096 bytes. Can't wait for my containers to fail because of fucking Docker putting a DNS service in Engine. Unacceptable. Docker should've realized they needed to think about this stuff all-the-why shykes was too busy picking fights with people as Kubernetes encroached on what he saw as "his" territory. There's a reason that everyone is very excited about the rkt announcement today. Particularly amongst some Kubernetes users... (In the interest of not tainting the waters, I do NOT work for Google)
falcolas 11y ago
I tend to agree with you. Between time to live, caching, and various namespace conflicts, this could make for a very large troubleshooting headache.
- shykes 11y ago
  Docker assumes it cannot trust the container's DNS resolver to respect TTL and cache in a compliant way. So it guarantees stable name->ip mapping for each container. As a result, when you point a service endpoint at another container, it's the IP/container mapping that is changed, which is a much more reliable and atomic change. I would definitely never rely on changing DNS records to orchestrate changes to my production stack, that would be way too brittle.
  - falcolas 11y ago
    The real problem is that you can't trust the program's resolver, either. Java will behave differently than Go, which behaves differently from Python, and so on.

>Use DNS-based discovery instead of /etc/hosts #19198 This will end well...

by thejosh 11y ago

>Use DNS-based discovery instead of /etc/hosts #19198 This will end well...

This is when you specify you want a user defined network and want to rely on docker networking. I'd give it some time before using that in production and use your own DNS/Service Discovery mix.

snorii 11y ago

Could you explain why? Simply from a learning perspective. I just don't know why and would like to know.

bpchaps 11y ago
Because /etc/nsswitch.conf exists to do exactly what's needed here. Now there's an extra layer of need-to-know that adds confusion. I can almost guarantee that there's going to be a major outage somewhere, someplace because of this change.

CSDude 11y ago

It uses DNS for only discovering the other containers within the same custom network, if query is not found the DNS redirects the queries to your own DNS server, I don't see how it can be worse than /etc/hosts solution.

ChristianBundy 11y ago
Exactly, obviously /etc/hosts will still take precedence, but instead of munging your /etc/hosts when starting a container you can just use their DNS server. I don't see a problem with this.

ossreality 11y ago

Apparently no one else has been paying an ounce of attention... And you get downvoted for it. The HN way! https://github.com/docker/docker/issues/19474 https://github.com/docker/docker/issues/19474 Least of all you're forced to go through their DNS server which doesn't support TCP. Boy, this is absolutely going to fuck people. Because I bet a bunch of people are going to run Go containers in 1.10 engine. And guess what happens when you send a Go app a DNS response, in UDP format, that is larger than 4096 bytes? You get a panic and crash! Woohoo! And yes, there are DNS servers that incorrectly throw out UDP DNS responses larger than 4096 bytes. Can't wait for my containers to fail because of fucking Docker putting a DNS service in Engine. Unacceptable. Docker should've realized they needed to think about this stuff all-the-why shykes was too busy picking fights with people as Kubernetes encroached on what he saw as "his" territory. There's a reason that everyone is very excited about the rkt announcement today. Particularly amongst some Kubernetes users... (In the interest of not tainting the waters, I do NOT work for Google)

falcolas 11y ago

I tend to agree with you. Between time to live, caching, and various namespace conflicts, this could make for a very large troubleshooting headache.

shykes 11y ago
Docker assumes it cannot trust the container's DNS resolver to respect TTL and cache in a compliant way. So it guarantees stable name->ip mapping for each container. As a result, when you point a service endpoint at another container, it's the IP/container mapping that is changed, which is a much more reliable and atomic change. I would definitely never rely on changing DNS records to orchestrate changes to my production stack, that would be way too brittle.
- falcolas 11y ago
  The real problem is that you can't trust the program's resolver, either. Java will behave differently than Go, which behaves differently from Python, and so on.