Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple networks doesnt work #1020

Closed
albinmedoc opened this issue Apr 4, 2024 · 11 comments · Fixed by #1104
Closed

Multiple networks doesnt work #1020

albinmedoc opened this issue Apr 4, 2024 · 11 comments · Fixed by #1104

Comments

@albinmedoc
Copy link

Describe the bug
One I bind multiple networks to the container the application only available on one of them.

I have one networks for all frontend-applications, that I want exposed through traefik, that network is called "frontend".
I have one network for communication between all *arr-containers, that network is called "arr".

It looks like the application is only listening for requests coming from the "arr"-network. This is also the ip-address that is logged to the terminal when the application is started.

To Reproduce
Steps to reproduce the behavior:

  1. Configure the container with multiple networks (at least 2).
  2. Start the container
  3. Try to open the webapp for each network.
  4. It should only work for the one that got logged to the terminal.

Expected behavior
The application should be available on all networks.

Screenshots
Skärmavbild 2024-04-04 kl  20 08 00
Skärmavbild 2024-04-04 kl  20 07 24

Device (please complete the following information):

  • OS: Debian
  • Version: 11
@albinmedoc
Copy link
Author

All my other *arr-containers are all configured with two networks and working fine.

  • Sonarr
  • Radarr
  • Prowlarr
  • Bazarr
  • Overseerr
  • Plex

@helangen
Copy link

I have the same setup and the same issue…

@albinmedoc
Copy link
Author

In the context of servers, 0.0.0.0 means "all IPv4 addresses on the local machine". If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.

@Nowadays
Copy link

Nowadays commented May 7, 2024

I'm no contributor or anything, but I'm failing to understand how a user's network misconfiguration is related to this project ?

I've basically got the same archictecture, with nginx, running with no problem whatsoever.

Plus you don't provide any useful logs, what's the error ? ECONNREFUSED, sockethangup ? Can you curl the API from the frontend network ? Is 172.19.0.9 pingable from the frontend network ?

@albinmedoc
Copy link
Author

@Nowadays, this is not related to network misconfiguration. The Maintainerr application is only listening on one of the two network interfaces. Therefore I can't use Traefik to reverse proxy into the application.

To make this work, the Maintainerr application need to listen on all interfaces (0.0.0.0).

172.19.0.9 is not pingable from the frontend network (and should not be).

@jce-zz
Copy link

jce-zz commented May 14, 2024

I have the same issue as the OP and is has nothing to do with any network misconfiguration.

The Maintainerr container only listens on the first of my two configured networks which happens to be the "fallback" one for direct container access. It does not listen on the second one used in conjunction with Nginx as reverse proxy. Nginx error is a simple "Connect() failed (connection refused)" resulting in a "502 Bad Gateway" in the browser.

@MikeMatau
Copy link

MikeMatau commented May 17, 2024

So for me this works...:

version: '3'

networks:
  web:
    external: true
  internal:
    driver: bridge
    internal: true

services:
  maintainerr:
    image: ghcr.io/jorenn92/maintainerr:latest
    container_name: maintainerr
    user: 1002:1002
    volumes:
      - type: bind
        source: ./maintainerr/data
        target: /opt/data
    #ports:
    #  - 6246:6246
    environment:
      - TZ=Europe/Brussels
    restart: unless-stopped
    networks:
      - web
    labels:
      - 'traefik.enable=true'
      - 'traefik.docker.network=web'
      - "traefik.http.services.maintainerr.loadbalancer.server.port=6246"
      - 'traefik.http.routers.maintainerr.rule=Host(`maintainerr.domain.com`)'
      - 'traefik.http.routers.maintainerr.entrypoints=websecure'
      - 'traefik.http.routers.maintainerr.tls.certresolver=letsencrypt'
      - 'traefik.http.routers.maintainerr.middlewares=maintainerr'
      - 'traefik.http.middlewares.maintainerr.basicauth.users=myuser:myPassword'

The Basic Auth is created using this:

htpasswd -nbm myUser 'myPassword'

Replacing all $ by $$ (eg: $apr1$c99/GTZt$EasfS/xasd6dXggSeJ.JwRj1 becomes $$apr1$$c99/GTZt$$EasfS/xasd6dXggSeJ.JwRj1)

I also tried it with and without modifying /etc/supervisord.conf line 15:

environment=PORT=6246,HOSTNAME=0.0.0.0

That actually results in this:

2024-05-17 21:23:33,696 INFO success: ui entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
   ▲ Next.js 14.1.3
   - Local:        http://localhost:6246
   - Network:      http://0.0.0.0:6246

 ✓ Ready in 828ms

But even without line 15 it works totally fine behind traefik.... Well, ok, maybe because I only have web, not a second network...

Greets

@jce-zz
Copy link

jce-zz commented May 17, 2024

@MikeMatau Sure, this works. Because you are just using one network (web) for the container, even though you defined two in the compose file. ;-)

However, OP and I attach two (!) networks to the container and this does not work (just one of them works).

@MikeMatau
Copy link

MikeMatau commented May 17, 2024

I added the second network:

docker exec -ti maintainerr /bin/sh
/opt/app $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
180: eth0@if181: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:13:00:06 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.6/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever
182: eth1@if183: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:15:00:08 brd ff:ff:ff:ff:ff:ff
    inet 172.21.0.8/16 brd 172.21.255.255 scope global eth1
       valid_lft forever preferred_lft forever

I also still have the line 15 in /etc/supervisord.conf changed to include HOSTNAME=0.0.0.0:

2024-05-17 22:03:30,465 INFO success: ui entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
   ▲ Next.js 14.1.3
   - Local:        http://localhost:6246
   - Network:      http://0.0.0.0:6246

 ✓ Ready in 972ms

And it works totally fine....

For you to test:

Create a file ./maintainerr/supervisord.conf
Add everything from the original but change line 15 to environment=PORT=6246,HOSTNAME=0.0.0.0 and mount it like so:

      - type: bind
        source: ./maintainerr/supervisord.conf
        target: /etc/supervisord.conf

below the data folder...
docker compose dow and docker compose up -d and you are good to go, till @jorenn92 maybe fixes this

@jorenn92
Copy link
Owner

In PR #1104, @MikeMatau's workaround was incorporated in the default supervisord.config.

This will be available in the next release.

@craigcabrey
Copy link

Ideally we should use :: instead of 0.0.0.0 for IPv6 compatibility. In case anyone comes searching for that problem, I overwrote supervisord.conf in the container with :: instead, which enables global IPv4 & IPv6 support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants