Container Station, ENV-Dateien für einen Docker – vs SSH

Soweit ich das verstanden habe, unterstützt QNAP einfach keine .env-Dateien als Teil einer YAML für Docker und plant dies auch nicht, zumindest nicht nativ in der Container Station. Ich habe gesehen, dass ich einen Docker-Container per SSH erstellen kann, und dieser wird dann auch in der Container Station angezeigt – aber die GUI funktioniert dann eigentlich gar nicht (keine Befehle, man muss wieder per SSH auf den Container zugreifen, um ihn zu verwalten). Das stört mich nicht unbedingt, aber wenn ich per SSH mit einer identischen YAML docker compose verwende, funktioniert es nie ganz richtig – ich vermute, das liegt irgendwie am virtuellen Switch/Netzwerk oder vielleicht an Speicherreferenzen, die nicht übernommen werden. Die gleiche YAML kann ich in der Container Station verwenden und es funktioniert problemlos.

Hat jemand ähnliche Erfahrungen gemacht? Es macht mir nichts aus, die Variablen direkt in die YAML zu schreiben, aber ich verstehe nicht, warum es nicht erfolgreich funktioniert. Leider bin ich nicht versiert genug mit Docker und Linux, um herauszufinden, wo der Fehler liegt.

Konkret habe ich das mit Immich ausprobiert: Docker Compose [Recommended] | Immich

Ich habe aufgegeben, vollständiges CS für Docker zu verwenden.

Nutze CS für Portainer/Dockge und verwende das dann für die Administration.

Erstelle eine neue Application in CS.

services:
  portainer:
    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:
    container_name: dockerproxy
    image: ghcr.io/tecnativa/docker-socket-proxy:latest
    environment:
#      - PUID=1001
#      - PGID=1000
      - TZ=America/Toronto
      - CONTAINERS=1 # Zugriff auf die Anzeige von Containern erlauben
      - SERVICES=1 # Zugriff auf die Anzeige von Services erlauben (notwendig bei Verwendung von Docker Swarm)
      - TASKS=1 # Zugriff auf die Anzeige von Tasks erlauben (notwendig bei Verwendung von Docker Swarm)
      - POST=0 # Jegliche POST-Operationen verbieten (effektiv nur Lesezugriff)
    ports:
      - 127.0.0.1:2375:2375
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro # Als read-only eingebunden
    restart: unless-stopped

Was ist das dockerproxy, das du dort hast? Ich habe das noch nie verwendet, ist das notwendig?

Es täuscht vor, Docker zu sein, damit ich allem Zugriff auf den Docker-Daemon geben kann, ohne ihnen ungefilterten, direkten Zugriff auf Docker zu gewähren.

Du brauchst es wahrscheinlich nicht, aber es gibt mir ein besseres Gefühl.

Ich habe .env gerade mit einer einfachen docker-compose.yml auf meinem QNAP getestet und es hat per SSH einwandfrei funktioniert.

Wenn du deine docker-compose.yml und die .env-Datei teilen kannst (du kannst alle sensiblen Daten entfernen), teste ich das gerne für dich und schaue, woran es liegen könnte.

Ich habe einen Tippfehler im YAML gefunden, die Ursache aller Probleme hier, also funktioniert jetzt alles einwandfrei, genau wie du gesagt hast!

Ich denke, ich werde Portainer ausprobieren – wenn die Leute es lieber mögen als CS. Ermöglicht es mir, die grundlegenden Dinge zu erledigen, ohne per SSH einzuloggen, auch wenn ich es über die Kommandozeile erstellt habe (anders als CS)?

Wie ich bereits gepostet habe, kannst du Portainer problemlos über CS zum Laufen bringen. Du kannst es sogar komplett ohne SSH machen. Erstelle einfach eine neue Anwendung in CS und füge das YAML ein.

Ich empfehle ein wenig SSH, um ein weiteres Share und einen Storage-Pool einzurichten.
Ich verwende /share/docker/. So kann nichts, was CS macht, jemals meine Sachen berühren, die ich mit Portainer erstellt habe.

Die Verwendung von .env-Dateien über die Kommandozeile (SSH-Zugang) funktioniert einwandfrei, wie auch andere bereits gesagt haben. Ich betreibe Dockhand in einem privilegierten Container und verwalte dann alles von dort aus. Zum Beispiel mit einer docker-compose.yaml-Datei wie dieser:

volumes:
  dockhand_data:

services:
  dockhand:
    image: fnsys/dockhand:latest
    container_name: dockhand
    restart: unless-stopped
    user: "0:0"
    ports:
      - 3000:3000
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - dockhand_data:/app/data