Das ist sozusagen der Sinn des obigen Setups; es ist äußerst nützlich, wenn der Staging-Server auf denselben Bucket zeigt, da dies die Synchronisation erheblich erleichtert.
Sie möchten jedoch nicht, dass er automatisch Backups erstellt (oder löscht) – daher sind diese durch diese Einstellungen deaktiviert:
Ich stimme zu, dass das CDN für Ihre Staging-Site deaktiviert werden muss. Ich habe mich damit selbst noch nicht beschäftigt, aber sobald Sie herausgefunden haben, wie das geht, aktualisieren Sie bitte das Wiki im OP oder fügen Sie es hinzu.
Danke, Nathan. Ich habe gelesen, dass S3-Backups die Dinge einfacher machen, aber ein Backup ist etwas anderes als die Website-Assets, daher war ich mir nicht sicher.
Ich habe die Backups und E-Mails bereits deaktiviert, also ist alles in Ordnung. Ich werde damit beginnen, den Staging-Server auf den vorhandenen Bucket zu verweisen und sicherzustellen, dass er nicht das CDN verwendet.
Ich plane, einen Spiegel meiner Produktions-Discourse mit der rsync-Methode zu erstellen.
Ich habe ein paar andere Websites, die sich in Discourse integrieren. Daher wäre es ideal, wenn die Entwicklungs-/Testversionen dieser Websites eine Entwicklungs-/Test-/Staging-Version von Discourse aufrufen und mit ihr interagieren könnten.
Daher würde ich sie nur bei Bedarf einschalten und eine Datenbank-Sicherung meiner PROD-Umgebung auf meine STAGING-Umgebung wiederherstellen – nicht täglich, sondern vielleicht nur einmal im Monat.
Wenn ich das tue, wie kann ich verhindern, dass einige Einstellungen bei der Datenbankwiederherstellung zurückgesetzt werden?
Diese zum Beispiel wären von unschätzbarem Wert:
Gibt es eine Möglichkeit, eine Datenbank-Sicherung wiederherzustellen und dann vielleicht einige Einstellungen manuell anzuwenden, bevor Discourse gestartet wird? Andere Ideen, Vorschläge, Fallstricke?
Wenn Sie Backups auf S3 aufbewahren und diese über Umgebungsvariablen konfigurieren, können Sie ganz einfach eine neue Website starten, die dieses Backup wiederherstellen kann. Starten Sie einfach eine neue VM, klonen Sie Discourse, kopieren Sie die YML, bauen Sie neu und stellen Sie wieder her. Sie können Einstellungen in der Datenbank mit Umgebungsvariablen überschreiben, wie im Zitat in Ihrem Beitrag.
Fehlt mir ein Schritt? Ich bin ziemlich sicher, dass das vor etwa einem Jahr funktioniert hat. Aber jetzt, obwohl es sich füllt, werden keine Themen oder Beiträge über Über die Kategorie hinaus hinzugefügt… hat sich etwas geändert?
Danke Jay! Hier ist ein Bildschirm, der zeigt, was ich versucht habe… Es sieht so aus, als müsste ich mich in der „Entwicklungsumgebung“ befinden. Wie kann ich diese aufrufen?
Ich habe schließlich ein altes Backup von einer meiner Discourse-Instanzen wiederhergestellt, auf der ich diese Methode zuvor verwendet hatte, um sie zu befüllen. Ich musste dies tun, aber es hat funktioniert.
Um die Datenbank löschen zu können, müssen Sie etwas Bestimmtes tun. Wenn Sie die db:drop Rake-Aufgabe ausführen, wird Ihnen mitgeteilt, was das ist. Sie müssten also sv stop unicorn ausführen und dann die Datenbank löschen, erstellen und migrieren, bevor Sie die Aufgabe ausführen. Oder das ist das Nächste, was ich versuchen würde, aber Sie haben eine andere Lösung…
Ich versuche, Testdaten auf meinem Staging-Server zu hinterlegen, erhalte aber eine Fehlermeldung:
rake aborted!
Datenbankbefehle werden nur in der Entwicklungsumgebung unterstützt
Dies geschieht in einer Multisite-Einrichtung, daher lauten die Befehle, die ich ausführe:
./launcher enter web_only
ALLOW_DEV_POPULATE=1 bundle install
RAILS_DB=instance-x ALLOW_DEV_POPULATE=1 rake dev:populate
Die ich bisher ohne Probleme verwendet habe, aber jetzt erhalte ich diese Fehlermeldung. Kann ich eine Umgebungsvariable setzen, um Datenbankbefehle in der Produktion zuzulassen?
