curl (56) Falha na recuperação: Redefinição da conexão por pares - ao atingir o contêiner do docker [fechado]

Em uma instância do AWS ec2 (que é executada docker), estou tentando curlacessar o serviço da web hospedado em contêiner do 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

Eu posso acessar o serviço web de dentro do contêiner:

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

Mas não consigo acessá-lo do host:

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

Eu olhei para esta resposta detalhada sobre esse curlerro, mas não tenho certeza de como depurar esse problema.

networking docker curl

— Kevin Meredith
fonte

Respostas:

A redefinição de conexão para um contêiner do Docker geralmente indica que você definiu um mapeamento de porta para o contêiner que não aponta para um aplicativo.

Portanto, se você definiu um mapeamento de 80:80, verifique se o processo dentro da instância do docker está de fato executando na porta 80 (netstat -an | grep LISTEN).

Você é redefinido quando o 'proxy' do Docker captura a conexão, tenta se conectar ao processo dentro do contêiner, falha e, portanto, redefine a conexão.

— Jason Martin
fonte

Não netstatno contêiner, mas eu corri: ss -a | grep -i LISTpara a saída tcp LISTEN 0 100 ::ffff:127.0.0.1:http :::*. Se eu li essa saída corretamente, está ouvindo localhost:80?

— 21716 Kevin

Na verdade, o stackoverflow.com/a/26553296/409976 corrigiu meu problema, ou seja, usando "0.0.0.0"como interface, não "localhost" .

— 21716 Kevin

Obrigado Jason. Sua solução não foi uma correção real para mim, mas me levou ao problema. Isso aconteceu comigo porque o serviço foi iniciado em 127.0.0.1:9200 (contêiner interno) e não foi "publicado" por causa do IP. Então, mudei para 0.0.0.0:9200 e comecei a trabalhar de fora do contêiner. Você precisa ter a porta 9200 exposta, mas tenho certeza que você já sabe disso.

— Tomáš Tibenský

@ KevinMeredith: Obrigado por isso .. esteve lutando nas últimas 4 horas por isso !!!

— 2191717

@KevinMeredith Ainda não consigo fazer o trabalho depois de mudar de host para 0.0.0.0.

— Lingbo Tang

Você pode investigar isso instalando o tshark no contêiner e, em seguida, faça tshark -i any:

Se você fizer uma solicitação externamente, deverá ver algo como o abaixo:

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

O pacote de rede chegou, mas respondeu com a RST, o que significa que foi rejeitado.

Provavelmente você está ouvindo em 127.0.0.1vez de 0.0.0.0- todos os IPs.

— Chris Stryczynski
fonte