curl (56) Recv failed: Resetowanie połączenia przez peer - po uderzeniu w kontener dokera [zamknięty]

Z instancji AWS ec2 (która działa docker) próbuję do curlmojej usługi hostowanej przez kontener dokowanej.

Dany:

[ec2-user]$ docker ps
CONTAINER ID        IMAGE                                                                COMMAND                  CREATED             STATUS              PORTS                                        NAMES
b56fa0d76d5c        $REGISTRY/$WORK/metrics:v0.1.0   "/bin/sh -c 'sh /root"   3 minutes ago       Up 3 minutes        0.0.0.0:80->80/tcp, 0.0.0.0:9000->9000/tcp   insane_leakey

Mogę trafić do serwisu internetowego z poziomu kontenera:

[ec2-user]$ docker exec -it b56fa0d76d5c bash
root@b56fa0d76d5c:/# curl 'http://localhost/health'
Request is missing required query parameter 'apiName'

Ale nie mogę trafić go z hosta:

[ec2-user]$ curl 'http://localhost/health'
curl: (56) Recv failure: Connection reset by peer

Przejrzałem szczegółową odpowiedź na ten curlbłąd, ale nie jestem pewien, jak rozwiązać ten problem.

networking docker curl

— Kevin Meredith
źródło

Odpowiedzi:

Resetowanie połączenia do kontenera Docker zwykle wskazuje, że zdefiniowano mapowanie portów dla kontenera, które nie wskazuje aplikacji.

Tak więc, jeśli zdefiniowałeś mapowanie 80:80, sprawdź, czy proces wewnątrz instancji dokera faktycznie działa na porcie 80 (netstat -an | grep LISTEN).

Otrzymujesz reset, gdy „proxy” Dockera odbiera połączenie, próbuje połączyć się z procesem wewnątrz kontenera, kończy się niepowodzeniem, więc resetuje połączenie.

— Jason Martin
źródło

Nie netstatw kontenerze, ale uruchomiłem: ss -a | grep -i LISTdo wyjścia tcp LISTEN 0 100 ::ffff:127.0.0.1:http :::*. Jeśli poprawnie odczytam to wyjście, to nasłuchuje localhost:80?

— Kevin Meredith

Właściwie stackoverflow.com/a/26553296/409976 ustalone mój problem, czyli używając "0.0.0.0"jako interfejs, nie "localhost" .

— Kevin Meredith,

Dzięki Jason. Twoje rozwiązanie nie było dla mnie prawdziwą poprawką, ale doprowadziło mnie do problemu. Zdarzyło mi się to, ponieważ usługa rozpoczęła się w 127.0.0.1:9200 (wewnątrz kontenera) i nie została „opublikowana” z powodu adresu IP. Więc zmieniłem go na 0.0.0.0:9200, a potem zaczął działać z zewnątrz kontenera. Musisz mieć odsłonięty port 9200, ale jestem pewien, że już o tym wiesz.

— Tomáš Tibenský

@KevinMeredith: Dzięki za to .. walczyłem przez ostatnie 4 godziny, bo tego !!!

— aman_novice

@KevinMeredith Nadal nie mogę go uruchomić po zmianie hosta na 0.0.0.0.

— RandomEli,

Możesz to sprawdzić, instalując tshark na kontenerze, a następnie tshark -i any:

Jeśli następnie wykonasz żądanie zewnętrznie, powinieneś zobaczyć coś takiego:

root@618910b515f0:/code# tshark -i any
Running as user "root" and group "root". This could be dangerous.
Capturing on 'any'
tshark: cap_set_proc() fail return: Operation not permitted

tshark: cap_set_proc() fail return: Operation not permitted

    1 0.000000000   172.18.0.1 → 172.18.0.3   TCP 76 45844 → 8001 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=820044004 TSecr=0 WS=128
    2 0.000019457   172.18.0.3 → 172.18.0.1   TCP 56 8001 → 45844 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

Pakiet sieciowy wszedł, ale odpowiedział „a” RST, co oznacza, że został odrzucony.

Najprawdopodobniej słuchasz 127.0.0.1raczej niż 0.0.0.0wszystkich adresów IP.

— Chris Stryczyński
źródło