curl (56) Lỗi Recv: Thiết lập lại kết nối bằng ngang hàng - khi nhấn container docker [đã đóng]

Từ một phiên bản AWS ec2 (chạy docker), tôi đang cố gắng sử curldụng dịch vụ web được lưu trữ trên docker của mình.

Được:

[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

Tôi có thể nhấn dịch vụ web từ trong container:

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

Nhưng, tôi không thể đánh nó từ máy chủ:

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

Tôi đã xem câu trả lời chi tiết về curllỗi này , nhưng tôi không biết làm thế nào để gỡ lỗi vấn đề này.

networking docker curl

— Kevin Meredith
nguồn

Câu trả lời:

Đặt lại kết nối với bộ chứa Docker thường chỉ ra rằng bạn đã xác định ánh xạ cổng cho bộ chứa không trỏ đến ứng dụng.

Vì vậy, nếu bạn đã xác định ánh xạ 80:80, hãy kiểm tra xem quy trình của bạn bên trong docker trên thực tế có đang chạy trên cổng 80 (netstat -an | grep LISTEN) không.

Bạn nhận được thiết lập lại khi Docker 'proxy' chọn kết nối, cố gắng kết nối với quy trình bên trong container, vì vậy sẽ đặt lại kết nối.

— Jason Martin
nguồn

Không có netstattrên container, nhưng tôi đã chạy: ss -a | grep -i LISTđể đầu ra tcp LISTEN 0 100 ::ffff:127.0.0.1:http :::*. Nếu tôi đọc đầu ra đó một cách chính xác, thì nó đang nghe localhost:80?

— Kevin Meredith

Trên thực tế, stackoverflow.com/a/26553296/409976 đã khắc phục sự cố của tôi, tức là sử dụng "0.0.0.0"làm giao diện, không phải "localhost" .

— Kevin Meredith

Cảm ơn Jason. Giải pháp của bạn không phải là một sửa chữa thực sự cho tôi, nhưng nó dẫn tôi đến vấn đề. Điều này xảy ra với tôi vì dịch vụ bắt đầu vào ngày 127.0.0.1:9200 (bên trong container) và nó không được "xuất bản" vì IP. Vì vậy, tôi đã thay đổi nó thành 0.0.0.0:9200 và sau đó nó bắt đầu hoạt động từ bên ngoài container. Bạn cần phải có cổng 9200 được hiển thị, nhưng tôi chắc chắn bạn đã biết điều đó.

— Tomáš Tibenský

@KevinMeredith: Cảm ơn vì điều đó .. đã đấu tranh trong 4 giờ qua vì điều đó !!!

— aman_novice

@KevinMeredith Tôi vẫn không thể làm cho nó hoạt động sau khi thay đổi máy chủ thành 0.0.0.0.

— Lingbo Tang

Bạn có thể điều tra điều này bằng cách cài đặt tshark trên container và sau đó làm tshark -i any:

Nếu sau đó bạn thực hiện một yêu cầu bên ngoài, bạn sẽ thấy một cái gì đó như dưới đây:

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

Gói mạng được gửi đến nhưng nó phản hồi với a RST, có nghĩa là nó đã bị từ chối.

Hầu hết có lẽ bạn đang nghe 127.0.0.1chứ không phải 0.0.0.0- tất cả IP.

— Chris Stryczynski
nguồn