curl (56) Échec Recv: réinitialisation de la connexion par l'homologue - lors de l'utilisation du conteneur Docker [fermé]

À partir d'une instance AWS ec2 (qui s'exécute docker), j'essaie de curlmon service Web hébergé par conteneur Docker .

Donné:

[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

Je peux accéder au service Web depuis le conteneur:

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

Mais, je ne peux pas le frapper de l'hôte:

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

J'ai regardé cette réponse détaillée sur cette curlerreur, mais je ne sais pas comment déboguer ce problème.

networking docker curl

— Kevin Meredith
source

Réponses:

La réinitialisation de la connexion à un conteneur Docker indique généralement que vous avez défini un mappage de port pour le conteneur qui ne pointe pas vers une application.

Donc, si vous avez défini un mappage 80:80, vérifiez que votre processus à l'intérieur de l'instance de docker s'exécute bien sur le port 80 (netstat -an | grep LISTEN).

Vous obtenez une réinitialisation lorsque le «proxy» Docker récupère la connexion, tente de se connecter au processus à l'intérieur du conteneur, échoue, réinitialise donc la connexion.

— Jason Martin
source

Non netstatsur le conteneur, mais j'ai couru: ss -a | grep -i LISTà la sortie tcp LISTEN 0 100 ::ffff:127.0.0.1:http :::*. Si je lis correctement cette sortie, alors j'écoute localhost:80?

— Kevin Meredith

En fait, stackoverflow.com/a/26553296/409976 a résolu mon problème, c'est-à-dire en utilisant "0.0.0.0"l'interface, non "localhost" .

— Kevin Meredith

Merci Jason. Votre solution n'était pas une solution réelle pour moi, mais cela m'a conduit au problème. Cela m'est arrivé parce que le service a démarré le 127.0.0.1:9200 (à l'intérieur du conteneur) et qu'il n'a pas été "publié" à cause de l'IP. Je l'ai donc changé en 0.0.0.0:9200 puis il a commencé à fonctionner de l'extérieur du conteneur. Vous devez avoir le port 9200 exposé, mais je suis sûr que vous le savez déjà.

— Tomáš Tibenský

@KevinMeredith: Merci pour ça .. lutte depuis 4 heures coz !!!

— aman_novice

@KevinMeredith Je ne peux toujours pas le faire fonctionner après avoir changé d'hôte en 0.0.0.0.

— Lingbo Tang

Vous pouvez enquêter sur cela en installant tshark sur le conteneur, puis procédez comme suit tshark -i any:

Si vous faites ensuite une demande en externe, vous devriez voir quelque chose comme ci-dessous:

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

Le paquet réseau est entré mais il a répondu par un RST, ce qui signifie qu'il a été rejeté.

Vous écoutez probablement 127.0.0.1plutôt que 0.0.0.0- toutes les adresses IP.

— Chris Stryczynski
source