4 ms·

Localhost resolving to IPv6 basically breaks with Docker they unless you give special instructions only listens on IPv4. With curl for instance you can use the

Localhost resolving to IPv6 basically breaks with Docker they unless you give special instructions only listens on IPv4. With curl for instance you can use the -4 parameter but probably best we start saying test the site on 127.0.0.1 in tutorials.

deathanatos 9y ago
Sorry, but none of that is correct. First, if you publish a container's port in docker, such as with the -p flag, e.g., docker run --rm -p 8080:80/tcp nginx:latest Docker will listen, on the host, on ::; it will accept IPv4 connections on that bind. (Through IPv4-mapped IPv6 addresses[1], which is a transition mechanism.) But even if we force Docker to bind to only IPv4, curl will still work: docker run --rm -p 127.0.0.1:8080:80/tcp nginx:latest curl will attempt an IPv6 connection first in this case (since localhost resolves to ::1), and fallback when it fails (since localhost also resolves to 127.0.0.1). If you pass -v to curl, it will tell you as much: * Trying ::1... * TCP_NODELAY set * connect to ::1 port 8080 failed: Connection refused * Trying 127.0.0.1... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 8080 (#0) Perhaps there is some pathological case where Docker and curl and IPv6 and localhost don't all work together, but one would need more information to tell. But it doesn't "basically break" Docker. [1]: https://en.wikipedia.org/wiki/IPv6_address#Transition_from_IPv4 https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I...
- alexellisuk 9y ago
  I'm sorry but none of what you've said is correct - I'm speaking from experience from the Docker community. Watch this ASCII recording to see the issue https://asciinema.org/a/xM8m0iqOepkSwCRBTIP9hYXGU https://asciinema.org/a/xM8m0iqOepkSwCRBTIP9hYXGU We run into the issue on RPi/Raspbian - curl hangs indefinitely. I had someone report to me that he couldn't access localhost:8080 in a web-browser using a Docker container for FaaS because it was resolving to this IPv6 - he was on Arch Linux. Perhaps you can reverse your hasty down-voting?
  - alexellisuk 9y ago
    Nobody said it broke Docker (it was the resolution that "broke". But the resolution clearly did not work and we had people running through tutorials only to find curl would hang and timeout unless switching to 127.0.0.1 or passing the -4 flag.
    - fundabulousrIII 9y ago
      hang == block. Docker is badly written and basically broken. With those corrections, carry on.
  - deathanatos 9y ago
    You're right; that opening line was unduly harsh. My apologies. It's unfortunate, however, that the creator of the video did not capture the output of curl -v, or perhaps even an strace. The logic presented in my first post is nonetheless what curl does, and should apply, so something else is going wrong here. I still think there's a wide difference between "in this particular case, something is causing the IPv6 address to hang" and "Localhost resolving to IPv6 basically breaks with Docker".

deathanatos 9y ago

Sorry, but none of that is correct. First, if you publish a container's port in docker, such as with the -p flag, e.g., docker run --rm -p 8080:80/tcp nginx:latest Docker will listen, on the host, on ::; it will accept IPv4 connections on that bind. (Through IPv4-mapped IPv6 addresses[1], which is a transition mechanism.) But even if we force Docker to bind to only IPv4, curl will still work: docker run --rm -p 127.0.0.1:8080:80/tcp nginx:latest curl will attempt an IPv6 connection first in this case (since localhost resolves to ::1), and fallback when it fails (since localhost also resolves to 127.0.0.1). If you pass -v to curl, it will tell you as much: * Trying ::1... * TCP_NODELAY set * connect to ::1 port 8080 failed: Connection refused * Trying 127.0.0.1... * TCP_NODELAY set * Connected to localhost (127.0.0.1) port 8080 (#0) Perhaps there is some pathological case where Docker and curl and IPv6 and localhost don't all work together, but one would need more information to tell. But it doesn't "basically break" Docker. [1]: https://en.wikipedia.org/wiki/IPv6_address#Transition_from_IPv4 https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I...

alexellisuk 9y ago
I'm sorry but none of what you've said is correct - I'm speaking from experience from the Docker community. Watch this ASCII recording to see the issue https://asciinema.org/a/xM8m0iqOepkSwCRBTIP9hYXGU https://asciinema.org/a/xM8m0iqOepkSwCRBTIP9hYXGU We run into the issue on RPi/Raspbian - curl hangs indefinitely. I had someone report to me that he couldn't access localhost:8080 in a web-browser using a Docker container for FaaS because it was resolving to this IPv6 - he was on Arch Linux. Perhaps you can reverse your hasty down-voting?
- alexellisuk 9y ago
  Nobody said it broke Docker (it was the resolution that "broke". But the resolution clearly did not work and we had people running through tutorials only to find curl would hang and timeout unless switching to 127.0.0.1 or passing the -4 flag.
  - fundabulousrIII 9y ago
    hang == block. Docker is badly written and basically broken. With those corrections, carry on.
- deathanatos 9y ago
  You're right; that opening line was unduly harsh. My apologies. It's unfortunate, however, that the creator of the video did not capture the output of curl -v, or perhaps even an strace. The logic presented in my first post is nonetheless what curl does, and should apply, so something else is going wrong here. I still think there's a wide difference between "in this particular case, something is causing the IPv6 address to hang" and "Localhost resolving to IPv6 basically breaks with Docker".