Ja, aber du hast es in deinem Punkt #2 außer Kraft gesetzt, also legst du damit wieder Dateien in S3 ab.
Die Einstellungen in der Datei app.yml werden ausschließlich beim Neuaufbau des Containers verwendet und dienen zur Befüllung der Datei config/discourse.conf im zu erstellenden Container.
Ahh! Wenn also irgendwelche s3_-Variablen in meiner conf/discourse.conf-Datei vorhanden sind, geht Discourse davon aus, dass S3-Uploads aktiviert sind? Ok… verstanden… Ich werde das entfernen und es noch einmal versuchen.
Wahrscheinlich gibt es nur eine, die zählt… Ich bin gerade nicht an meinem Computer, um zu prüfen, was genau das auslösen könnte, aber wenn diese Prüfung auslöst, würde ich erwarten, dass deine Seite alle neuen Uploads zu S3 hochlädt.
Es funktioniert, es funktioniert, es funktioniert, esfunktioniertesfunktioniert! Juhu!!! Vielen Dank für eure ganze Arbeit und dafür, dass ihr mir so geduldig erklärt habt, was ich tun muss. Es ist großartig, dass wir jetzt damit starten können.
Also, ein paar kurze Fragen, damit ich besser verstehe, was genau passiert…
Ich habe bisher jeweils 100 Einträge auf einmal verarbeitet. In den ersten Durchläufen hat das Tool Beiträge migriert (?), aber jetzt werden nur noch Bilder kopiert. Ich habe Tausende und Abertausende von Beiträgen, und jeder davon hat normalerweise nur ein angehängtes Bild… also bin ich mir nicht sicher, warum/wie es „keine Beiträge mehr zum Migrieren“ gab? Was bedeutet es eigentlich, einen Beitrag zu migrieren? Das ist also Frage 1: Was genau passiert hier? 
Frage 2 ist einfacher: Jetzt, wo das Tool nur noch Bilder kopiert, stelle ich fest, dass 2X-Bilder lokal als 3X-Bilder kopiert werden:
Downloaded 27/100: //my-forum-storage.s3.dualstack.us-east-1.amazonaws.com/original/2X/1/14c56ef9f1dddb7b7a6f14e920234e0f714ea699.jpeg to /uploads/default/original/3X/1/4/14c56ef9f1dddb7b7a6f14e920234e0f714ea699.jpeg
Beachtet, dass sich die URL von 2X/1/xyz.jpeg zu 3X/1/4/xyz.jpeg ändert (ein zusätzlicher Ordnerpfad ist enthalten).
Ist das in Ordnung?
Schließlich habe ich die Bilder stichprobenartig geprüft, und sie scheinen in Ordnung zu sein. Da ich aber nicht weiß, zu welchem Beitrag jedes Bild gehört, kann ich keine „Live“-Prüfung im Forum durchführen und zu 100 % sicher sein, dass meine Nutzer das Richtige sehen. Wie kann ich den Dateinamen einer JPEG-Datei einem Forumbeitrag zuordnen?
Welche Befehle hast du genau eingegeben? Du musst das Limit erweitern, um alle deine Beiträge abzudecken.
Am Ende habe ich ein hohes Limit festgelegt, sobald ich sicher war, dass ich in die nächste Phase übergehe. Etwas wie folgt:
bin/rake uploads:batch_migrate_from_s3[100,100000]
Es migriert zuerst die Uploads, die es in Beiträgen findet; es gibt keine referenzielle Integrität zwischen den Referenzen in post.raw zu einem Upload und dem Upload-Objekt in der Datenbank. Es sucht nach Beiträgen mit Verweisen auf reine URLs oder upload://-Pseudoprotokoll-URLs, die entfernte Inhalte darstellen. Dabei muss der Beitrag nach der Migration zumindest neu aufbereitet werden, wenn nicht sogar eine Änderung gespeichert wird, da Basis-URLs direkt auf S3 zeigen. Wenn kein Inhalt in einem Beitrag gefunden wird, der migriert werden muss, geht es zum nächsten Element über.
Die Pfadänderungen werden nicht direkt vom Migrations-Skript gesteuert; es handelt sich lediglich um Änderungen daran, wo Discourse die Dateien ablegt. Ein weiteres Verzeichnisniveau verbessert die Leistung, wenn viele Dateien vorhanden sind, und viele andere Systeme nutzen zwei und gelegentlich drei Verzeichnisebenen, um die Dateien zu verteilen.
Du könntest auf dasselbe Problem stoßen, das ich hatte: Beim Migrieren der anderen Uploads verlor Discourse die Spur der Profilbilder der Benutzer. Mir ist das erst aufgefallen, als es viel zu spät war, um aus einem Backup wiederherzustellen. Daher habe ich die betroffenen Benutzer kontaktiert, mich entschuldigt und sie gebeten, ihre Avatare zu korrigieren. Ich weiß immer noch nicht, was dort schiefgelaufen ist.
Ah ok, cool. Ich sehe das in der Ausgabeliste:
Alle Post-Uploads migriert. Migration von Profil-Uploads...
Alle Profil-Uploads migriert. Migration von anderen Nicht-Post-Uploads...
Was sind „Nicht-Post-Uploads"? Hier scheint die meiste Arbeit noch zu liegen – die Migration von Posts und Profil-Uploads bewirkt nichts.
Vielen Dank für die Bestätigung bezüglich der Pfade für die Roh-Uploads!
Ich bin mir nicht sicher, ob das passiert, aber das ist in Ordnung – meine Seite nutzt SSO, sodass ich bei jeder Anmeldung des Benutzers (oder bei Änderungen des Bildes auf der Hauptseite) die Avatar-URL übergebe.
Ehrlich gesagt, weiß ich nicht, was die anderen waren. Ich habe eher gehofft, dass, falls referenzielle Integrität ein Thema wäre, eine Fremdschlüssel-Constraint existieren würde, und dass andernfalls einfach der Upload nachgeschlagen und verwendet würde, wo immer er sich befindet. Mir sind definitiv Fremdschlüssel-Constraints als Hinweis darauf begegnet, dass für zwei an Benutzerprofile angehängte Uploads etwas Besonderes zu tun ist.
Hmmm, es scheint tatsächlich zu funktionieren… obwohl ich heute Morgen auf ein ernstes Problem gestoßen bin… plötzlich ist meine Festplattennutzung um 25 % gestiegen und hat das Laufwerk vollgelaufen, wodurch das Forum komplett abgestürzt ist.
Im Moment, wenn ich den Rake-Befehl ausführe, scheint es, als würden die Bilder genau während des Batch-Laufs heruntergeladen/hochgeladen. Ich gebe den rake-Befehl ein, es werden genau 300 Bilder verarbeitet (ich führe sie in Batches von 300 aus), und dann endet der Vorgang.
Die wichtige Frage ist also: Könnte man diese Downloads von S3 auf die lokale Festplatte einfach in eine Warteschlange stellen? Könnte sich dadurch ein Batch angesammelt haben, der dann um 5 Uhr morgens ausgeführt wurde und mein Forum zum Absturz gebracht hat? 
Ich habe dafür gesorgt, dass bei der Migration von Beiträgen, beim Hochladen jeder neuen Profilgruppe und beim Hochladen aller anderen Dateien jeweils gewartet wurde, bis die Warteschlange leer war. Die Bilder sollten nun direkt nach dem Verschieben verarbeitet werden. (Die Standardversion stapelt alles einfach und blockiert die Warteschlange, bis sie fertig ist; bei mir hätte das bedeutet, dass 10–12 Tage lang keine Forenbenachrichtigungen gesendet wurden, während die Bilder neu verarbeitet wurden.)
Mir fällt nichts ein, was einen solchen Anstieg verursacht haben könnte, es sei denn, es wurden eine Reihe riesiger Uploads verarbeitet?
Ja, das ist für mich ein Rätsel. Ich meine, ich führe die Batches gar nicht so oft aus – ich gebe den Befehl jedes Mal manuell ein und beobachte die Ausführung. Ich habe keine weiteren Beiträge oder Profile mehr zu migrieren; alles, was noch übrig ist, sind „andere Uploads“. Wenn ich den Batch ausführe, scheint es, als würde es live von S3 heruntergeladen und direkt auf Digital Ocean hochgeladen. (Und ich sehe in Sidekiq nichts, was darauf hindeutet, dass etwas in die Warteschlange gestellt wird.)
Ich versuche, weitere Logs zu finden, die Aufschluss darüber geben könnten, was um 5:35 Uhr passiert ist.
Lies das gesamte Thema durch.
Aber der Großteil davon wirkte für mich verwirrend. Obwohl ich mit Docker-/Container-Befehlen und grundlegenden Rails-Befehlen vollständig vertraut bin.
Ich habe ähnliche Probleme (viele meiner Beiträge haben fehlende Bilder, oder einige zeigen keine Bilder, bis man auf sie klickt).
Ich habe zu verschiedenen Zeiten im Jahr zwei verschiedene S3-Buckets verwendet. Ich habe etwa 1000 Beiträge und ungefähr ebenso viele Bilder.
Jetzt habe ich alle Bilder von den S3-Buckets auf meinen lokalen Server kopiert. Kann mir jemand sagen, wie ich die Discourse-URLs so ummappen kann, dass diese Bilder nun korrekt mit den Beiträgen verknüpft sind?