Erster Edit: vorheriger Post https://feddit.de/post/2992576
Erstaunlicherweise früher als gedacht, bin ich an dem Punkt, an dem ich ein (für mich) halbwegs laufendes Konzept habe.
An dem vorher genannten Setting hat sich nicht mehr viel geändert.
Auf dem Weg dahin hab ich nun doch mich mit dem ein oder anderen Programm oberflächlich auseinandergesetzt.
Was zur Überlegung stand:
PhotoPrism - Yoah .. fett würde es ganz gut treffen .. und zu fett für den BananaPi
PiGallery - macht schon Probleme auf der Demo Seite und läuft nur über Docker
----
Btw. Docker ist für mich Ausschlußkriterium
----
Später kam mir der Gedanke, es muss ja gar keine Fotoverwaltung als solche sein, sondern ein einfacher Dateidienst, ähnlich wie gDrive, würde mir ja auch reichen.
Als mir beim noch stärkeren überlegen einfiel, dass ich auch bei diesen Programmen das Problem haben werde Thumbnails erzeugen zu müssen + dass ich jedes Bild zum Betrachten auf dem Handy komplett laden muss (3mb vs 15mb), war die Idee ganz schnell vom Tisch.
Wen es interessiert, es wäre Seafile geworden.
Sehr schönes Produkt aus Deutschland, glaube ich zumindest.
Mit sämtlichen Erklärvideos vom Hersteller selber auf Youtube;
wer also genug hat von nextcloud, ist bei Seafile sehr gut aufgehoben.
Meine aktuelle Lösung ist folgende:
Piwigo + XnConvert + WinScp
Kurz zu Piwigo, diesem tollem Stück Software.
Man kann die zu hostenden Bilder auf zwei Arten anlegen;
virtuell oder "hart".
Virtuell bedeutet, dass man das/die Bild(er) in Piwigo hochlädt;
die kommen dann in einen Ordner "upload" und können in Piwigo frei umhersortiert werden, von Ordner zu Ordner zu Ordner zu Ordner.
Hart oder Fest, you name it, bedeutet, dass man einen Ordner samt Bilder in den Ordner "Gallerie" ablegt;
dieser wird dann in Piwigo als Album angezeigt und ist fix.
Der bleibt so wie er ist, ohne späterer Möglichkeit zum Nachsortieren.
Und nun kommen wir zum springenden Punkt:
Fest oder lose? Wenn ich die Bilder "hochlade" habe ich keine Chance von Extern Thumbnails einzuspielen, da die Bilder von Piwigo umbenannt werden und ich mir die neuen Namen mühseelig zusammensuchen müsste.
Wenn ich die Bilder nur ablege, hab ich das Problem, dass ich im Nachgang nur sehr müßig die Struktur ändern kann =/
Der Prozess:
Nun .. ich hab gestern Abend den ersten Testlauf gemacht mit 300 Bildern.
Hier die Auflistung im zeitlichen Verlauf:
Die Originalbilder bleiben die ganze Zeit auf der SD Karte;
was am längsten dauert wird zuerst begonnen; das Erstellen der Thumbs.
Hierfür brauch ich derzeit 3 Durchläufe, welche bei 300 Pic insgesamt ca 30min Zeit in Anspruch nehmen.
Deswegen zuerst XnConvert füttern für die Durchläufe th(200px) me(792px) und xl(1224px)
Netterweise werden die Bilder direkt mit richtigen Namen (nämlich "-me/th/xl.jpg" ausgeworfen und kommen in einen Zwischenordner auf dem Läppi.
Während die Thumbs erstellt werden, kopiere ich die originalen Bilder auf die HDD per WinScp, dass sollte lange vor den Thumbs fertig sein.
Im Anschluss wird Piwigo aufgefordert, die neuen Bilder in die Datenbank aufzunehmen (und gleichzeitig die Verzeichnisse für die Thumbs zu erstellen).
Wenn geschehen, werden die Thumbs hinterher geschoben und (derzeit noch) mit chmod/chown verfügbar gemacht ..
Ich glaub das war es soweit .. Nachträge werden editiert.
Rein aus Interesse: Warum?
Nichts was ich mit Fakten untermauern kann; also rein persönliche Ansicht.
Ich verfolge immer das Credo: So wenig wie möglich, so viel wie nötig.
Linux hatte für mich schon immer den Vorteil der gemeinsam genutzten Bibliotheken;
ich muss ffmpeg nur einmal vorhalten und nicht in 8 Programmen separat; dagegen verstößt Docker, da alles was man braucht, in dem Image gespeichert ist.
Docker virtualisiert .. Virtualisieren kann nach mein dafür nicht performant sein, auf jeden Fall nicht so, wie ein natives Programm.
Container sind keine Virtualisierung im Sinne einer VM. Viel mehr funktionieren sie (zumindest unter Linux, keine Ahnung von Windows) über Kernel-kontrollierte Ressourcenverwaltung und Abschottung vom Host und anderen Containern (konkret hauptsächlich mittels CGroups & Namespaces). Die eine Sache, die du in keinem Docker-Image finden wirst, ist ein OS-Kernel, der den Container verwaltet, denn das passiert alles nativ über den Kernel des Hosts. Also weniger Virtualisierung als Sandboxing.
Es geht also so gut wie keine Performance verloren, zumindest verglichen mit einer VM, einfach weil der rechenintensive Teil von Hypervisors wie VirtualBox/KVM+Qemu, das Emulieren von privilegierten Instruktionen, schlicht nicht nötig ist.
Ich geb dir natürlich Recht, dass man tendenziell mehr Speicher benötigt, wenn man 8 Instanzen von libffmpeg halten muss. Aber sobald einer deiner Dienste aus irgendeinem Grund nicht mit der aktuellen Version davon funktioniert, die anderen aber die neueste Version brauchen, ist Docker sehr praktisch, denn man muss sich einfach nicht mehr mit Versionskonflikten in den verwendeten Bibliotheken etc. rumschlagen, wenn jeder Container eigene kompatible Versionen mitbringt.
Notiz am Rande: Windows verwendet genauso gemeinsam genutzte Bibliotheken. DLLs sind konzeptionell nix anderes als .so Bibliotheken unter Linux. Die Bibliotheken unter C:\System32 sind ein gutes Beispiel.
Jemand hatte Container Mal als "chroot with an advertisment budget" beschrieben. Finde ich zum rüberbringen der Grundidee ganz gut
Und zusammen mit Stacks / Docker-Compose kann man sich Container-Landschaften bauen, die sich binnen weniger Minuten auf jedem anderen Docker (gleicher CPU-Architektur) replizieren lassen. Ich hab meinen steinalten (und lahmen) Raspberry Pi 2, der nur zum Sammeln von ADS-B Flugzeugdaten da ist, auf Container umgestellt. Von der Performance her konnte ich keine Veränderung feststellen. Dafür kann ich jetzt aber die ganze Geschichte (Anbindung an alle bekannten Sammeldienste) binnen kürzester Zeit wieder zum Laufen bringen, sollte die SD-Karte mackig werden.
Vielen Dank für deinen Beitrag, der Punkt mit den Versionskonflikten ist Tatsache ein Punkt, dass hat mir schon des öfteren Mal ein Knüppel zwischen die Beine geworfen.
Ich muss aber dazu sagen, dass ich grundsätzlich aus der Schleife bin und deswegen vielleicht auch träge bei neuen (hab ~2014 davon gelesen gehabt) Entwicklung.
Native Applikationen sind ja auch weiterhin ne gute Sache für bestimmte Anwendungsfälle, in denen Docker die Sache einfach schwieriger macht. Beispiel von mir: für's Management meiner Access Points betreibe ich einen Unifi Controller in einem Docker, was an sich kein Problem ist. Wenn man dann aber anfängt, mit VLANs und Konsorten zu hantieren, muss man einige Verrenkungen machen, damit der relevante Traffic auch im Container ankommt. Wenn man den Controller nativ betreibt, hat man sich quasi einen Mittelsmann gespart.
Ist ja nicht verkehrt, manche Trends verschwinden ja nach ein paar Jahren auch wieder :D
Für viele nützliche Dienste gibt es inzwischen auch häufig direkt vom Entwickler docker-compose Files, die es echt trivial machen, eine Anwendung inklusive aller benötigten anderen Dienste hochzufahren und somit einen guten Startpunkt liefern, sich mal näher mit der Materie zu beschäftigen.
Aber Docker ist wirklich super praktisch. Ich hatte die "Idee" hinter Docker mal irgendwo als Meme gesehen, was in Textform ungefähr so geht: "But it works on my machine!" - "Well, then we'll just ship your machine"