I’d argue if you’re going do the rabbit hole of *arr you want to use Portainer to setup your containers.
Make an application in CS3+, CS controls Portainer, use Portainer to control everything else. Modifying stuff in CS sucks, mapping docker commandline to CS sucks, mapping docker compose to CS sucks slightly less.
Portainer is the correct approach.
(I’m using a proxy since everything I want to play with wants the docker.sock, and I don’t feel like fixing stuff in QNAP if an app/container does something stupid with the socket.)
networks:
# create the below network before running this template
external_edge:
external: true
services:
portainer:
networks:
external_edge:
ipv4_address: 172.27.1.250
container_name: portainer-ce
image: portainer/portainer-ce:latest
security_opt:
- no-new-privileges:true
environment:
- TZ=America/Toronto
ports:
- 9001:8000
- 9000:9000
- 9043:9443
volumes:
- /var/run/docker.sock:/var/run/docker.sock:rw
- /share/Container/portainer-ce/data:/data:rw
restart: always
dockerproxy:
networks:
external_edge:
ipv4_address: 172.27.1.251
container_name: dockerproxy
image: ghcr.io/tecnativa/docker-socket-proxy:latest
environment:
# - PUID=1001
# - PGID=1000
- TZ=America/Toronto
- CONTAINERS=1 # Allow access to viewing containers
- SERVICES=1 # Allow access to viewing services (necessary when using Docker Swarm)
- TASKS=1 # Allow access to viewing tasks (necessary when using Docker Swarm)
- POST=0 # Disallow any POST operations (effectively read-only)
ports:
- 127.0.0.1:2375:2375
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro # Mounted as read-only
restart: unless-stopped