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

Running containers missing from display due to how ports are assigned. #533

Open
2 tasks done
ShanDestromp opened this issue May 27, 2024 · 1 comment
Open
2 tasks done
Labels
bug Something isn't working

Comments

@ShanDestromp
Copy link

⚠️ Please verify that this bug has NOT been reported before.

  • I checked and didn't find similar issue

🛡️ Security Policy

Description

Possibly related to #429 and #286 (the latter seems really likely to me).

I have a stack with 7 containers, however when running (and all containers are active and accessible) only 3 are displayed. If I edit the stack while editing it lists them all, but as soon as I save the stack it reverts back to displaying just the 3. The stacks displayed are always consistent and not related to their position in the compose file. The reason I think it might be related to #286 is because the 3 that display have standard

 ports:
      - 9696:9696

layout, while those that are "missing" use the "published / target" style:

    ports:
      - published: 6789
        target: 8080

If I change the port style of one of the "missing" containers to the simpler "external:internal" style, and save the stack, the container will show up on the list as expected.

👟 Reproduction steps

Assign ports like this:

    ports:
      - published: 6789
        target: 8080

👀 Expected behavior

All containers are visible regardless of the "style" used I guess?

😓 Actual Behavior

Some containers missing from display.

Dockge Version

1.4.2

💻 Operating System and Arch

Debian 12

🌐 Browser

Chrome / FF

🐋 Docker Version

No response

🟩 NodeJS Version

No response

📝 Relevant log output

The only thing in the dockage logs is this repeated basically forever:

05/27/2024 08:00:19 AM 2024-05-27T12:00:19Z [TERMINALRESIZE] INFO: Terminal: compose--monitoring
05/27/2024 08:00:19 AM 2024-05-27T12:00:19Z [TERMINALRESIZE] INFO: Terminal: combined--monitoring
05/27/2024 08:27:56 AM 2024-05-27T12:27:56Z [AUTH] INFO: Origin is not set, IP: ::ffff:192.168.1.3
05/27/2024 08:27:56 AM 2024-05-27T12:27:56Z [SERVER] INFO: Socket connected (direct)
@ShanDestromp ShanDestromp added the bug Something isn't working label May 27, 2024
@wsw70
Copy link

wsw70 commented Oct 29, 2024

Ha, I have the same problem, but for some other reason - though closely related (ports)

My configuration of Gitea that shows the behaviour of this bug is below. It is a configuration where the reverse proxy takes care of the access to the web interface, and an extra port is exposed (TBH I do not remember why anymore but it does no matter)

 gitea:
    image: gitea/gitea:latest
    labels:
      - traefik.http.services.gitea.loadbalancer.server.port=3000
    ports:
      - 13352
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - gitea:/data

However if I remove the exposed port the container is correctly displayed in the dockge:

 gitea:
    image: gitea/gitea:latest
    labels:
      - traefik.http.services.gitea.loadbalancer.server.port=3000
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - gitea:/data

There is indeed something wrong with the ports parsing/management

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants