curl (56) Recv fallito: connessione ripristinata dal peer - quando si colpisce il contenitore docker [chiuso]

Da un'istanza di AWS ec2 (che funziona docker), sto provando il curlmio servizio web ospitato dal container docker.

Dato:

[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

Posso colpire il servizio web dall'interno del contenitore:

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

Ma non posso colpirlo dall'host:

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

Ho esaminato questa risposta dettagliata su questo curlerrore, ma non sono sicuro di come eseguire il debug di questo problema.

networking docker curl

— Kevin Meredith
fonte

Risposte:

Il ripristino della connessione su un contenitore Docker indica in genere che è stata definita una mappatura delle porte per il contenitore che non punta a un'applicazione.

Quindi, se hai definito un mapping di 80:80, controlla che il tuo processo all'interno dell'istanza docker sia effettivamente in esecuzione sulla porta 80 (netstat -an | grep LISTEN).

Si ottiene un ripristino quando il 'proxy' Docker rileva la connessione, tenta di connettersi al processo all'interno del contenitore, fallisce, quindi ripristina la connessione.

— Jason Martin
fonte

No netstatsul contenitore, ma ho corso: ss -a | grep -i LISTper l'output tcp LISTEN 0 100 ::ffff:127.0.0.1:http :::*. Se ho letto correttamente quell'output, allora è in ascolto localhost:80?

— Kevin Meredith,

In realtà, stackoverflow.com/a/26553296/409976 ha risolto il mio problema, ovvero utilizzando "0.0.0.0"come interfaccia, no "localhost" .

— Kevin Meredith,

Grazie Jason. La tua soluzione non è stata una vera soluzione per me, ma mi ha portato al problema. Questo mi è successo perché il servizio è iniziato il 127.0.0.1:9200 (all'interno del contenitore) e non è stato "pubblicato" a causa dell'IP. Quindi l'ho cambiato in 0.0.0.0:9200 e poi ha iniziato a funzionare dall'esterno del contenitore. Devi avere la porta 9200 esposta, ma sono sicuro che lo sai già.

— Tomáš Tibenský,

@KevinMeredith: Grazie per quello .. ho lottato per le ultime 4 ore per questo !!!

— aman_novice,

@KevinMeredith Non riesco ancora a farlo funzionare dopo aver cambiato l'host in 0.0.0.0.

— Lingbo Tang,

Puoi investigare installando tshark sul container e poi fai tshark -i any:

Se poi fai una richiesta esternamente dovresti vedere qualcosa di simile al seguente:

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

Il pacchetto di rete è arrivato ma ha risposto con a RST, il che significa che è stato rifiutato.

Molto probabilmente stai ascoltando 127.0.0.1piuttosto che 0.0.0.0tutti gli IP.

— Chris Stryczynski
fonte