Können Snapshots bei der Aktualisierung des Host-Betriebssystems verwendet werden?

Entschuldigung, falls diese Frage bereits gestellt wurde. Ich habe mich umgesehen, aber kein genaues Szenario gefunden, das ich plane (oder ich habe es übersehen, aber ich möchte sichergehen, dass ich es richtig mache, da ich es noch nie zuvor getan habe).

Ich bin noch auf 18 (wo ich angefangen habe; ich habe noch nie ein Linux-Betriebssystem aktualisiert, nur die Sicherheitsupdates), also werde ich bald auf 22 umsteigen. Alles, was ich hier gelesen habe, deutet darauf hin, dass eine Migration zu einer Neuinstallation viel sinnvoller ist als ein Upgrade der bestehenden Installation, da es potenziell eine Vielzahl von zufälligen Problemen geben kann, die auftreten können oder auch nicht, aber es ist das Risiko nicht wert, denn wenn sie auftreten, ist es nur ein sinnloser Aufwand.

Ich habe diesen Leitfaden gelesen: Move your Discourse Instance to a Different Server, aber er bezieht sich auf die Verschiebung von einem Server zu DigitalOcean (oder umgekehrt), was den Snapshot unanwendbar macht, während ich plane, von einem bestehenden DigitalOcean Droplet zu einem neuen zu wechseln (was ich mehrfach als funktionierend und ideal für ein Upgrade erwähnt habe).

Meine Frage für eine DO>DO-Übertragung ist also, ob ich einfach mein Droplet herunterfahren, einen Snapshot erstellen, ein neues Droplet mit dem aktualisierten Ubuntu, das ich möchte, starten, den Snapshot laden und fertig bin (die DNS-Einträge für die Domain usw. anpassen)? Im Grunde umgehe ich die “vollständige Neuinstallation von Discourse”, die der Leitfaden beschreibt. Nach meinem Verständnis von Snapshots sind sie dazu gedacht, eine identische 1:1-Kopie der Installation auf dem Droplet zu sein, im Gegensatz zum Backup, das speziell für Ihre Discourse-Einrichtung gedacht ist und eine vollständige Installation erfordert, um es tatsächlich nutzen zu können. Verstehe ich das richtig? Gibt es Nachteile außer längeren Ausfallzeiten?

tl;dr: Kann ich einfach einen Snapshot machen, ein neues, aktualisiertes Droplet erstellen, den Snapshot laden und fertig sein?

Ein DO-Snapshot enthält die Betriebssystemversion. Das Wiederherstellen eines Snapshots würde das Betriebssystem zurücksetzen.

Ihre praktischen Optionen sind, ein Backup zu verschieben oder /var/discourse per rsync zu sichern und Docker manuell neu zu installieren.

2 „Gefällt mir“

Hoffentlich liege ich nicht völlig falsch, aber das Wiederherstellen eines Snapshots von 18 auf 22 setzt Sie auf 18 zurück, da ein Snapshot eine 1:1-Kopie des gesamten Droplets ist.

Für mich ist das Aufsetzen eines komplett neuen Droplets immer die letzte Option, da ich alles installieren muss, was Ubuntu (oder welches Betriebssystem auch immer) benötigt, einschließlich des Mail-Systems usw.

Ich bin mir absolut sicher, dass dies für diejenigen, die es können, nur eine weitere triviale Aufgabe ist, aber nach 10 Jahren habe ich nie gelernt, wie man ein neues funktionierendes Droplet einfach startet.

2 „Gefällt mir“

Die Installation von Discourse dauert ungefähr 30 Minuten, oder?

Machen Sie einfach ein Backup Ihrer Website und Ihrer app.yml, erstellen Sie ein neues Droplet mit der neuen Betriebssystemversion, weisen Sie dem neuen Droplet die IP-Adresse neu zu (damit die Domain auf den richtigen, neuen Ort zeigt), installieren Sie Discourse (Sie können den Assistenten beenden und app.yml aktualisieren, dann neu erstellen) und importieren Sie Ihr Backup.

Der gesamte Vorgang sollte weniger als eine Stunde dauern.

Dieser Vorgang berührt Ihr bestehendes Droplet nie. Wenn also alles fehlschlägt, ist es so einfach, zurückzurollen?

2 „Gefällt mir“

Wenn ich von einer LTS-Version des Betriebssystems zur nächsten Version wechsle, erwarte ich einen ziemlich reibungslosen Ablauf. Ich würde also ein Backup erstellen – natürlich – und es zur Sicherheit herunterladen – natürlich – und dann versuchen, das Betriebssystem zu aktualisieren. Wenn es nicht funktioniert, könnte ich dann ein frisches Betriebssystem ausprobieren.

Dabei würde ich jedoch mehr Ausfallzeiten des Forums in Kauf nehmen.

Ich bin etwas zurückhaltend, zu einer frischen Instanz zu migrieren, hauptsächlich weil ich die DNS-Einträge aktualisieren und auf die Weitergabe warten müsste. Obwohl ich sehe, dass der Beitrag über mir besagt, dass ich meine IP-Adresse mitnehmen könnte, was gut ist und diese Zurückhaltung beseitigt.

Tatsächlich ändere ich meine Antwort vollständig: Wenn ich meine IP-Adresse zu einer neuen Instanz mitnehmen kann, wäre das vorzuziehen. Möglicherweise erlauben nicht alle Anbieter dies. Möglicherweise würde man bei einigen Anbietern eine kostenlose IP-Adresse verlieren und für die IP-Adresse bezahlen, weil sie verschoben wurde, obwohl sie sich nicht geändert hat.

