Eine gemeinnützige Organisation, mit der ich zusammenarbeite, hat eine Discourse-Installation 2.9.0.beta1, deren Wartung mir zufiel, als der ursprüngliche Administrator ging. Als ich versuchte, die SMTP-Zugangsdaten zu aktualisieren, erfuhr ich, dass die Installation weder sich selbst neu erstellen noch sicher über das Web oder die Befehlszeile aktualisieren kann. (Wenn ich nicht ein Hot-Backup der Instanz hätte, das vor Beginn der Arbeit erstellt wurde, wäre dies eine schlechte Zeit gewesen.) Das Problem scheint ziemlich tief in Ruby aufzutreten, und ich kann Protokolle erfassen, wenn sie hilfreich erscheinen.
Ich dachte, es sei vielleicht einfach zu alt, um es ordnungsgemäß zu aktualisieren, also versuchte ich stattdessen einen Wiederherstellungsprozess, indem ich eine neue, frische Discourse-Instanz erstellte und dann das aktuellste Backup des Forums darauf lud. Aber auch dieser Prozess schlug unentschieden fehl, mit dem, was ich für Datenbankspaltenfehler hielt, bevor der Upgrade-Prozess nicht mehr reagierte.
Was wäre der beste Weg, um von unserem jetzigen Standpunkt aus weiterzumachen? Das Forum ist derzeit funktionsfähig, ich kann es nur weder aktualisieren noch anscheinend ein Backup verwenden. Sollte ich weiterhin versuchen, eine Wiederherstellung durchzuführen, sollte ich meine Bemühungen zur Aktualisierung verdoppeln und Protokolle erfassen, um loszulegen, oder gibt es eine dritte Option, die ich nicht sehe?
Sie müssen zu einer neuen virtuellen Maschine wechseln. Es ist wahrscheinlich, dass Ihr Betriebssystem zu alt ist, um Docker auf eine unterstützte Version zu aktualisieren.
Es ist besser, zu einer neuen VM zu wechseln, die auf neuerer Hardware läuft, die schneller und günstiger ist.
Die Docker-Versionierung schien keine Rolle dabei zu spielen, warum Ruby-Builds zusammenbrachen, aber ich nehme an, es ist möglich. Die Docker-Pulls, die Teil des Wiederaufbaus waren, schienen keine außergewöhnlichen Fehlerzustände aufzuweisen. Das sieht zwar so aus, als könnte ich es versuchen. Danke für die Antwort!
Ihr Umzug wurde durch Ihre Backups auf S3, die in der Datenbank und nicht in Umgebungsvariablen konfiguriert sind, wie in Konfigurieren eines S3-kompatiblen Objektspeichers für Uploads beschrieben, etwas komplizierter (obwohl dies für Uploads gilt, sodass Sie die Einstellung use_s3 nicht verwenden müssten, nur den Backup-Bucket und den Speicherort. EDIT: Und dann schlug die Wiederherstellung fehl, weil Ihre EC2 keine Schreibberechtigung für den Bucket hat.
Ein Load Balancer vor Ihrer Site ändert die Dinge ebenfalls im Vergleich zu den meisten Benutzern.
Und da Ihre Anmeldeinformationen für die EC2 sind und nicht in der Datenbank oder der YML-Datei gespeichert sind, kann die Wiederherstellung nicht abgeschlossen werden.