# Migration zu einer selbst gehosteten Lösung von Kubernetes
**URL:** https://meta.discourse.org/t/migration-to-a-self-hosted-solution-from-kubernetes/377198
**Category:** Self-hosting
**Tags:** install, migrations-tooling
**Created:** [4. August 2025 um 12:40 UTC](https://meta.discourse.org/t/migration-to-a-self-hosted-solution-from-kubernetes/377198 "2025-08-04T12:40:20Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@stevejr](https://meta.discourse.org/u/stevejr)
#### Post date: [4. August 2025 um 12:40 UTC](https://meta.discourse.org/t/migration-to-a-self-hosted-solution-from-kubernetes/377198/1 "2025-08-04T12:40:20Z")
Hallo zusammen,
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.
Danke.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [7. August 2025 um 18:32 UTC](https://meta.discourse.org/t/migration-to-a-self-hosted-solution-from-kubernetes/377198/2 "2025-08-07T18:32:12Z")
> [@stevejr](#):
>
> Wir verwenden bereits eine externe Postgres-DB für die Installation, und diese wird beibehalten.
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.
> [@stevejr](#):
>
> Wir haben jedoch einige Einstellungen über die Benutzeroberfläche und auch über Umgebungsvariablen aktualisiert, die die Bitnami-Installationsskripte für Discourse zuordnen, z. B. `DISCOURSE_S3_BACKUP_BUCKET` wird `S3_BACKUP_BUCKET` zugeordnet.
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](https://meta.discourse.org/t/configure-an-s3-compatible-object-storage-provider-for-uploads/148916).
> [@stevejr](#):
>
> Ist es besser, eine brandneue Datenbank mit einer frischen Installation zu erstellen und dann ein Backup/Restore durchzuführen?
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. 😉
> [@stevejr](#):
>
> Reicht es aus, die Discourse-Einstellungen in den erforderlichen YAML-Dateien festzulegen, oder sollten wir immer noch Umgebungsvariablen verwenden?
Legen Sie sie in der YML fest.
> [@stevejr](#):
>
> Wenn wir ein Backup über die Benutzeroberfläche durchführen, was wird dann tatsächlich wiederhergestellt - wird die Datenbank aktualisiert?
Ja, die Datenbank wird aktualisiert. Ich empfehle Ihnen, [ein Backup über die Befehlszeile wiederherzustellen](https://meta.discourse.org/t/restore-a-backup-from-the-command-line/108034).
> [@stevejr](#):
>
> Wenn die neue Installation eine spätere Version von Discourse ist, wird dies ein Problem verursachen, wenn ein Restore versucht wird?
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.
---
### Author:  [@manning-ncsa](https://meta.discourse.org/u/manning-ncsa)
#### Post date: [16. Oktober 2025 um 14:45 UTC](https://meta.discourse.org/t/migration-to-a-self-hosted-solution-from-kubernetes/377198/3 "2025-10-16T14:45:10Z")
> [@pfaffman](#):
>
> > [@stevejr](#):
> >
> > Ist es besser, eine brandneue Datenbank mit einer frischen Installation zu erstellen und dann ein Backup/Restore durchzuführen?
>
> Wenn mit “besser” gemeint ist “werde ich dadurch unsere bestehende Website nicht kaputt machen und sie in einem Zustand hinterlassen, in dem sie nie wieder funktionieren wird?”, dann lautet die Antwort ja. 😉
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.
> [@stevejr](#):
>
> - Die Standardinstallationsanleitung verwendet Docker – wie überwachen Sie die Container in einer Produktionsumgebung, da die [Standardinstallation](https://meta.discourse.org/t/142537?silent=true) eine einzelne VM mit Docker zu sein scheint.
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](https://git.ncsa.illinois.edu/nsf-muses/muses-terraform/-/tree/695dba4ba1077e55ab6539fd27d495261cded024/charts/discourse), 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](https://git.ncsa.illinois.edu/nsf-muses/muses-terraform/-/blob/695dba4ba1077e55ab6539fd27d495261cded024/charts/discourse/files/run.sh) 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](https://www.communiteq.com/discoursehosting/pricing/) oder [Discourse.org](https://discourse.org/pricing) zu migrieren.