curl (56) Ошибка при получении: сброс соединения через одноранговый узел - при попадании в докер-контейнер [закрыт]

Из экземпляра AWS ec2 (который запускается docker) я пытаюсь curlподключиться к своему веб-сервису, расположенному в Docker-контейнере.

Данный:

[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

Я могу поразить веб-сервис из контейнера:

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

Но я не могу поразить это от хозяина:

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

Я посмотрел на этот подробный ответ на эту curlошибку, но я не уверен, как отладить эту проблему.

networking docker curl

— Кевин Мередит
источник

Ответы:

Сброс подключения к контейнеру Docker обычно означает, что вы определили сопоставление портов для контейнера, который не указывает на приложение.

Итак, если вы определили отображение 80:80, убедитесь, что ваш процесс внутри экземпляра докера фактически работает на порте 80 (netstat -an | grep LISTEN).

Вы получаете сброс, поскольку прокси-сервер Docker устанавливает соединение, пытается подключиться к процессу внутри контейнера, завершается неудачно и сбрасывает соединение.

— Джейсон Мартин
источник

Нет netstatна контейнере, но я побежал: ss -a | grep -i LISTдля вывода tcp LISTEN 0 100 ::ffff:127.0.0.1:http :::*. Если я правильно прочитал этот вывод, значит, он прослушивается localhost:80?

— Кевин Мередит

На самом деле, stackoverflow.com/a/26553296/409976 исправил мою проблему, то есть использование "0.0.0.0"в качестве интерфейса, а не "localhost" .

— Кевин Мередит

Спасибо Джейсон. Ваше решение не было для меня настоящим решением, но привело меня к проблеме. Это случилось со мной, потому что служба была запущена в 127.0.0.1:9200 (внутри контейнера) и не была «опубликована» из-за IP. Поэтому я изменил его на 0.0.0.0:9200, а затем он начал работать снаружи контейнера. Вам нужно открыть порт 9200, но я уверен, что вы уже это знаете.

— Томаш

@KevinMeredith: Спасибо за это .. боролись за последние 4 часа, потому что это !!!

— aman_novice

@KevinMeredith Я все еще не могу заставить его работать после смены хоста 0.0.0.0.

— Линбо Тан

Вы можете исследовать это, установив tshark на контейнер, а затем выполните tshark -i any:

Если вы затем делаете запрос извне, вы должны увидеть что-то вроде следующего:

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

Сетевой пакет пришел, но он ответил RST, что означает, что он был отклонен.

Скорее всего, вы слушаете, 127.0.0.1а не 0.0.0.0все IP-адреса.

— Крис Стрычински
источник