Multiple networks doesnt work

[albinmedoc]

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

Device (please complete the following information):

• OS: Debian
• Version: 11

[albinmedoc]

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

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

[helangen]

I have the same setup and the same issue…

[albinmedoc]

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]

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]

@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]

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]

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]

@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]

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]

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

This will be available in the next release.