Hallo, ich habe gerade eine neue Discourse-Installation eingerichtet – vielen Dank für die großartige Arbeit, die es so einfach gemacht hat!
Idealerweise möchte ich meinen Discourse-Server wegwerfbar machen, sodass ich z. B. keine Daten verliere, wenn jemand ihn versehentlich in der EC2-Konsole löscht.
Die integrierte Backup-/Restore-Funktionalität ist großartig und ich habe damit bereits einige Testläufe durchgeführt. Ich speichere app.yml, Uploads und Backups in S3.
Der nächste Schritt wäre, die Datenbank zu Amazon RDS zu verschieben, wofür es hier hier eine großartige Anleitung gibt.
Meine Frage ist: Wenn ich das tue, sollte ich theoretisch sicher sein, die Instanz zu beenden und dann auf einem neuen Server einfach Discourse zu klonen, meine app.yml zu holen und ./launcher rebuild app auszuführen? ODER gibt es andere Zustände außer PostgreSQL/Uploads/app.yml? Vielleicht in Redis?
Ich denke, das stimmt größtenteils. Sie müssen sicherstellen, dass Sie nicht zwei gleichzeitig laufen lassen. Wenn Sie den neuen Container erstellen, migrieren Sie die Datenbank, was sie potenziell für den anderen Container unbrauchbar macht (Sie können dies mit skip_post_deployment_migrations vermeiden). Die Dinge in Redis gelten als ätherisch und werden nicht gesichert. Ich bin mir nicht ganz sicher, wie oder ob einige der Dinge dort wiederhergestellt werden, aber das ist Ihnen wahrscheinlich egal.
@phil22 - Ich habe an einer ähnlichen Einrichtung gearbeitet, wie Sie sie vorschlagen, und sie ist subtiler, als Sie denken:
Das Discourse-Team veröffentlicht mehrere Versionen pro Monat, daher müssen Sie bei Ihrer ursprünglichen Version bleiben, wenn Sie zu Ihrer neuen EC2 klonen. Normalerweise ist es in Ordnung, die Anwendung blind zu aktualisieren, aber einige Versionen enthalten wichtige Datenbank-Upgrades (PG 12 → PG 13), und wenn Sie dies nicht verfolgen und Ihr externes RDS nicht aktualisieren, könnten Sie stecken bleiben.
Wir hatten Erfolg damit, dass die EC2 ein EBS-Volume verwendet, das auch so konfiguriert ist, dass es in Ihren App-Container eingehängt wird. Damit speichern wir alle Inhalte des /shared-Ordners. Auf diese Weise haben Sie alle Inhalte des /shared-Ordners auf EBS gespeichert, wenn Ihre EC2-Instanzen kommen und gehen. Außerdem ändern Sie manchmal Ihre Meinung über die Speicherung von Dateien in S3. Wenn Sie einen alternativen Speicherort für hochgeladene Dateien haben (wie den /shared-Ordner), ist das in diesem Fall gut.
Nach Ihrem Rat werde ich mich für RDS entscheiden, aber auf einen bestimmten Commit des discourse_docker-Repos festlegen. Obwohl dies Upgrades komplexer machen wird, hoffe ich, dass es bedeutet, dass wir, wenn wir ein Problem mit dem Server haben, alles sicher auf RDS haben und ziemlich schnell denselben funktionierenden Zustand ohne manuelle Wiederherstellung erreichen können.
(Ich denke, wir könnten dasselbe mit EBS erreichen, aber mit Volumenverschlüsselung und Unix-Magie zum Mounten/Dismounten des Volumens zwischen Instanzen bin ich ein wenig verängstigt vor dem Prozess der Automatisierung dessen)