Warnung: Wenn Sie nicht mit der Arbeit als Linux-Systemadministrator vertraut sind und keine Erfahrung mit Docker-Containern haben, wird der Wechsel zu einer Multi-Container-Bereitstellung Schwierigkeiten verursachen. Sowohl das Personal als auch freiwillige Helfer werden Sie dann angemessen auffordern, zu einer eigenständigen Single-Container-Bereitstellung zurückzukehren, die vollständig vom
launcher-Skript verwaltet wird.Wenn Sie zu einer Multi-Container-Bereitstellung wechseln und Ihr System dadurch beschädigt wird, haben Sie wahrscheinlich die „Freude“, beide defekten Teile behalten zu müssen. Wenn Sie die folgenden Anweisungen lesen und sich alles wie Magie anfühlt, anstatt zu klären, wie die Dinge tatsächlich in den Containern funktionieren, dann rennen Sie, gehen Sie nicht, zu Ihrer nächsten Standard-eigenständigen Bereitstellung. Das wird Ihnen einen Gefallen tun.
Die empfohlene Methode zum Migrieren von einer Single-Container-Bereitstellung zu einer Multi-Container-Bereitstellung besteht im Wesentlichen aus:
- Einem Backup Ihres Discourse
- Das Wegwerfen des Ganzen
- Einem Neustart von Grund auf mit einer Multi-Container-Bereitstellung
- Der Wiederherstellung Ihres Backups
Wenn Sie wie ich eine große Seite haben, die Stunden zum Wiederherstellen braucht, fragen Sie sich vielleicht, ob es einen schnelleren Weg gibt. Kein Wunder mehr! Ich habe von einer eigenständigen Bereitstellung zu einer Drei-Container-Bereitstellung (Web, Daten und Redis) migriert, in weniger Zeit, als es normalerweise für ./launcher rebuild app bei dieser Seite dauert. (12 Minuten Gesamtausfallzeit, während das Rebuilden der App manchmal mehr als 30 Minuten gedauert hat.) Basierend auf meiner Erfahrung würde ich Redis in Zukunft mit Postgres in einem einzigen data-Container behalten.
Wenn Sie dies tun, tragen Sie die Verantwortung zu wissen, wann Sie Ihre anderen Container (Daten und, wenn Sie so dumm sind wie ich und Redis auslagern, auch Redis) neu aufbauen müssen. Sie erhalten keine kostenlosen Upgrades mehr für alles mit ./launcher rebuild app — wenn Sie nicht die Ressourcen haben, diesen Prozess zu verwalten, nutzen Sie eine eigenständige Bereitstellung oder kaufen Sie gehostetes Discourse.
Test
Verwenden Sie diesen Prozess nicht zum Migrieren zu mehreren Containern, es sei denn, Sie verstehen nach dem Lesen auch, wie Sie schnell von mehreren Containern zu einem einzelnen Container migrieren würden. Wenn Ihnen das nach dem Lesen nicht offensichtlich ist, dann ist dieser Beitrag ausreichend fortgeschrittene Technologie (das heißt, von Magie nicht zu unterscheiden), und es ist möglich, dass Sie auch nicht erkennen, wenn dieser Prozess auf halbem Weg abbricht. Sie könnten also mit einem defekten Discourse enden, das Sie erst viel später bemerken. Wenn das passiert, dürfen Sie beide defekten Teile behalten. Was kaputt geht, gehört Ihnen, wie man so sagt!
Backup
Sichern Sie zuerst, und aktivieren Sie zuerst Miniaturansicht-Backups, damit Sie diese bei der Wiederherstellung nicht alle neu erstellen müssen. Wenn Sie hier einen Fehler machen, geraten Sie leicht in eine Situation, in der der einfachste, sicherste und schnellste Weg zur Wiederherstellung darin besteht, zur normalen Methode zurückzukehren. Seien Sie bereit, zur empfohlenen Methode zurückzufallen, falls etwas schiefgeht.
Laden Sie Ihr Backup herunter. Die folgenden Befehle beinhalten das Verschieben von Dateien im Discourse-Datenverzeichnis. Wenn Sie einen Fehler machen, haben Sie vielleicht Ihr Backup gelöscht. Laden Sie es also herunter. Und falls Ihr Backup keine Uploads enthält, sichern Sie diese ebenfalls. Sie befinden sich ebenfalls dort, wo Sie Dateien verschieben werden.
Im Ernst: Sichern Sie.
Als ich das tat, machte ich zuerst ein Backup, dann ein Remote-System-Backup, bevor ich weitermachte.
Neue Multi-Container-Konfiguration einrichten
Sie benötigen mindestens containers/web_only.yml und containers/data.yml und, wenn Sie Redis ebenfalls auslagern wollen, auch containers/redis.yml. Beginnen Sie damit, samples/data.yml (und optional samples/redis.yml) in das containers/-Verzeichnis zu kopieren.
Wenn Sie Redis separat bereitstellen, entfernen Sie die Redis-Vorlage von oben aus der Datei containers/data.yml. (Tun Sie dies jedoch nicht ohne guten Grund; es ist nur zusätzliche Arbeit.)
Sie haben zwei Möglichkeiten, web_only.yml zu erstellen:
- Kopieren Sie
samples/web_only.ymlnachcontainers/; vergleichen Sie dann beide mitcontainers/app.ymlund bewahren Sie dabei jede Postgres-Konfiguration inparams:in Ihrer neuencontainers/data.ymlauf.
- Kopieren Sie alle
params:für Postgres auscontainers/app.ymlincontainers/data.yml. - Erstellen Sie ein eindeutiges Passwort, um
SOME_SECRETzu ersetzen.
- Alternativ kopieren Sie
containers/app.ymlnachcontainers/web_only.ymlund vergleichen es mitsamples/web_only.yml.
- Entfernen Sie alle Verweise auf die Postgres- und Redis-Vorlagen.
- Entfernen Sie den gesamten
params:-Abschnitt, der nur Postgres-Einstellungen enthielt. - Fügen Sie einen
links:-Abschnitt hinzu, wortwörtlich aussamples/web_only.ymloder modifiziert (siehe unten), wenn Sie Redis in einem separaten Container bereitstellen. - Fügen Sie einen Datenbankabschnitt aus
samples/web_only.ymlhinzu und erstellen Sie ein eindeutiges Passwort, umSOME_SECRETzu ersetzen. - Ändern Sie die Volume-Definitionen von
standalonezuweb_only.
Hier ist der links:-Abschnitt, den Sie verwenden sollten, wenn Sie Redis in einen eigenen Container auslagern, anstatt den vernünftigen Standard zu verwenden, es mit Postgres im Datencontainer zu bündeln:
# Verwenden Sie den 'links'-Schlüssel, um Container zu verknüpfen, also den Docker --link-Flag.
links:
- link:
name: data
alias: data
- link:
name: redis
alias: redis
Der redis-Link wird nicht benötigt, wenn Sie die Redis- und Postgres-Container als einen einzigen Datencontainer kombinieren; dies zeigt nur, was Sie tun würden.
Hier ist eine Kopie der aktuellen Postgres-Einstellungen in env in samples/data.yml, in denen Sie SOME_SECRET ändern müssen:
## TODO: Konfigurieren Sie die Verbindung zu den Datenbanken
DISCOURSE_DB_SOCKET: ''
#DISCOURSE_DB_USERNAME: discourse
DISCOURSE_DB_PASSWORD: SOME_SECRET
DISCOURSE_DB_HOST: data
## Wenn Sie einen einzelnen Daten+Redis-Container verwenden, wird dies „data" sein
DISCOURSE_REDIS_HOST: redis
Beachten Sie, dass Sie für eine normale Bereitstellung (nicht Multisite) keine anderen Zeilen ändern müssen. DISCOURSE_DB_SOCKET ist für einen Unix-Domain-Socket für Postgres, es ist keine Portnummer.
Hier ist ein Beispiel für die Änderung der Volume-Definition am Ende von web_only.yml, die Sie verwenden müssen, wenn Sie es aus app.yml statt aus samples/web_only.yml kopieren:
@@ -75,10 +80,10 @@
## Der Docker-Container ist zustandslos; alle Daten werden in /shared gespeichert
volumes:
- volume:
- host: /var/discourse/shared/standalone
+ host: /var/discourse/shared/web_only
guest: /shared
- volume:
- host: /var/discourse/shared/standalone/log/var-log
+ host: /var/discourse/shared/web_only/log/var-log
guest: /var/log
Setzen Sie nun dasselbe geheime Passwort, das Sie in containers/web_only.yml verwendet haben, in containers/data.yml anstelle von SOME_SECRET.
Jetzt sind Sie bereit für die Migration.
Jetzt ist der Zeitpunkt, an dem Sie Ihr finales Backup erstellen und herunterladen, bevor Sie die schnelle Migration versuchen. Denken Sie daran: Wenn hier etwas schiefgeht, gehen Sie sofort zur empfohlenen Methode über. Ich kann es nicht oft genug betonen.
Separate Daten (Postgres) und Redis-Container:
cd /var/discourse
./launcher stop app
cd shared
mkdir data
mkdir redis
mv standalone/postgres_* data/
mv standalone/redis_data/ redis/
mv standalone web_only
mkdir -p data/log/var-log
mkdir -p redis/log/var-log
cd ..
./launcher destroy app
./launcher bootstrap data
./launcher bootstrap redis
./launcher start redis
./launcher start data
./launcher bootstrap web_only
./launcher start web_only
Kombinierter Postgres+Redis-Datencontainer:
cd /var/discourse
./launcher stop app
cd shared
mkdir data
mv standalone/postgres_* data/
mv standalone/redis_data/ data/
mv standalone web_only
mkdir -p data/log/var-log
cd ..
./launcher destroy app
./launcher bootstrap data
./launcher start data
./launcher bootstrap web_only
./launcher start web_only
Beachten Sie auch, dass, wenn Sie previously ein externes Nginx eingerichtet haben, Sie den proxy_pass-Pfad ändern müssen, um dem neuen web_only-Socket-Standort zu entsprechen; sagen wir von http://unix:/var/discourse/shared/standalone/nginx.http.sock: zu http://unix:/var/discourse/shared/web_only/nginx.http.sock:.
Für mich, auf einer 2-Kern-VM mit 4 GB RAM und einer Seite mit 600 MB Backups ohne Downloads, ergab dieser Prozess 12 Minuten Ausfallzeit. Ihre mileage may vary (Ihre Ergebnisse können variieren).
Beachten Sie, dass nichts davon bisher den Launcher aktualisiert. Sie sind möglicherweise nicht auf dem neuesten Stand. (Zum Beispiel habe ich dies nach dem PostgreSQL 12-Update durchgeführt, aber bevor ich es angewendet hatte. Dieser Prozess ließ mich mit PostgreSQL 10 zurück. Als Nächstes habe ich das Daten-App neu aufgebaut, was den Launcher aktualisierte und mich erfolgreich durch den PostgreSQL 12-Aktualisierungsprozess führte.)
Was bei zukünftigen Updates zu tun ist
Nach dieser Migration müssen Sie, wenn Sie Redis oder Daten aktualisieren müssen, zuerst die Web-App stoppen. Das würde ungefähr so aussehen:
./launcher stop web_only
./launcher rebuild data # und/oder redis
./launcher rebuild web_only
Beachten Sie, dass, wenn Sie den data- (oder postgres- oder redis-) Container neu aufbauen, Sie einen neuen Web-Container erstellen müssen, um ihn mit dem neuen Datencontainer zu verbinden. Sie können dies entweder durch ein Rebuilden von web_only tun oder, wenn Sie denken, dass Sie es nicht neu aufbauen müssen, ein ./launcher destroy web_only; ./launcher start web_only wird die Arbeit erledigen (und wenn Sie einen Fehler bezüglich „fehlender Datencontainer“ oder Ähnlichem erhalten, ist dies das, was Sie tun müssen).
Wenn jedoch weder Postgres noch Redis aktualisiert werden müssen, ist es viel schneller, diese Container nicht neu aufbauen zu müssen, und die meisten App-Rebuilds sind einfach ./launcher rebuild web_only.
Alternativ, für noch weniger Ausfallzeit (verschieden zwischen 15 Sekunden und 2 Minuten gemeldet):
./launcher bootstrap web_only
./launcher destroy web_only && ./launcher start web_only
Noch einmal: Durch den Wechsel zu einer Multi-Container-Bereitstellung ist es nun Ihre Aufgabe, den Überblick darüber zu behalten, wann dies angemessen ist. Sie erhalten Benachrichtigungen in der Admin-Konsole über Updates, aber diese gelten nur für den web_only-Container. Niemand wird Ihnen sagen, wann Sie Postgres oder Redis aktualisieren müssen. Wenn Sie dies tun, lesen Sie vor jedem Versionsupgrade die Ankündigungen-Kategorie und lesen Sie die Veröffentlichungsnotizen für jede neue Version, auf die Sie upgraden oder durch die Sie hindurchgehen. Das heißt, wenn Sie ein Versionsupdate überspringen, überspringen Sie nicht das Lesen der Veröffentlichungsnotizen für die Version, die Sie übersprungen haben. (Überlegen Sie sich, ein Watch auf Veröffentlichungsnotizen einzurichten oder Ihren Feed-Reader an https://meta.discourse.org/tag/release-notes.rss zu abonnieren, um auf dem Laufenden zu bleiben.)
Beachten Sie, dass das Neu aufbauen des web_only-Containers erfordert, dass die Datenbank läuft, sodass Sie die Dinge nicht beschleunigen können, indem Sie alle zwei oder drei Container parallel neu aufbauen. Wenn Sie sie jedes Mal alle neu aufbauen werden, bleiben Sie bei der Standard-empfohlenen eigenständigen Bereitstellung; sie wird schneller sein als das Jonglieren mehrerer Container.
Überprüfung des Backups
Wenn Sie Uploads separat von der Datenbank sichern, hoffe ich, dass Sie ein dateibasiertes Remote-Backup-Regime für Uploads haben, sodass diese bei einer Katastrophe gesichert und wiederhergestellt werden können.
Überprüfen Sie Ihre Remote-Backup-Implementierung, um sicherzustellen, dass sie Uploads in /var/discourse/shared/web_only statt in /var/discourse/shared/standalone sichert, damit Ihre Backups in Ihrer neuen Multi-Container-Implementierung aktuell bleiben.
Ich hatte den Unterschied zwischen RDS und meinem eigenen Datenbankserver nicht verstanden, bevor Sie es mir sagten 
