ich betreibe Discourse seit einiger Zeit in einem Kubernetes-Cluster mit dem nicht unterstützten Bitnami-Image. Da Bitnami das Image nun ausmustert und kostenpflichtig macht, möchte ich unseren Server auf eine selbst gehostete Lösung auf AWS migrieren.
Ich habe ein paar Fragen, bei denen mir die Community hoffentlich helfen kann:
Wir verwenden bereits eine externe Postgres-Datenbank für die Installation, und diese wird auch weiterhin bestehen bleiben. Wir haben jedoch einige Einstellungen über die Benutzeroberfläche und auch über Umgebungsvariablen aktualisiert, die die Bitnami-Installationsskripte auf Discourse abbilden, z. B. wird DISCOURSE_S3_BACKUP_BUCKET zu S3_BACKUP_BUCKET.
Reicht es aus, die Discourse-Einstellungen in den erforderlichen YAML-Dateien festzulegen, oder sollten wir weiterhin Umgebungsvariablen verwenden?
Wenn wir ein Backup über die Benutzeroberfläche durchführen, was wird dann tatsächlich wiederhergestellt – werden die Daten in der Datenbank aktualisiert?
Ist es besser, eine brandneue Datenbank mit einer frischen Installation zu erstellen und dann ein Backup/Restore durchzuführen?
Wenn die neue Installation eine spätere Version von Discourse ist, wird dies ein Problem darstellen, wenn ein Restore versucht wird?
Die Standardinstallationsanleitung verwendet Docker – wie überwacht man die Container in einer Produktionsumgebung, da die Standardinstallation eine einzelne VM mit Docker zu sein scheint?
Gibt es Dokumente, die eine Migration und mögliche Fallstricke detailliert beschreiben?
Ich bin sicher, dass ich während der Migration weitere Fragen haben werde, aber jeder Rat/jede Hilfe wäre wirklich willkommen.
Wenn es nicht bereits Ihr Plan war, würde ich für die Migration zu einer neuen Datenbank (auf demselben Server) wechseln, damit Sie Ihre bestehende Website nicht beschädigen.
Ich kann nicht genau sagen, was Bitnami Ihrer Meinung nach tut, aber die Variable, die Sie in Ihrer ENV benötigen, ist DISCOURSE_S3_BACKUP_BUCKET. Weitere Informationen zum richtigen Festlegen dieser S3-Variablen in Ihrer app.yml finden Sie unter Konfigurieren eines S3-kompatiblen Objektspeichers für Uploads.
Wenn mit “besser” gemeint ist “werde ich dadurch unsere bestehende Website nicht beschädigen und sie in einem Zustand hinterlassen, in dem sie nie wieder funktionieren wird?”, dann lautet die Antwort ja.
Das ist es, was Sie wollen. Der Ort, von dem Sie wiederherstellen, muss dieselbe oder eine neuere Version als die Backup-Version sein. Die Datenbank wird nach der Wiederherstellung migriert.
Dies ist möglicherweise alles, was Sie wissen müssen, und wir helfen Ihnen hier gerne kostenlos weiter. Wenn Sie persönliche, auf Ihre Einrichtung zugeschnittene Unterstützung wünschen, können Sie mich kontaktieren oder im Kanal Marketplace um Hilfe bitten.
Eine weitere Option wäre, Images zu erstellen und diese in k8s zu starten. Das habe ich schon ein paar Mal gemacht und GitHub zum Erstellen der Images verwendet.
Meine Erfahrung bestätigt dies. Ich habe im Laufe der Jahre so viele seltsame kleine Fehler gesehen, dass ich immer vollständige Backups pflege, damit ich von vorne anfangen und die Website wiederherstellen kann. Sich auf die Behebung von Problemen vor Ort zu verlassen, wird Sie irgendwann im Stich lassen.
Wie Sie, wurde ich im Stich gelassen, als Bitnami aufhörte, kostenlose Images und Charts anzubieten. Ich musste so viele Deployments anpassen und migrieren. Eines davon war mein Discourse-Deployment. Wenn es für Sie nützlich ist, hier ist ein Link zu dem Ersatz-Helm-Chart, das ich in sehr kurzer Zeit erstellt habe (was bedeutet, dass es funktioniert, aber weit von einem idealen Design entfernt ist). Es ist ein Versuch, die “offizielle Installationsmethode” zu verwenden, da ich nach all den Jahren kein “Community-Standard”-Helm-Chart gesehen habe. (Ich nehme an, Bitnamis Chart war effektiv dieser Standard, da nur wenige von uns diese abrupte Änderung vorhergesehen haben.) In jedem Fall ist dieses neue Chart, das ich für eine meiner Forschungsgemeinschaften betreibe, im Grunde nur ein Pod mit zwei Containern: dem offiziellen Docker-in-Docker-Container und einem benutzerdefinierten Container, der auf python:3 basiert, Docker installiert und dann die offizielle Discourse-Installation verwendet. Da alle Komponenten (Discourse-Server, Redis, PostgreSQL) in der Blackbox des lokal von Skript erstellten Images laufen, gibt es keine Skalierbarkeit oder Unterstützung für Hochverfügbarkeit. Ich konnte die Ausfallzeit durch das erneute Starten des Pods auf einem anderen Knoten (z. B. beim Entleeren eines Knotens für OS-Updates oder bei einem Knotencrash) reduzieren, indem ich docker save verwendete, um das erstellte Image im persistenten Volume zu speichern und es dann zu laden, wenn local_discourse/app:latest nicht gefunden wird.
Aber um Ihre Frage zu beantworten: Ich weiß nicht, wie ich in diesem neuen Deployment etwas überwachen soll. Ich betreibe es “in Produktion”, aber meine Community ist klein genug und die Nutzung moderat genug, dass es keine große Sache ist, wenn das Forum eine Weile offline ist. Selbst dann bin ich sehr nah daran, das Self-Hosting aufzugeben und zu einem Dienst wie Communiteq oder Discourse.org zu migrieren.
