known proxy for jellyfin in container?
from barbara@lemmy.ml to selfhosted@lemmy.world on 05 Apr 2024 14:07
https://lemmy.ml/post/14092453

I’ve got jellyfin and nginx proxy manager running in two separate containers. What do I need to specify in known proxies? The ip is changing frequently which means I can’t use it.

I try setting the ip in the compose file but something is wrong. nginx proxy manager:

22     networks:
23	 npm:
24         ipv_address: 172.20.0.2
25
26 networks:
27   npm:
28     driver: bridge
29     ipam:
30	 config:
31         - subnet: 172.20.0.0/24
32           gateway: 172.20.0.1
33

and

jellyfin:

32     networks:
33	 npm:
34         ipv_address: 172.20.0.3
35
36 networks:
37   npm:
38     driver: bridge
39     ipam:
40	 config:
41         - subnet: 172.20.0.0/24
42           gateway: 172.20.0.1

jellyfin log: [16:08:01] [INF] [16] Emby.Server.Implementations.HttpServer.WebSocketManager: WS 172.20.3.11 request

can someone point me into the right direction?

#selfhosted

threaded - newest

JASN_DE@lemmy.world on 05 Apr 2024 14:20 next collapse

That setting also takes host names. As long as both containers share at least one network, put in the service name (not the container_name!), e.g. “npm” or whatever yours is called and you should be fine.

atzanteol@sh.itjust.works on 05 Apr 2024 14:20 next collapse

Put them on different subnets and use the gateway IP address maybe?

barbara@lemmy.ml on 05 Apr 2024 14:28 collapse

When using a different subnet, the requests come from

[16:27:24] [INF] [35] Emby.Server.Implementations.HttpServer.WebSocketManager: WS 10.89.2.6 request

chiisana@lemmy.chiisana.net on 05 Apr 2024 14:31 next collapse

Last time this was asked, I’ve voiced the concern that tying fixed IP address to container definitions is an anti-pattern, and I’ll voice that again. You shouldn’t be defining a fixed IP address to individual services as that prevents future scaling.

Instead, you should leverage service discover mechanisms to help your services identify each other and wire up that way.

It seemed like in NPM, there is no fitting mechanisms out of the box. Which may suggest your use case is out growing what it may be able to service you for in the future. However, docker compose stacks may rescue the current implementation with DNS resolution. Try simplifying your npm’s docker compose to just this:

   networks:
      - npm

networks:
  npm:
    name: npm_default
    external: true

And your jellyfin compose with something like:

   networks:
      - npm
      - jellyfin_net

networks:
  npm:
    name: npm_default
    external: true
  jellyfin_net:
    name: jellyfin_net
    internal: true

Have your other services in Jellyfin stack stay only on jellyfin_net or whatever you define it to be, so they’re not exposed to npm/other services. Then in the configs, have your npm talk direct to the name of your jellyfin service using hostname, maybe something like jellyfin or whatever you’ve set as the service name. You may need to include the compose stack as prefix, too. This should then allow your npm to talk to your jellyfin via the docker compose networks’ DNS directly.

Good luck!

steersman2484@sh.itjust.works on 05 Apr 2024 15:07 next collapse

I agree on your take, but I don’t think that “future scaling” is a concern for the most home users.

chiisana@lemmy.chiisana.net on 05 Apr 2024 15:10 collapse

It may not affect this current use case for a home media server, but people should still be aware of it so as they learn and grow, they don’t paint themselves in a corner by knowing only the anti patterns as the path forward.

jake_jake_jake_@lemmy.world on 05 Apr 2024 17:51 next collapse

as someone who does stuff in my lab that can translate to a work context, i absolutely second this opinion.

if i am labbing to learn, then learning the best way to do it is always be the main focus, even if it means restarting what I was doing to change how some prerequisite is setup or functions.

today, OP is working with jellyfin, but as an example, what happens if later they get security cameras and want to use some sort of local ML to analyze events, and don’t want to put a lot cpu utilization to that task during lulls in activity? a solution might be to dynamically create and destroy containers for the analysis tasks, and the background on a network setup in an unrelated container stack that would allow scaling that means one less problem to solve later.

Lifebandit666@feddit.uk on 11 Apr 2024 20:48 collapse

I’m glad you commented as I didn’t know I can define 2 networks in Docker. At the moment I’m trying to get Arr working in docker and it was going well until I realised my containers can’t communicate with Plex. I believe it’s because I’m using Gluetun and I haven’t enabled LAN networking on my VPN. but theoretically the apps that need to see Plex don’t need to be behind the VPN, but they didn’t work when they weren’t because they couldn’t talk to Prowlarr.

So theoretically I could just slap “bridge” in my network as well, and then they’ll be in Gluetun and out of it at the same time.

I may try it tomorrow. Thanks for your comment

barbara@lemmy.ml on 06 Apr 2024 08:12 collapse

Thank you! I’ll have a look into it

Decronym@lemmy.decronym.xyz on 11 Apr 2024 20:55 collapse

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters More Letters
DNS Domain Name Service/System
IP Internet Protocol
Plex Brand of media server package
VPN Virtual Private Network

[Thread #674 for this sub, first seen 11th Apr 2024, 20:55] [FAQ] [Full list] [Contact] [Source code]