search

newsnowlabs / docker-ingress-routing-daemon

Docker swarm daemon that modifies ingress mesh routing to expose true client IPs to service containers
MIT License
189 stars 37 forks source link

ngix still not getting the client ip #22

Closed uacaman closed 2 years ago

uacaman commented 2 years ago

I am using portainer on top docker swarm and nginx is used as a reverse proxy to all other containers,

before the installation of dind the client ip was 10.0.0.2 and after i got the same 10.0.0.2.

The installation was using the commands line docker-ingress-routing-daemon --ingress-gateway-ips 10.0.0.1 --install

After that i scaled the services down to 0 and up to 1 again. I have only one host.

I have no clue where to start to look what is causing the ip to remain the same.

The ngix and all container use a network called "proxynet" in overlay. Could a overlay network be the problem?

struanb commented 2 years ago

Hi @uacaman, thank you for trying DIND. In your installation command, you must provide the ingress IPs for the nodes you are planning to use as load balancers. In your case, you only have one host, so one IP, and it looks like its ingress IP is 10.0.0.2. As such, the IP you provide on the installation command line should probably be 10.0.0.2 not 10.0.0.1.

Please can you try uninstalling with docker-ingress-routing-daemon --uninstall and reinstalling with docker-ingress-routing-daemon --ingress-gateway-ips 10.0.0.2 --install.

Then please scale down to 0 and up to 1 again, and let me know what happens.

uacaman commented 2 years ago

Yes, the IP is 10.0.0.2, after changing the command it worked. But when rebooting the system it did not. I had to add ExecStopPost=docker-ingress-routing-daemon --uninstall on the dind.service to make it work on system reboot

struanb commented 2 years ago

Hi @uacaman. It sounds like the original issue reported has been fixed, which is great news.

P.S. Regarding making it work on system reboot, the ExecStopPost command should not be necessary, as no relevant state configured by DIND survives a system reboot anyway, and so it is sufficient to ensure DIND is started following system reboot. If you feel there is something further to investigate here, please raise a new issue.