2

I have a container on my server. Up until yesterday, everything was working okay, then someone deleted docker routes on the host. Application is running inside the container and listening on 0.0.0.0:5000, it is exposed on 5001 . Running curl -v localhost:5001 gives out

* Rebuilt URL to: localhost:5001/
*   Trying ::1...
* Connected to localhost (::1) port 5001 (#0)
> GET / HTTP/1.1
> Host: localhost:5001
> User-Agent: curl/7.47.0
> Accept: */*
>
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

I have tried restarting the daemon, recreated the container, created and attached a new bridge network to the container but nothing has worked.

However, I tried launching the container with host driver and I could reach it. I do not want to use host network, I need to make it work with bridge network.

artfulbeest
  • 1,395
  • 2
  • 16
  • 22

2 Answers2

2

I finally was able to get everything working.

  1. Changed docker subnet settings, cause somehow subnets created by docker-compose were interfering with host's public interface. Added code below to /etc/docker/daemon.json

    { "dns": ["10.10.1.222"], "default-address-pools": [ {"base":"10.10.0.0/16","size":24} ] }

  2. Restart docker service

  3. Forced docker compose to use default bridge network. In docker-compose.yaml

    network_mode: bridge

  4. Down containers created by compose, then re-up

  5. Removed all networks created by compose

    docker network rm

Note: From my question, docker routes were deleted because somehow they were making host unreachable on reboot. Changing docker subnets and removing all other networks except the default solved that problem.

docker network ls 



NETWORK ID          NAME                DRIVER              SCOPE
15d807ad77d4        bridge              bridge              local
6cd415046a23        host                host                local
6e9b8dfc500e        none                null                local

Edit

As per @OlivierMehani comment, while using 20.10.0.0/16 subnet worked for me, it might cause problems as 20.10.0.0/16 is public address range. To be safe, use IP ranges 10.0.0.0 - 10.255.255.255, 172.16.0.0 to 172.31.255.255 and 192.168.0.0 to 192.168.255.255. Just make sure the subnet you pick is not being used in your organization especially by the docker host.

artfulbeest
  • 1,395
  • 2
  • 16
  • 22
  • well, this solved my issue there https://github.com/docker/for-mac/issues/3782 – kerbrose Dec 24 '20 at 10:51
  • This doesn't look like a good idea. The 20.10.0.0/16 range is part of the public address space, and actually belongs to Microsoft (see `whois 20.10.0.0`). While this might work most of the time, you might actually run into really weird issues (such as DNS resolution failures) if you shadow this network. – shtrom Sep 01 '21 at 06:10
  • @OlivierMehani, this is true, it works for me as I am not exposed to the internet. I will update my answer to use a private subnet range. Thank you. – artfulbeest Sep 01 '21 at 08:41
1

Reset iptables back to default (note that this will remove all the existing rules, chains and sets the policies to ACCEPT, if you have other rules other that docker default, or made any changes, makes sure you make a backup before doing this)

  1. stop docker service: sudo systemctl stop docker

  2. reset iptables back to default:

iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -t nat -F
iptables -t mangle -F
iptables -F
iptables -X
  1. start docker: systemctl start docker
Farhad Farahi
  • 35,528
  • 7
  • 73
  • 70