Ich habe ein kleines Docker Tutorial geschrieben, da mir auf gefallen ist das viele Paperless Anwender hier nicht die Grundlagen mitbringen wie das betreiben von Paperless mittels Docker eigentlich im Unterbau funktioniert.
Das ist an sich nicht schlimm, da Stefan sehr gute Einsteiger Kurse für den Betrieb hat. Alles darüber hinaus birgt allerdings Probleme mit sich. Was ist wenn doch mal ein Fehler im Docker Betrieb auf taucht und was sind diese Images genau?
Grüße
3 „Gefällt mir“
webserver:
image: ghcr.io/paperless-ngx/paperless-ngx:2.20.6
Das image: unterhalb des webserver: Eintrages ist die Angabe darüber woher welches Image für den Container genommen werden soll. Das ist das so genannte Container Image, aus welchen dann bei einem START ein Container entsteht.
Der erste Teil ist die Containerimage Registry ghcr.io . Aus welche Registry die Images kommen spielt keine Rolle, wichtig ist das man weiß was das Image am Ende macht. Einige Anbieter gehen mittlerweile dahin und stellen die Images nicht mehr nur in der Public Docker Registry Namens Docker Hub bereit, sondern auch in Image Registry von Github. Das passiert vollautomatisch nach Änderungen im Code der Anwendung.
Alles nach ghcr.io ist der Pfad zum eigentlichen Image inklusive des Namens. Meistens der Name der Anwendung. Bei uns also paperless-ngx. Und nach dem : am Ende kommt der sogenannte Image Tag. In den meisten Fällen ist das die Version der Anwendung. Und nun etwas gaaanz wichtiges.
Man sollte versuchen hier immer eine eindeutige Version mit an zu geben, da es damit nachvollziehbarer ist welche Version genau aktuell am laufen ist. Bei Datenbanken kann man gerne auch :17 oder :18 angeben, also keine gaaanz genau Version. Die sogennaten Minor Releases sind meisten untereinander und mit der Anwendung kompatibel.
Was man aber niemals nimmer auf gar keinen Fall machen sollte ist dort ein :latest hin zu schreiben.
Denn dann weiß man gar nicht mehr welche Version man genau hat und was noch viel schlimmer ist es wird immer ein Image mit Tag latest runter geladen. Das bedeutet das man nie ein Update macht wenn man eingestellt hat das Docker nur neuere Versionen runter laden soll. Denn ein latest gibt es ja local schon.
1 „Gefällt mir“
Herzlichen Dank dafür!
Yamaneko, der bei Docker immer wieder ins Schleudern kommt
Hilfreiche Information - Dankeschön!
Docker Volumes:
Ergänzend zum o.g. Tutorial noch eine aus meiner Sicht wichtige Info zur Speicherung der Daten.
Es gibt bei Docker mehrere Möglichkeiten:
Die einfachste Variante, die Daten werden beim Start der Container temporär gespeichert.
Hier muss nichts zusätzlich konfiguriert werden.
Nachteil: Bei Neustart oder beenden des Containers sind die Daten verloren => ungeeignet für Paperless.
Deshalb gibt es die Möglichkeit Volumes zu nutzen. Eintrag in der docker-compose.yml.
Hier z.B. die gemäß Template von Paperless:
volumes:
- /paperless/data:/usr/src/paperless/data
- /paperless/media:/usr/src/paperless/media
- /paperless/export:/usr/src/paperless/export
- /paperless/consume:/usr/src/paperless/consume
Die Einträge rechts vom Doppelpunkt sind die internen (im Dockercontainer) Verzeichnise und exakt so, wie es die Entwickler vorgesehen haben.
Die Einträge links vom Doppelpunkt ist die externe Ordnerstruktur (i.d.R auf der NAS) und die Pfade völlig beliebig. Es muss nur für jeden benötigten internen Ordner einen externen Ordner geben.
D.h die externen Ordner werden nach innen projiziert(das ist ein Feature von Docker und hat nichts mit Paperless zu tun).
Also Paperless greift intern auf den Pfad /usr/src/paperless/consume um Dokumente einzulesen, durch die Zurodnung greift es dabei physikalisch auf /paperless/consume zu.
Wichtig: Auf diese externen Ordner muss der User/Gruppe berechtigt sein, der mit USERMAP_UID,USERMAP_GID für die Containerkonfiguration angegeben wurde.
Der Vorteil dabei ist, die Daten bleiben erhalten, auch wenn die Container nicht mehr laufen.
Und da die Daten nicht im Container selbst sind, kann leicht ein Backup der gewünschten Verzeichnisse erstellt werden.
Das was @aromedia beschreibt ist der sogenannte bind mount als Speichertyp. Also das einbinden von lokalen Verzeichnissen.
Es gibt auch den Speichertyp volume. Dabei werden volumes anglegt
docker volume ls
Hier kann man ganz viele volume plugins verwenden so das ein volume am Ende auch auf ein Netzwerkshare zeigen kann. NFS, SMB oder sshfs.
Wow Klasse, vielen Dank für diese tolle Einleitung in das Container-Thema. ja, du hast recht. Ich hab mich auch an der Anweisung von Stefan entlang gehangelt und so meine ersten Container auf den NAS gebracht.
Gruss
Franz
1 „Gefällt mir“