ips are changing

[christianmerges]

Hello,

please don't judge me that hard, in case this is the wrong place to ask. How do I choose the right IPs? Everytime I start the stack, new subnet and new IPs r assigned. what is the best way to assign IPs? The ip of which container schould be specified as "pms ip"? What is a Cluster-IP? Is it the first ip of the subnet?

[pabloromeo]

Hey!
No worries. So, now regarding dynamic IPs, you probably won't need to worry about that, they are IPs on a virtual network managed by docker.
Now, if you are running this on Docker Swarm, for the PMS_IP parameter you can actually just use the IP of ANY of the nodes in your cluster. Swarm will internally route traffic to the correct one running the plex service at that time.

I should actually explain it better in the docs. The PMS_IP is actually sent over to the orchestrator and it's used by the worker to later report transcode status back to the actual Plex server. So technically it's just the location at where to report back, and in the case of Swarm, that can be any node in the cluster. It's used to replace a hardcoded 127.0.0.1 specified by Plex in the transcode instructions. Come to think of it, maybe I can find a workaround so that this setting isn't even mandatory and resolved internally to the IP assigned by docker to the "plex" service. And just have the PMS_IP as an override in case someone runs Plex OUTSIDE of the cluster.

In fact, if you want to give it a shot, just set the PMS_IP value to the string "plex". Since "plex" is the service name in the stack it should resolve to it's IP.

In my case I'm doing it a bit differently: I run Keepalived as a replicated service on all nodes in order to have a virtual floating IP across the cluster with a single fixed IP from my real LAN. But that isn't necessary. That's the IP I referred to as "Cluster-IP", a virtual IP from your network that points to any available node at any given time. That's just for high availability in case any node is down temporarily.

Let me know if this helps

[christianmerges]

If u r right regarding to replacing IPs with Service names, this should be the recommended YAML-File.
In Portainer I see no Errors in the Stack section, but there are multiple containers created, because they fail all with the same error: curl: (7) Failed to connect to localhost port 32400: Connection refused

version: '3.4'

services:
  plex:
    image: ghcr.io/linuxserver/plex:latest
    deploy:
      mode: replicated
      replicas: 1
    environment:
      DOCKER_MODS: "ghcr.io/pabloromeo/clusterplex_dockermod:latest"
      VERSION: docker
      PUID: 1000
      PGID: 1000
      TZ: Europe/Berlin
      PLEX_CLAIM: "claim-123"
      ORCHESTRATOR_URL: http://plex-orchestrator:3500
      PMS_IP: plex
      TRANSCODE_OPERATING_MODE: both #(local|remote|both)
      TRANSCODER_VERBOSE: "1"   # 1=verbose, 0=silent
    healthcheck:
      test: curl -fsS http://localhost:32400/identity > /dev/null || exit 1
      interval: 15s
      timeout: 15s
      retries: 5
      start_period: 30s
    volumes:
      - /media/docker/config:/config
      - /media/docker/backups:/backups
      - /media/Filme:/data/movies
      - /media/Serien:/data/tv
      - /tmp/docker:/tmp
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 32400:32400


  plex-orchestrator:
    image: ghcr.io/pabloromeo/clusterplex_orchestrator:latest
    deploy:
      mode: replicated
      replicas: 1
      update_config:
        order: start-first
    healthcheck:
      test: curl -fsS http://localhost:3500/health > /dev/null || exit 1
      interval: 15s
      timeout: 15s
      retries: 5
      start_period: 30s
    environment:
      TZ: Europe/Berlin
      STREAM_SPLITTING: "OFF" # ON | OFF (default)
      LISTENING_PORT: 3500
      WORKER_SELECTION_STRATEGY: "LOAD_RANK" # RR | LOAD_CPU | LOAD_TASKS | LOAD_RANK (default)
    volumes:
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 3500:3500

  plex-worker:
    image: ghcr.io/linuxserver/plex:latest
    hostname: "plex-worker-{{.Node.Hostname}}"
    deploy:
      mode: global
      update_config:
        order: start-first
    environment:
      DOCKER_MODS: "ghcr.io/pabloromeo/clusterplex_worker_dockermod:latest"
      VERSION: docker
      PUID: 1000
      PGID: 1000
      TZ: Europe/Berlin
      LISTENING_PORT: 3501      # used by the healthcheck
      STAT_CPU_INTERVAL: 2000   # interval for reporting worker load metrics
      ORCHESTRATOR_URL: http://plex-orchestrator:3500
    healthcheck:
      test: curl -fsS http://localhost:3501/health > /dev/null || exit 1
      interval: 15s
      timeout: 15s
      retries: 5
      start_period: 240s
    volumes:
      - /media/docker/codecs:/codecs # (optional, can be used to share codecs)
      - /media/Filme:/data/movies
      - /media/Serien:/data/tv
      - /tmp/docker:/tmp
      - /etc/localtime:/etc/localtime:ro

[christianmerges]

I changed now all services to: start_period: 600s
Still waiting for the workers to come online, but orchenstrator and plex r running.

[pabloromeo]

Yeah, it looked like the healthcheck for your plex service was failing. It might have been that on first run Plex takes longer to start up and is was being shut down by the orchestrator.

After your question I did try using "plex" as an IP, and in fact the worker transcoding did work and reported back, however, there might be issues with plex itself rejecting that network traffic and playback would appear to be waiting. Plex is a bit restrictive with what source IPs can send status posts to it, it seems, and you'll have to set up proper network ranges for both external traffic as well as docker ip ranges for it not to reject the status updates from the worker. There's info regarding that in the README.
If that doesn't work you can always set PMS_IP to the IP of one of the nodes.

[christianmerges]

Thank u. Is reference plex-orchestrator as hostname working? I have currently some iptables problems to fix, so it would be glad to know, that this is not the issue.

[pabloromeo]

You mean for ORCHESTRATOR_URL? Yeah, I see no reason why that wouldn't work just using the service name. That's how I have it running. That's just docker resolving service names to internal IPs, nothing specific being done by the app itself.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.