1 „Gefällt mir“

Eine super einfache Abhilfemaßnahme hierfür ist, einfach eine sehr niedrige TTL (Time To Live) festzulegen (oder die Nameserver auf einen umzustellen, der dies unterstützt). Auf diese Weise laufen die Einträge in kürzerer Zeit ab, als für den Wiederaufbau benötigt wird.

2 „Gefällt mir“

Sie können eine statische IP-Adresse verwenden (ich kann mich nicht erinnern, wie DigitalOcean sie jetzt nennt). Im Netzwerk können Sie eine neue IP-Adresse erhalten und diese dann dem alten Droplet zuordnen. Dann ändern Sie die DNS und lassen sie weitergeben. Wenn Sie bereit sind, zum neuen Server zu wechseln, wechseln Sie einfach die IP, um sie auf den neuen Server zu richten. Dies geschieht sofort und wenn etwas schief geht, können Sie einfach zurückwechseln.

1 „Gefällt mir“

Das ergibt Sinn, ich habe gar nicht daran gedacht, dass das Betriebssystem mit übernommen wird.

Das Starten eines neuen Droplets wäre auch meine letzte Wahl, da ich noch nie Droplets verschoben habe (dies ist das erste, das ich habe) und auch noch nie das Betriebssystem aktualisiert habe. Aber alle Anleitungen, die ich hier sehe, scheinen durchweg zu empfehlen, es auf diese Weise zu tun, im Gegensatz zum einfachen Aktualisieren des Droplets, auf dem man sich gerade befindet. Daher dachte ich, ich mache es wie die Mehrheit, wenn beide Wege Risiken bergen und ich beides noch nie getan habe.

Mein Gedanke ist auch, wenn das Upgrade irgendwie total schiefgeht, haben Sie jetzt die Ausfallzeit durch den Versuch, die Ausfallzeit, während Sie gezwungen sind, es zu reparieren (oder aufzugeben und ein neues zu erstellen), im Gegensatz zu dem neuen, das potenziell nicht funktioniert, während Ihr ursprüngliches läuft und intakt bleibt. Ich weiß nicht, warum es schiefgehen sollte, aber wenn ich hier im Meta-Bereich suche, sagen VIELE Leute, dass es schiefgegangen ist, oder Links, die sagen, dass sie es nie auf diese Weise empfehlen würden (plus die offiziellen Anleitungen hier und DigitalOcean schlagen es vor).

Ich werde es dieses Wochenende versuchen.

Reservierte IPs (anscheinend früher Floating IPs)

Nur damit ich es ganz klar verstehe, ich folge der Anleitung discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

Nach 5. Install Discourse, kann ich den Assistenten an dieser Stelle verlassen, anstatt die Konfiguration durchzuführen, meine app.yml austauschen und dann

./launcher rebuild app

Und es sollte gut sein? (Dann in den Admin-Bereich gehen und sicherstellen, dass es aktualisiert ist/das Backup wiederherstellen)?

Korrekt: Wenn Sie eine leere app.yml-Datei erstellen (z. B. mit touch app.yml im Verzeichnis containers) und den Inhalt von Ihrem anderen Server (vorsichtig!) hineinkopieren, müssen Sie ./discourse-setup überhaupt nicht ausführen.

Ein Problem, das mich diese Woche ereilte, war meine E-Mail-Einrichtung: Stellen Sie sicher, dass Ihr E-Mail-Dienst nicht die exakte IP-Adresse erfordert, von der aus Sie aufrufen. Wenn dies der Fall ist, stellen Sie sicher, dass Sie diese Konfiguration (bei Ihrem Dienstanbieter) aktualisieren.

2 „Gefällt mir“

Es ist jedoch die sicherste Methode. Wenn Sie etwas kaputt machen, funktioniert Ihre alte Website weiterhin. Es gibt kein Risiko.

Es gibt ein Thema dazu. Sie können Ihre yml-Datei und die Let’s Encrypt-Sachen kopieren und sogar sehen, dass es funktioniert, indem Sie Ihre lokalen DNS so ändern, dass sie auf den neuen Server zeigen.

Und wenn Sie Ihre Backups auf S3 haben, können Sie besser schlafen, da Sie wissen, dass Sie im Falle eines schlimmen Problems einen neuen Server hochfahren und ein Backup in etwa 30 Minuten wiederherstellen können.

2 „Gefällt mir“

Meine einzige wirkliche Sorge war nicht so sehr das Verschieben selbst, sondern der gesamte Einrichtungsprozess, bei dem ich versehentlich eine Einstellung verpatze, sei es der E-Mail-Dienst oder Let’s Encrypt, und dies erst später bemerke, wenn alles zusammenbricht. Was offensichtlich kein Problem ist, wenn es einfach meine alte App.yml lesen kann, also ist das in Ordnung.

Ich bin mir nicht ganz sicher, was das bedeutet, aber ich glaube nicht, dass es das tut… Ich habe Mailgun und überprüfe alle Einträge dort/DNS in GoDaddy, nichts scheint mit einer bestimmten IP-Adresse verknüpft zu sein.

Okay, das klingt einfach genug, ich werde es diese Woche versuchen. Vielleicht gleichzeitig auf ein besseres Droplet upgraden.

1 „Gefällt mir“

Sie haben Recht!

Ich kann das Thema, von dem ich sicher bin, dass es existiert, nicht finden. Kurz gesagt, konfigurieren Sie Backups auf S3 in Ihren Umgebungs-Einstellungen, rsync über /var/discourse oder vielleicht nur die Verzeichnisse für SSL und Let’s Encrypt und Container, und bauen Sie dann neu.