Die Installation von Paperless NGX auf Docker, das ist an sich kein Problem. Auf der Webseite von Paperless-ngx gibt es verschiedene Anleitungen für die Installation auf Docker:
https://docs.paperless-ngx.com/setup
Da fällt sicherlich das interaktive Installationsskript auf. Damit werden alle benötigten Parameter für die Installation abgefragt, daraus dann das Compose-File generiert und damit dann installiert. Bei diesem Produkt wohl die einfachste Variante, gerade für Neulinge in Docker.
Aber wir möchten Portainer nutzen und das auch für die Installation. Ist das für Paperless-ngx sinnvoll? Nicht unbedingt, aber wir können da was lernen. Oder anders ausgedrückt, mit dem Skript ist es einfach, mit Portainer kann man was lernen.
Interessant ist bei diesem Video die Nutzung der Speicherbereiche. Also wo legt Paperless-ngx die Dateien ab, wo werden sie importiert, wo exportiert. Und wo liegt die Datenbank? Im Docker liegt das alles unter /var zusammen mit vielen anderen Daten. Das ist gerade für ein Dokumenten-Management nicht gerade ideal. Also wollen wir die Ziele für die Daten umbiegen, also nicht unter /var sondern zum Beispiel unter /paperless. Das kann dann auch ein eigenes Filesystem sein, also volle Kontrolle über den Speicherverbrauch.
Eine Möglichkeit zeigen wir in dem folgenden Video:
zusätzliche Hinweise zum .yml File:
1. image: docker.io/library/postgres:17
Dies sagt Docker, die Version 17 von postgres SQL zu nehmen, also nur die 17er Version, nicht aber 18, wenn es denn verfügbar sein sollte.
2. image: ghcr.io/paperless-ngx/paperless-ngx:latest
Hier wird anders als bei postgres die neuste Version genutzt. Damit wird auch ein Versionssprung durchgeführt und es wird damit immer die neuste Version genutzt. Das hat Vor- aber auch Nachteile. Will man immer die neuste Version nutzen?
3. volumes: – data:/usr/src/paperless/data
Hier wird die Zuordnung der Speicherbereiche getroffen, auf dem Docker Host ist es data unter /var und in dem Container nutzt er den /usr/src/ Pfade. Also extern auf intern gemappt.
Hier könnte man direkt den neuen Pfad angeben für den Speicher. Also statt nur data dann /paperless/data
Für die Volumes gibt es verschiedene Möglichkeiten, diese können im Compose File zugeordnet werden, aber auch durch Docker-Befehle zentral verwaltet werden.
Volume-Definitionen im Compose File
In diesem Beispiel nutzen wir das Compose-File mit der Zuordnung bzw. dem Mount.
unter volumes:
data:
drive: local
driver_opts:
type: none
device: /paperless/data
o: bind
Die Zuordnung im Compose File ist flexibler und wird für eine Neuinstallation immer gleich bleiben. Wenn die Zuordnungen vorab per Command gemacht werden muss, dann kann dies vergessen werden (zum Beispiel bei einem Restore durch Neuinstallation).
Neben der Zuordnung von lokalen Filesystemen (oder einfach nur anderen Verzeichnissen) sind auch SMB oder NFS Filesysteme möglich. Die Definition ist sehr ähnlich, hier ein Beispiel für SMB / CIFS:
data:
driver_opts:
type: cifs
o: username=user,password=password,uid=1001,gid=101,vers=3.0
device: //192.168.1.1/share/data
Unter Device wird der Share auf dem NAS angegeben, so wie auch bei einem Standard-Linux-Mount. Unter dem o: findet sich neben User und Passwort auch uid und gid und die Version von SMB. User und Passwort sind notwendig, die 3 anderen Angaben nicht immer unbedingt.
Und dann noch ein Beispiel mit NFS:
data:
driver_opts:
type: "nfs"
o: "addr=192.168.1.1,nolock,soft,rw"
device: ":/share/data"
Die Angaben hinter dem o: mit dem nolock und soft und rw sind je nach NFS Server notwendig oder auch nicht.
Tipp: Die Angaben für SMB und NFS müssen häufig etwas ausgetestet werden. Am Besten vorab auf dem Docker Host direkt die Mounts testen. Damit ist die reine Funktion dann sichergestellt. 