Hostname and port issues for services (Sonarr/Radarr)

[WoosterInitiative]

Describe the bug
My testing reveals that the UI ports for Sonarr and Radarr must be exposed by the container. Also, I am unable to use the hostname of the container (e.g. 'radarr' or 'sonarr'), I must use the IP address explicitly.

Are you on latest or develop branch?
Using "latest" branch as of ~10pm 12/14/20 PST

To Reproduce
Steps to reproduce the behavior:

1. Have the radarr or sonarr containers not set to expose any ports explicitly (on 'Ports' in docker-compose or -p in docker run)
2. Try to setup either service in Overseer
3. Testing will reveal that it is unable to connect to the container

Expected behavior
I expect to be able to leave the ports not exposed while using the hostname of the container.

Workaround
Expose the UI ports of Sonarr and Radarr from their containers and use the IP address in place of the hostname.

[sct]

This is a configuration issue. Not a bug.

[github-actions]

👋 @WoosterInitiative, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please use our support channels to get help with Overseerr.

• Discord - GitHub Discussions

[WoosterInitiative]

@sct

Wait, what? So I can't communicate to another docker container by name? And I have to expose the ports? That's at least a "limitation," otherwise known as a "bug lite."

I tried support and just about got laughed out, this should stay as at least a note for future users, perhaps even added as a caveat to the docs.

[sct]

You got laughed out of support? By who?

This isn't a limitation. There are several people in the discord referencing containers by their docker names in the docker network. It's a configuration issue with your docker network. Not with Overseerr.

[WoosterInitiative]

Interesting... I'll have to find those people. When I was in there everyone was doing it by ip and telling me I was wrong about "exposing" ports, which is the correct terminology.