[Help]: Cannot access webpage portal after container startup

[mataborg]

Controller Version

5.14.32.3

Describe Your Issue or Question

Cannot access portal webpage by IP:port after container creation. Logs seem to indicate the container is functioning normally.

Expected Behavior

Access web server at https://<>:8843 or http://<>:8088

Steps to Reproduce

Launch container in portainer EE using compose as a stack in Docker Swarm. Tried decalring the host network explicitly and just by port assignments.

How You're Launching the Container

---
version: '3.8'

services:
  omada:
    image: mbentley/omada-controller:latest-chromium
    ulimits:
      nofile:
        soft: 4096
        hard: 8192
    stop_grace_period: 30s
    environment:
      - PUID=12001
      - PGID=12000
      - MANAGE_HTTP_PORT=8088
      - MANAGE_HTTPS_PORT=8043
      - PORTAL_HTTP_PORT=8088
      - PORTAL_HTTPS_PORT=8843
      - PORT_APP_DISCOVERY=27001
      - PORT_ADOPT_V1=29812
      - PORT_UPGRADE_V1=29813
      - PORT_MANAGER_V1=29811
      - PORT_MANAGER_V2=29814
      - PORT_DISCOVERY=29810
      - PORT_TRANSFER_V2=29815
      - PORT_RTTY=29816
      - SHOW_SERVER_LOGS=true
      - SHOW_MONGODB_LOGS=false
      - SSL_CERT_NAME=tls.crt
      - SSL_KEY_NAME=tls.key
      - TZ=America/Boise
    volumes:
      - omada-data:/opt/tplink/EAPController/data
      - omada-logs:/opt/tplink/EAPController/logs

volumes:
  omada-data:
  omada-logs:

Container Logs

will attach later due to github dumping new discussion because of log size

MongoDB Logs

will attach later due to github dumping new discussion because of log size

Additional Context

No response

[mataborg]

mongod.log
nsx7vuey64mtfhwxpiu9pc8an_logs.txt

[mataborg]

Welp, on a hunch I started modifying the compose file to expose the following ports since host binding didn't seem to do the trick:
8088:8088
8043:8043
8843:8843

And the web portal finally popped up at port 8043. Not sure if this is expected behavior due to being deployed as part of a swarm?
Either way, I may recommend adding explicit ports to the default docker compose file:

version: "3.1"

services:
  omada-controller:
    container_name: omada-controller
    image: mbentley/omada-controller:5.14
    restart: unless-stopped
    ulimits:
      nofile:
        soft: 4096
        hard: 8192
    stop_grace_period: 60s
    network_mode: host
    environment:
      - PUID=508
      - PGID=508
      - MANAGE_HTTP_PORT=8088
      - MANAGE_HTTPS_PORT=8043
      - PORTAL_HTTP_PORT=8088
      - PORTAL_HTTPS_PORT=8843
      - PORT_APP_DISCOVERY=27001
      - PORT_ADOPT_V1=29812
      - PORT_UPGRADE_V1=29813
      - PORT_MANAGER_V1=29811
      - PORT_MANAGER_V2=29814
      - PORT_DISCOVERY=29810
      - PORT_TRANSFER_V2=29815
      - PORT_RTTY=29816
      - SHOW_SERVER_LOGS=true
      - SHOW_MONGODB_LOGS=false
      - SSL_CERT_NAME=tls.crt
      - SSL_KEY_NAME=tls.key
      - TZ=Etc/UTC
    volumes:
      - omada-data:/opt/tplink/EAPController/data
      - omada-logs:/opt/tplink/EAPController/logs
    **ports:
      - 8088:8088
      - 8843:8843
      - 8043:8043
      - 27001:27001
      - 19810:19810
      - 29810:29810
      - 29811:29811
      - 29812:29812
      - 29813:29813
      - 29814:29814
      - 29815:29815
      - 29816:29816**

volumes:
  omada-data:
  omada-logs:

[mbentley]

Yeah, the example compose file uses network_mode: host so ports are ignored.

8088 is the management portal on http; should just redirect to https
8043 is the management portal which is what http will redirect to
8843:8843 is for the client login portal, if enabled

[mataborg]

I'm a little confused then, when I set the network mode to host that didn't solve the issue, only explicitly declaring the ports allowed me to access the container. Does that work in standalone docker without swarm or stack usage?

[mbentley]

Oh sorry, I completely missed that you're trying to deploy this to a cluster with Swarm mode. I honestly do not recall the explicit behavior with Swarm mode as it relates to things like network host mode but that might explain your need for explicit port declaration although I haven't touched Swarm in probably 5 years so my knowledge is rusty and out of date.

The biggest question I would have when it comes to Swarm mode would be how you're handling persistent storage considering MongoDB can be picky about the backing storage filesystem. Not sure if you have a common networked file system or if you're relying on local host storage but that would be a problem if the container gets scheduled on a host that the volumes do not exist on.

Your best bet may be to explicitly call out the ports to expose and pin the container to a specific node using placement constraints unless you have multi-host storage figured out.