27

From an AWS ec2 instance (which runs docker), I am trying to curl my docker container-hosted web service.

Given:

[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

I can hit the web service from within the container:

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

But, I can't hit it from the host:

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

I looked at this detailed answer on this curl error, but I'm not sure how to debug this issue.

Community
  • 1
Kevin Meredith
  • 1,119
  • 2
  • 14
  • 21

2 Answers2

22

Connection Reset to a Docker container usually indicates that you've defined a port mapping for the container that does not point to an application.

So, if you've defined a mapping of 80:80, check that your process inside the docker instance is in fact running on port 80 (netstat -an|grep LISTEN).

You get a reset as the Docker 'proxy' picks up the connection, attempts to connect to the process inside the container, fails, so resets the connection.

Jason Martin
  • 4,865
  • 15
  • 24
  • No `netstat` on the container, but I ran: `ss -a | grep -i LIST` to output `tcp LISTEN 0 100 ::ffff:127.0.0.1:http :::*`. If I read that output correctly, then it's listening on `localhost:80`? – Kevin Meredith Apr 11 '16 at 18:45
  • 10
    Actually, http://stackoverflow.com/a/26553296/409976 fixed my issue, i.e. using `"0.0.0.0"` as the interface, **not** `"localhost"`. – Kevin Meredith Apr 11 '16 at 19:10
  • 6
    Thanks Jason. Your solution wasn't an actual fix for me, but it lead me to the issue. This happened to me because the service started on 127.0.0.1:9200 (inside container) and it wasn't "published" because of the IP. So I changed it to 0.0.0.0:9200 and then it started to work from outside of the container. You need to have the 9200 port exposed, but I'm sure you already know that. – Tomáš Tibenský May 18 '17 at 12:57
  • @KevinMeredith : Thanks for that.. been struggling for past 4 hours coz of that!!! – aman_novice Jul 18 '17 at 16:03
  • @KevinMeredith I still can't make it work after changing host to `0.0.0.0`. – RandomEli Sep 20 '17 at 17:35
  • I've been looking for this for about 2 hours. Thank you for this answer. – Marco Aurélio Deleu Aug 16 '18 at 13:51
  • This is correct, I was mapping the host OS port to a port on which an application was not running in the container; got this error. After removing the container and starting with the right port mapping it worked. – picmate 涅 Nov 25 '20 at 18:16
6

You can investigate this by installing tshark on the container and then do tshark -i any:

If you then do a request externally you should see something like the below:

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

The network packet came in but it responded with a RST, which means it was rejected.

Most probably you're listening on 127.0.0.1 rather than 0.0.0.0 - all IPs. You can verify this by running netstat -tulpn

Chris Stryczynski
  • 1,176
  • 2
  • 15
  • 23