Wie ein lokales Synology-Volume im Portainer definieren?

[ara]

Moin Moin, ich folge gerade der Anleitung "ioBroker unter Docker auf der Synology DiskStation (ab v3) " und habe bei der Definition des neuen Containers das Problem, dass ich kein Volume auswählen kann. Offensichtlich, weil ich noch gar keins angelegt habe im portainer. Ich kann jedenfalls keinen eigenen Pfad eingeben und das Dropdown ist logischerweise leer. Nun zur Frage: Wie muss ich ein lokales Volume VON DER SYNOLOGY angeben auf der Portainer läuft? Letzlich will ich ja in der Container-Definition dann ja "/volume2/docker/iobroker" anwählen können.

[vepman]

@ara
Ich hatte das so unter meiner Synology:

Vieleicht hilft es.

[ara]

@vepman Ja, das kenne ich. Diesmal geht es aber um Portainer. Habs grad gelöst: Man muss den Container-Share auf BIND stellen, dann kann man im Feld Host auch den Pfad eingeben.
Trozdem danke für Deine Reaktion.

[A Former User]

@ara sagte in Wie ein lokales Synology-Volume im Portainer definieren?:

Diesmal geht es aber um Portainer.

Moin,

unter dem neuen Container-Manager der DSM 7.2 und/oder Portainer würde ich an Deiner Stelle lieber mit Docker Compose Dateien arbeiten, auf die Schnelle, das sind Beschreibungen, wie der fertige Docker Container aus sehnen soll.
Beispiel Portainer auf der Synology:

version: '0.1'

services:
  Portainer:
    container_name: Portainer_ds716plus2
    image: portainer/portainer-ce:latest
    restart: always
    environment:
      AGENT_SECRET: keineAhnungwasichhiermache
    network_mode: "bridge"
    ports:
      - 8000:8000
      - 9000:9000
      - 9433:9443
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /volume1/docker/portainer:/data

Wenn man dann mit Volumes arbeitet, kann man diese vorher in der DiskStation anlegen. Hier kann man auch Environment Einstellungen mitgeben, um den Container zu modifizieren.

Unter Portainer heißen die Stack
Beispiel immich Fotoverwalltung



Wenn dann ein neues Image da ist, brauche ich nur auf Update the Stack klicken

Es wird das aktuelle Image geholt und der/die Container werden auf den aktuellen Stand gebracht, im Fall von immich sind das gleich 5 Container, alles wird auch in der richtigen Reihenfolge gemacht.

version: "3.8"

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    command: [ "start.sh", "immich" ]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
    env_file:
      - stack.env
    depends_on:
      - redis
      - database
      - typesense
    restart: always

  immich-microservices:
    container_name: immich_microservices
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    command: [ "start.sh", "microservices" ]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
    env_file:
      - stack.env
    depends_on:
      - redis
      - database
      - typesense
    restart: always

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    env_file:
      - stack.env
    restart: always

  immich-web:
    container_name: immich_web
    image: ghcr.io/immich-app/immich-web:${IMMICH_VERSION:-release}
    env_file:
      - stack.env
    restart: always

  typesense:
    container_name: immich_typesense
    image: typesense/typesense:0.24.1@sha256:9bcff2b829f12074426ca044b56160ca9d777a0c488303469143dd9f8259d4dd
    environment:
      - TYPESENSE_API_KEY=${TYPESENSE_API_KEY}
      - TYPESENSE_DATA_DIR=/data
    volumes:
      - tsdata:/data
    restart: always

  redis:
    container_name: immich_redis
    image: redis:6.2-alpine@sha256:70a7a5b641117670beae0d80658430853896b5ef269ccf00d1827427e3263fa3
    restart: always

  database:
    container_name: immich_postgres
    image: postgres:14-alpine@sha256:28407a9961e76f2d285dc6991e8e48893503cc3836a4755bbc2d40bcc272a441
    env_file:
      - stack.env
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
    volumes:
      - pgdata:/var/lib/postgresql/data
    restart: always

  immich-proxy:
    container_name: immich_proxy
    image: ghcr.io/immich-app/immich-proxy:${IMMICH_VERSION:-release}
    environment:
      # Make sure these values get passed through from the env file
      - IMMICH_SERVER_URL
      - IMMICH_WEB_URL
    ports:
      - 2283:8080
    depends_on:
      - immich-server
      - immich-web
    restart: always

volumes:
  pgdata:
  model-cache:
  tsdata:

Sorry für ein nicht ioBroker Beispiel, die beiden Beispiele verdeutlichen aber ganz gut was damit alles möglich ist.

VG
Bernd

[ara]

@dp20eic Ja, den Docker compose benutze ich auch.
Allerdings war hier die Empfehlung den portainer zu nutzen.
Ehrlich gesagt bin ich mir auch nicht schlüssig, welche "Verwaltung" hier die bessere ist.
Hat den Docker compose portainer quasi abgelöst weil neuer?

Blick da noch nicht so durch. -.-

[A Former User]

@ara sagte in Wie ein lokales Synology-Volume im Portainer definieren?:

Hat den Docker compose portainer quasi abgelöst weil neuer?

Moin,

ich kenne da die historischen Daten nicht. Also für mich ist das alles das gleiche, egal ob das jetzt der Container Manager unter DSM 7.2 ist oder ob das Portainer und die Stacks sind, in beiden Fällen wird intern Docker Compose ausgeführt, oder etwas benutzt, was dem gleich kommt.
Ich habe den Portainer halt mit dem internen Tool der Synology erstellt, was ja logisch ist
Alles andere mache ich jetzt im Portainer, egal ob es nur mal so schnell ein Container zum Testen ist oder etwas als Stack für den Produktiven gebrauch. In 99 % aller Fälle finde ich auch ein Compose File, das ich dann nur an meine Wünsche anpasse.

Ach so, nein, da ist nichts abgelöst. Docker Compose ist nur eine Technik, im Docker Universum, das Portainer oder alle anderen Container Verwaltungstools auch nutzen. Nicht schlagen, wenn das nicht ganz wissenschaftlich korrekt ist

VG
Bernd