9

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.

7

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.

  • 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
  • 6
    Actually, 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
  • 5
    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. – Lingbo Tang Sep 20 '17 at 17:35
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.