申し訳ありませんが、この質問はすでにされているかもしれませんが、探しましたが、私が計画している正確なシナリオは見つかりませんでした（または見落としたかもしれませんが、初めて行うので、確実に正しく行いたいと思っています）。
私はまだ18（私が始めた場所です。Linux OSのアップグレードはセキュリティアップデート以外は行ったことがありません）なので、近いうちに22に移行する予定です。ここで読んだすべては、既存のものをアップグレードするよりも新しいインストールに移行する方がはるかに賢明であると示唆しています。なぜなら、潜在的に無数のランダムな問題が発生する可能性があり、それらが発生しても無意味な手間になるだけなので、リスクを冒す価値はないからです。
このガイドを読みました Move your Discourse Instance to a Different Server しかし、それはあるサーバーからDigitalOcean（またはその逆）への移動を参照しており、スナップショットは適用できません。一方、私は既存のDigitalOcean Dropletから新しいものへの移動を計画しています（これは、アップグレードに理想的で、うまく機能するという複数の参照を見てきました）。
したがって、DO>DO転送に関する私の質問は、Dropletをシャットダウンし、スナップショットを取得し、希望する更新されたUbuntuで新しいDropletを起動し、スナップショットをロードして、完了できるかということです（ドメインのDNSレコードなどを調整しますか）？基本的に、ガイドで詳述されている「Discourseを完全に再インストールする」ことを回避します。スナップショットは、Discourseのセットアップのバックアップとは異なり、Dropletのインストールと1対1で同一であると理解していますが、後者は実際に利用するために完全なインストールが必要です。私の理解は正しいですか？これによるダウンタイムの長さ以外の欠点はありますか？
要約：スナップショットを取得し、新しいアップグレードされたDropletを作成し、スナップショットをロードして完了できますか？
Stephen
2023 年 4 月 16 日午前 9:14
2
DO スナップショットには OS バージョンが含まれます。スナップショットを復元すると、オペレーティング システムがロールバックされます。
実用的な選択肢は、バックアップを移動するか、/var/discourse を rsync して Docker を手動で再インストールすることです。
「いいね！」 2
Jagster
2023 年 4 月 16 日午前 9:15
3
おそらく完全に間違っているわけではないと思いますが、22で18のスナップショットを復元すると、スナップショットはドロップレット全体の1:1コピーであるため、18に戻ります。
私にとっては、完全に新しいドロップレットを起動するのは常に最後の選択肢です。なぜなら、メールシステムなど、Ubuntu（または他のOS）が必要とするすべてをインストールする必要があるからです。
これは、できる人にとっては些細なタスクにすぎないことは確かですが、10年経っても、新しい機能的なドロップレットを簡単に起動する方法を学んだことがありません。
「いいね！」 2
Discourseのインストールは30分程度で完了しますか？
サイトとapp.ymlのバックアップを作成し、新しいOSバージョンの新しいドロップレットを作成し、IPを新しいドロップレットに再割り当て（ドメインが正しい新しい場所を指すように）、Discourseをインストール（ウィザードを終了してapp.ymlを更新し、再構築できます）、バックアップをインポートします。
このプロセス全体で1時間もかからないはずです。
このプロセスでは既存のドロップレットには一切触れないため、万が一うまくいかなくても、簡単にロールバックできますか？
「いいね！」 2
Ed_S
2023 年 4 月 16 日午後 5:48
5
OSのLTSバージョンから次のバージョンに移行する場合、比較的スムーズなプロセスを期待するでしょう。そのため、もちろんバックアップを取り、安全のためにダウンロードしてから、OSのアップデートを試みます。もしうまくいかなければ、OSをクリーンインストールすることを試すことができます。
しかし、これを行うとフォーラムのダウンタイムが長くなります。
フォーラムをクリーンインストールすることには、DNSを更新して伝播を待つ必要があるため、少し気が進みません。ただし、上記の投稿ではIPアドレスを持ち運べると書かれており、それは良いことで、この気が進まないという気持ちを取り除いてくれます。
実際、私の答えを完全に変えますが、IPアドレスを新しいインスタンスに持ち運べるのであれば、それが望ましいでしょう。おそらく、すべてのプロバイダーがこれを許可しているわけではありません。おそらく、一部のプロバイダーでは、IPアドレスが移動しても、実際には変更されていないにもかかわらず、コストのかからないIPを失い、IPの支払いを開始することになるでしょう。
「いいね！」 1
Stephen
2023 年 4 月 16 日午後 6:11
6
Ed S:
DNSを更新して伝播を待つ必要があります。
これに対する非常に簡単な緩和策は、TTLを非常に低く設定する（またはこれをサポートするネームサーバーに切り替える）ことです。そうすれば、レコードは再構築にかかる時間よりも短い時間で期限切れになります。
「いいね！」 2
pfaffman
2023 年 4 月 18 日午前 7:48
7
静的IP（DigitalOceanが現在どのように呼んでいるか思い出せませんが）を使用できます。ネットワーキングで新しいIPを取得し、それを古いドロップレットにマッピングできます。その後、DNSを変更して伝播させます。新しいサーバーに移行する準備ができたら、IPを新しいサーバーに向けるだけです。これは即座に発生し、何か問題が発生した場合は、元に戻すことができます。
「いいね！」 1
Jakke Lehtonen:
おそらく私は完全に間違っているわけではありませんが、18のスナップショットを22に復元すると、スナップショットは全体 のドロップレットの1:1コピーであるため、18に戻ります。
私にとって、完全に新しいドロップレットを起動するのは常に最後の選択肢です。なぜなら、Ubuntu（または他のOS）が必要とするすべてのもの、メーリングシステムなどを含むすべてをインストールする必要があるからです。
できる人にとっては、これは単なる些細なタスクであることは間違いありませんが、10年経っても、新しい機能的なドロップレットを簡単に起動する方法を学んだことはありません。
それは理にかなっています。OSが移動することについては全く考えていませんでした。
新しいドロップレットを起動するのは、私も最後の選択肢です。なぜなら、ドロップレットを移動したことがない（これが最初のドロップレットです）し、OSをアップグレードしたこともないからです。しかし、ここにあるガイドは、ほとんどすべてが、現在使用しているドロップレットをアップグレードするよりも、そのようにすることを推奨しているように見えるので、両方の方法にリスクがあるなら、多数派に従うのが良いだろうと思いました。
また、アップグレードが完全に失敗した場合、試みたダウンタイムがあり、それを修正しようと（または諦めて新しいものを作成する）強制されるダウンタイムがあり、新しいものが機能しない可能性がある一方で、元のものは実行中でそのまま残るという考えもあります。なぜ失敗するのかはわかりませんが、ここでメタを検索すると、失敗したという人がたくさんいます。または、その方法を絶対に推奨しないと言う人もいます（さらに、ここにある公式ガイドとDigitalOceanもそれを推奨しています）。
週末に試してみます。
予約済みIP（以前はフローティングIPと呼ばれていたようです）
ガイド discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub に従うということで、念のため確認させてください。
Discourse のインストール後、その時点でウィザードを終了しても問題ありません。設定を行わず、app.yml をスワップしてから、
./launcher rebuild app
を実行すれば、問題なく動作しますか？（その後、管理者画面に入り、更新されているか確認/バックアップを復元しますか？）
merefield
2023 年 4 月 19 日午後 12:10
10
Correct: コンテナディレクトリでtouch app.ymlのように空のapp.ymlファイルを作成し、他のサーバーから（注意して！）内容を貼り付ければ、./discourse-setupを実行する必要は全くありません。
今週私を悩ませた問題の1つは、メールの設定でした。メールサービスが、接続元の正確なIPアドレスを要求しないことを確認してください。もし要求する場合は、（サービスプロバイダーで）その設定を更新するようにしてください。
「いいね！」 2
pfaffman
2023 年 4 月 19 日午後 12:19
11
それでも、それが最も安全な方法です。もし壊れても、古いサイトは引き続き機能します。リスクはゼロです。
それに関するトピックがあります。ymlファイルとLet’s Encryptの設定をコピーし、ローカルDNSを変更して新しいサーバーを指すようにすることで、それが機能することを確認できます。
そして、バックアップがS3にある場合、何かひどくうまくいかなくても、約30分で新しいサーバーを起動してバックアップを復元できることを知って、より安心して眠ることができます。
「いいね！」 2
Jay Pfaffman:
それでも最も安全な方法です。壊しても、古いサイトは引き続き機能します。リスクはゼロです。
それに関するトピックがあります。ymlファイルとLet’s Encryptの設定をコピーして、ローカルDNSを変更して新しいサーバーを指すようにすることで、それが機能することを確認できます。
そして、S3にバックアップがあれば、何かひどくうまくいかなかった場合に、新しいサーバーを起動して約30分でバックアップを復元できることを知って、よりよく眠ることができます。
私の唯一の実際の懸念は、単にそれを移動することではなく、セットアップ全体を通過して、メールサービスやLet’s Encryptの設定のいずれかで設定を誤ってしまい、すべてが崩壊した後にのみそれを認識することでした。明らかに、古いapp.ymlを読み取ることができるのであれば、それは問題ではありません。
これが何を意味するのか完全にはわかりませんが、そうではないと思います… Mailgunを持っており、そこですべてのレコード/ GoDaddyのDNSを確認していますが、特定のIPに関連付けられているものは何もなさそうです。
さて、簡単そうです。今週試してみます。同時に、より良いDropletにアップグレードするかもしれません。
「いいね！」 1
pfaffman
2023 年 4 月 19 日午後 12:50
13
Kartoon:
ないと思います
その通りです！
存在すると確信しているトピックが見つかりません。要するに、環境設定でS3にバックアップを設定し、/var/discourse を rsync するか、SSL、Let’s Encrypt、コンテナのディレクトリだけをバックアップしてから再構築してください。