Aus dem obigen Link kann ich ersehen, dass Bilder und Anhänge in einem tieferen gemeinsamen Ordner in der Discourse-Installation gespeichert werden, nicht innerhalb des Docker. Da ich einen symbolischen Link zu einem Bildordner von meinem zweiten Speicherort verwenden möchte, den ich per NFS auf andere Server mounte. Und auf einem sekundären Server möchte ich den Docker-Container von Discourse ausführen, um Lastenausgleich / Failover zu ermöglichen… und denselben Bildordner vom NFS-Mount verwenden. Ich habe bereits eine Datenbank von einem anderen Netzwerkspeicher, nur für den Fall.
Ich habe die Einstellung gerade getestet, aber das Ergebnis ist nicht gut. Ich habe alle Bilddateien von /var/discourse/shared/standalone/uploads nach /var/www/image/uploads kopiert
Dann,
Symbolische Links zum NFS-gemounteten Bildordner erstellt
chmod & chown mit www-data:www-data und 755 für die /uploads-Ordner
Ich kann Bilder auf dem primären Server sehen, auf dem der Bildordner nativ gemountet ist, aber nicht auf dem sekundären NFS-gemounteten Server. Bilder fehlen mit Containergröße.
Außerdem kann ich auf dem primären Server zwar Bilder sehen, aber nicht mehr herunterladen.
Ich vermute, es liegt an den Dateiberechtigungen. Ich frage mich, was die ideale Einstellung ist.
Ich bin mir nicht sicher, ob es sich um Vanilla handelt oder aufgrund von Dutzenden von Rebuilds, aber Bilder im Standardordner sind 755/644 (Ordner/Datei) und main_id:www-data auf meinem Server. Ich habe dieselbe Strategie angewendet, aber sie hat nicht funktioniert. Es könnte ein Problem mit symbolischen Links oder NFS sein, aber ich kann es nicht mehr nachvollziehen.
Anstatt eines Symlinks sollte die Docker-Bereitstellung auf Ihre NFS-Bereitstellung verweisen.
Aber die Synchronisierung von Berechtigungen innerhalb des Containers, außerhalb des Containers und auf dem entfernten NFS-Server kann sicherlich schwierig sein.
Das war mein erster Versuch. Im Docker habe ich festgestellt, dass das Dateisystem für meines etwas durcheinander war, was ich früher gefunden hatte. Es war verschachtelt /uploads/uploads/uploads, bevor /default/ gesehen wurde. Ich bin mir nicht sicher, was wirklich passiert ist, aber ich habe alle Dateien von innen in mein Image-Mount kopiert und den Mount-Ordner als Volume hinzugefügt.
Hier war die Situation nicht viel anders als bei Symlinks. Dateiberechtigungen verursachten tatsächlich das gleiche Problem. Nachdem ich verstanden hatte, dass Dateien tatsächlich außerhalb des Docker-Containers gespeichert werden, dachte ich, Symlinks könnten eine viel einfachere Lösung sein.
Für beides bin ich mir ziemlich sicher, dass es sich um Dateiberechtigungen handelt, aber ein benutzerdefiniertes CDN nur durch einen Nginx-Serverblock klingt nach einer viel einfacheren Lösung als Docker-Volumes, solange Symlinks nicht funktionieren.
Ich bin ziemlich sicher, dass nichts Gutes aus der Verwendung von Symlinks resultieren kann. Ein Problem ist, dass es schwierig ist, den Symlink innerhalb und außerhalb des Containers gleich zu halten, und ich vermute, dass Ihr Problem mit verschachtelten Uploads damit zusammenhängt. Ich habe schon empfohlen, keine Symlinks zu verwenden, und ich glaube, das ist der Grund.
Unterstützt Discourse eine CDN-Nutzung basierend auf benutzerdefinierten CNAMEs? Ich erinnere mich, S3-Konfigurationen im Admin-Bereich und Meta-Posts für Fastly gesehen zu haben, kann mich aber nicht genau an die Konfiguration für benutzerdefinierte CDNs erinnern.
Den Beitrag habe ich gefunden. Ich muss wohl eine selbst gehostete Version eines S3-kompatiblen CDN einrichten. Ein reiner Nginx-Bildserver reicht nicht aus.