curl (56) Error de recv: restablecimiento de la conexión por parte de pares: cuando se golpea el contenedor acoplable [cerrado]

Desde una instancia de AWS ec2 (que se ejecuta docker), intento acceder a curlmi servicio web alojado en contenedor de Docker .

Dado:

[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

Puedo acceder al servicio web desde el contenedor:

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

Pero, no puedo golpearlo desde el host:

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

Miré esta respuesta detallada sobre este curlerror, pero no estoy seguro de cómo depurar este problema.

networking docker curl

— Kevin Meredith
fuente

Respuestas:

El restablecimiento de la conexión a un contenedor Docker generalmente indica que ha definido una asignación de puertos para el contenedor que no apunta a una aplicación.

Por lo tanto, si ha definido una asignación de 80:80, verifique que su proceso dentro de la instancia de Docker se esté ejecutando en el puerto 80 (netstat -an | grep LISTEN).

Obtiene un restablecimiento cuando el 'proxy' de Docker toma la conexión, intenta conectarse al proceso dentro del contenedor, falla, por lo que restablece la conexión.

— Jason Martin
fuente

No netstaten el contenedor, pero ejecuté: ss -a | grep -i LISTa la salida tcp LISTEN 0 100 ::ffff:127.0.0.1:http :::*. Si leo esa salida correctamente, ¿está escuchando localhost:80?

— Kevin Meredith

En realidad, stackoverflow.com/a/26553296/409976 solucionó mi problema, es decir, usarlo "0.0.0.0"como interfaz, no "localhost" .

— Kevin Meredith

Gracias Jason. Su solución no fue una solución real para mí, pero me llevó al problema. Esto me sucedió porque el servicio comenzó en 127.0.0.1:9200 (dentro del contenedor) y no fue "publicado" debido a la IP. Así que lo cambié a 0.0.0.0:9200 y luego comenzó a funcionar desde fuera del contenedor. Necesita tener el puerto 9200 expuesto, pero estoy seguro de que ya lo sabe.

— Tomáš Tibenský

@KevinMeredith: ¡Gracias por eso ... he estado luchando durante las últimas 4 horas por eso!

— aman_novice

@KevinMeredith Todavía no puedo hacer que funcione después de cambiar el host a 0.0.0.0.

— Lingbo Tang

Puede investigar esto instalando tshark en el contenedor y luego hacer tshark -i any:

Si luego realiza una solicitud externamente, debería ver algo como lo siguiente:

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

El paquete de red entró pero respondió con un RST, lo que significa que fue rechazado.

Lo más probable es que esté escuchando en 127.0.0.1lugar de 0.0.0.0todas las IP.

— Chris Stryczynski
fuente