Ich habe festgestellt, dass die Aufgabe rake assets:precompile eine Datenbankverbindung erfordert: Das bedeutet, dass die Aufgabe nur zur „Laufzeit
Wir speichern die Themes in der Datenbank (sie werden in der Admin-Oberfläche bearbeitet), sodass sich das CSS in PostgreSQL befindet. Daher ist zur Build-Zeit eine Datenbankverbindung erforderlich, um diese vorzukompilieren.
Vielen Dank für die Information!
Wäre es denkbar, den Build der Lokalisierungen separat zu implementieren (also zur Build-Zeit auszuführen)?
Außerdem kann ich mir vorstellen, dass einige Umgebungen (bei mir zumindest) keine Änderungen an den Themes zulassen möchten: Wäre es in diesem Fall möglich, einen alternativen Speicherort für das CSS bereitzustellen?
Wir haben die Idee besprochen, einen Schalter einzuführen, der die gesamte Benutzeroberfläche für die Anpassung deaktiviert. Dadurch könnten die CSS-Dateien zur Build-Zeit kompiliert und während des Builds in den Objektspeicher hochgeladen werden (genau wie beim JS-Core bzw. den Plugins).
Dies ist jedoch ein sehr spezieller Anwendungsfall, der nur für unternehmensorientierte Bereitstellungen interessant wäre und für 99 % der Communities im Internet keinen Mehrwert bietet. Daher ist dies nicht in unserer Roadmap enthalten, und es wäre schwierig, Ressourcen für diese Aufgabe freizumachen, anstatt neue Funktionen zu entwickeln oder an der Performance zu arbeiten.
Könnten Sie uns mehr über Ihre Umgebung und Ihren Anwendungsfall mitteilen?
Gut zu wissen, dass die Idee bereits diskutiert wurde. Ich verstehe, dass der Aufwand für die Änderung wahrscheinlich zu groß ist, um gerechtfertigt zu sein.
In meinem Fall wird Discourse mit einer bestehenden Website verknüpft sein, sodass es ein festes, benutzerdefiniertes Theme geben wird, das mit dem der Website übereinstimmt: Es würde keinen Sinn ergeben, es dynamisch zu ändern.
Oh, ich meinte den Anwendungsfall, dass du dich zur „Build-Zeit
Oh, na ja, wenn ich das Image erstelle, arbeite ich auf meinem Entwicklungslaptop. Das Image wird dann in ein Repository gepusht, und das Endsystem (VPS bei DigitalOcean) zieht es von dort.
Die Datenbank befindet sich in einem Volume auf dem VPS, sodass sie nicht auf meinem Laptop aktualisiert werden kann: Das würde erfordern, dass ich Discourse stoppe, die Datenbank per rsync auf meinen Laptop übertrage, das Image erstelle und pushe und schließlich Discourse neu starte…
Sie betreiben also die Datenbank und die Anwendung in einem einzigen Droplet?
In diesem Fall führt die Einhaltung unseres offiziellen Installationsleitfadens, der ein Droplet mit Anwendung und Datenbank in einem einzigen Droplet ergibt, zu einer voll funktionsfähigen Website, die über die Weboberfläche und optional über die Befehlszeile mit einem vollständigen Image-Neubau aktualisiert werden kann.
Wenn du damit „direkt auf dem Host
[quote=“matpen, Beitrag: 10, Thema: 126779”]
Wenn du damit „direkt auf dem Host
Hehe, danke für die Idee, aber das wird schnell kompliziert. Außerdem löst es das Problem nicht, da wir immer noch Discourse anhalten und auf den Bootstrap-Prozess warten müssen, sonst könnten inkonsistente Daten entstehen.
Es sieht so aus, als müssten wir uns mit einer längeren Ausfallzeit (5–6 Minuten für Migration und Precompilation) beim Upgrade abfinden. Trotzdem würde ich mich freuen, wenn ihr ein Issue mit niedriger Priorität im Tracker anlegen könntet, vielleicht mit einem Link zu diesem Thema.
Vielen Dank und weiter so!
Nein, das ist nicht der Fall.
Es sollten nur „ein paar Sekunden
Gut zu wissen, danke. In diesem Fall werde ich die Container definitiv aufteilen, was ohnehin eine bessere Architektur ist.
Allerdings verstehe ich nicht, worin der Unterschied liegt? Wenn ich mich nicht irre, teilen sich alle Container alle Host-CPU-Kerne (sofern nicht anders konfiguriert), sodass Prozesse in beiden Fällen parallel ausgeführt werden sollten. Übersehe ich etwas?
Ihr alter Container läuft weiter, während der neue hochgefahren wird. Anschließend können Sie den alten schnell ausschalten und den neuen starten, sodass die Ausfallzeit kürzer ausfällt.