Curl (56) Recv-Fehler: Verbindung durch Peer zurückgesetzt - beim Auftreffen auf Docker-Container [geschlossen]

Von einer AWS ec2-Instanz (die ausgeführt wird docker) versuche curlich, einen von Docker-Containern gehosteten Webdienst zu verwenden.

Gegeben:

[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

Ich kann den Webdienst aus dem Container heraus aufrufen:

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

Aber ich kann es vom Gastgeber nicht treffen:

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

Ich habe mir diese detaillierte Antwort auf diesen curlFehler angesehen, bin mir aber nicht sicher, wie ich dieses Problem beheben soll.

networking docker curl

— Kevin Meredith
quelle

Antworten:

Das Zurücksetzen der Verbindung auf einen Docker-Container zeigt normalerweise an, dass Sie eine Portzuordnung für den Container definiert haben, die nicht auf eine Anwendung verweist.

Wenn Sie also eine Zuordnung von 80:80 definiert haben, überprüfen Sie, ob Ihr Prozess in der Docker-Instanz tatsächlich auf Port 80 ausgeführt wird (netstat -an | grep LISTEN).

Sie werden zurückgesetzt, wenn der Docker-Proxy die Verbindung aufnimmt, versucht, eine Verbindung zum Prozess im Container herzustellen, fehlschlägt und die Verbindung zurücksetzt.

— Jason Martin
quelle

Nein netstatauf dem Container, aber ich lief: ss -a | grep -i LISTum auszugeben tcp LISTEN 0 100 ::ffff:127.0.0.1:http :::*. Wenn ich diese Ausgabe richtig gelesen habe, hört sie dann zu localhost:80?

— Kevin Meredith

Eigentlich stackoverflow.com/a/26553296/409976 festen mein Problem, dh unter Verwendung "0.0.0.0"als Schnittstelle, nicht "localhost" .

— Kevin Meredith

Danke Jason. Ihre Lösung war für mich keine wirkliche Lösung, führte mich jedoch zu dem Problem. Dies ist mir passiert, weil der Dienst am 127.0.0.1:9200 (innerhalb des Containers) gestartet wurde und aufgrund der IP nicht "veröffentlicht" wurde. Also habe ich es auf 0.0.0.0:9200 geändert und dann fing es an, von außerhalb des Containers zu arbeiten. Sie müssen den 9200-Port offen legen, aber das wissen Sie sicher schon.

— Tomáš Tibenský

@ KevinMeredith: Danke dafür. Ich habe die letzten 4 Stunden damit gekämpft !!!

— aman_novice

@ KevinMeredith Ich kann es immer noch nicht zum Laufen bringen, nachdem ich den Host gewechselt habe 0.0.0.0.

— Lingbo Tang

Sie können dies untersuchen, indem Sie tshark auf dem Container installieren und dann Folgendes tun tshark -i any:

Wenn Sie dann eine externe Anfrage stellen, sollten Sie Folgendes sehen:

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

Das Netzwerkpaket ist eingegangen, hat aber mit a geantwortet RST, was bedeutet, dass es abgelehnt wurde.

Höchstwahrscheinlich hören Sie 127.0.0.1eher zu als 0.0.0.0- alle IPs.

— Chris Stryczynski
quelle