6

Problem

I have a Docker service container exposed to *:8080.

  • I cannot access the container through localhost:8080. Chrome / curl hangs up indefinitely.
  • But I can access the container if I use any other local IP, such as 127.0.0.1

This is tripping me up because in my hosts file, localhost redirects to 127.0.0.1.

Why is this happening? And is it IPv4/IPv6 dual-stack related somehow?

Environment

I am on PopOS (Ubuntu-based), with Docker Swarm enabled. I am using this test stack file, traefik.docker-compose.yml:

version: '3'
services:
  reverse-proxy:
    image: traefik # The official Traefik docker image
    command: --api --docker # Enables the web UI and tells Traefik to listen to docker
    ports:
      - "80:80"     # The HTTP port
      - "8080:8080" # The Web UI (enabled by --api)
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock # So that Traefik can listen to the Docker events

To run the stack, I use:

docker stack deploy -c traefik.docker-compose.yml traefik

Once the service is up, I confirm that it is listening to 8080 through 2 ways:

  1. docker service ls
ID                  NAME                    MODE                REPLICAS            IMAGE               PORTS
4ejfsvenij3p        traefik_reverse-proxy   replicated          1/1                 traefik:latest      *:80->80/tcp, *:8080->8080/tcp
  1. sudo ss -pnlt | grep 8080
LISTEN   3         128                       *:8080                   *:*        users:(("dockerd",pid=2119,fd=45))

For reference, here is the contents of my /etc/hosts:

127.0.0.1   localhost
::1     localhost ipv6-localhost
127.0.1.1   pop-os.localdomain  pop-os pop1810x220

I just use curl for the tests:

  • Works: curl http://127.0.0.1:8080
  • Hangs up: curl http://localhost:8080
Jeric de Leon
  • 63
  • 3
  • 8
  • How about `curl 'http://[::1]:8080'` (the IPv6 version of `localhost`)? – Charles Duffy Feb 25 '19 at 00:58
  • No dice, `http://[::1]:8080/` hangs up too – Jeric de Leon Feb 25 '19 at 01:17
  • 1
    That's actually what I was *hoping* for -- it tells us what's wrong with `localhost`. Keep in mind that `/etc/hosts` isn't the only piece involved in name resolution -- you need to evaluate your system's NSS modules to know what all the components are in play, so you can't trust that `/etc/hosts` overrides everything else without investigating how your distro (or your sysadmin, if locally overridden) has set up name resolution. – Charles Duffy Feb 25 '19 at 02:04
  • This opens up a new avenue for investigation, I'll dig more around this, thank you! – Jeric de Leon Feb 25 '19 at 02:20
  • 1
    Have you found a solution for this? – p0rter May 07 '19 at 09:42
  • I still haven't :( – Jeric de Leon May 07 '19 at 15:50
  • I got the same issue. However, container deployed by docker run works fine when accessing the ::1. The containers deployed by docker compose or swarm failed to map the external ipv6 to ipv4. If you look at `netstats -tulpn` you will found the normal container was listening via `docker-proxy` while the swarm was listened by `dockerd`. I'm not sure why this causes the difference. Hope an update on this. – Yuanyi Wu Jan 01 '20 at 01:15

1 Answers1

0

Try editing /etc/hosts in the running container to remove the second 'localhost' reference which is on the second line and follows a few spaces after '::1' so that it reads:

::1 ipv6-localhost

Schadenfred
  • 136
  • 1
  • 9