Discourseを別のサーバーへ移行する方法（同じDNS名を維持）

サポート インストール
1

Discourseを個人ホスティングからAmazon LightSailサーバーへ移行しようとしています。サーバー移行やDiscourseのセットアップに関するスレッドをすべて検索し、読みました：

Move your Discourse Instance to a Different Server
Restore a backup from the command line
How To Install Discourse on Ubuntu 18.04 | DigitalOcean
discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

私の理解では、手順は以下の通りです：

  1. 新しいDiscourseサーバーをインストールする
  2. 既存のDiscourseからバックアップをエクスポートする（現在はS3への保存が設定されていますが、これは手動でのファイルバックアップになると思います）
  3. 新しいDiscourseにバックアップをインポートする（S3から直接読み取れないため、手動で行う必要があります）

いくつかの制約があるため、ステップ1の進め方が少し詰まっています。ドメイン名は1つしかなく、新しいサーバーでも同じドメイン名を維持したいと考えています。また、ダウンタイムは避けたいです（目標は、新しいサーバーのセットアップを完了し、バックアップを復元してから、最終的にDNSエントリを新しいサーバーに変更することです。これにより、両方のサーバーが同時に稼働している状態でダウンタイムを回避できます）。

私の理解では、新しいDiscourseサーバーを設定する際、既存サーバーのapp.ymlを新しいサーバーにコピーし、その後discourse-setupを実行できます。ここで問題なのは、これを行うと既存サーバーと同じDNS名を使用してしまう点です（これは望ましい動作ですが）。以下の2つの問題が予想され、その解決策を探っています：

  1. Let’s Encryptは、ドメイン名がまだ古いサーバーを指しているため、新しいサーバー用のSSL証明書を作成してくれません。
  2. SSL証明書がないと（古いサーバーの設定ではSSLのみを使用するように設定されており、これはapp.ymlに引き継がれます）、サーバーが起動しません。
  3. DNS名のリダイレクトを使ってDiscourseサーバーに接続しようと試みましたが、入力されたURLがapp.ymlの設定と一致しない場合、NGINXまたはDiscourseが機能せず、ブラウザで接続しようとするとエラーが発生します。そのため、Webインターフェースがない状態で復元プロセスを開始できません。

既存サーバーのapp.ymlを使用して新しいDiscourseサーバーのセットアップを完了し、その後バックアップを復元してDNSの切り替えを行うにはどうすればよいでしょうか？あるいは、より簡単な方法があるでしょうか？

2

S3 バケットを同じものを使用しない場合は、バックアップが S3 ファイルをダウンロードするように強制する非表示の設定があります。設定ファイルでその名前を確認し、rails コンソールで設定できます。これについて議論しているトピックもありますが、settings.yml を確認するのが最も簡単かもしれません。

discourse-setup を実行する必要はありません。app.yml をコピーして再構築するだけで十分です。

Let’s Encrypt の証明書は rsync で転送できます。実際には、いくつかのログなどを除いて /var/discourse 全体をコピーすることも可能です。

「いいね！」 3
3

理想的には「リフト＆シフト」を行いたいところですが、Amazon Lightsail では既存のイメージをインポートできないため、それは不可能です。そのため、正確には同じ S3 を使用することになります。

あなたのアプローチは、リフト＆シフトに最も近いもののようです。おっしゃることを理解している限り、元のサーバーから_/var/discourse_フォルダ全体を tar/gz 圧縮し、新しいサーバーで展開した後、discourse startを実行し、DNS を Bee サーバーに再設定するだけで済むということでしょうか？それだけでよいのでしょうか？新しいサーバーで Discourse を再構築する必要はありませんか？また、Nginx、Docker、およびそのフォルダ外の他の依存関係についてはどうすればよいでしょうか？

4

はい、ご自身で合理的と思われる方法でファイルを移動してください。はい、新しいコンテナをビルドして起動するには、再ビルドが必要です。

「いいね！」 1
5

ありがとうございます。どうやら「リフト＆シフト」は私が思っていたほどきれいな作業ではなかったようです。スムーズなリフト＆シフト操作を確保するためには、前後にいくつかの確認作業が必要です（Postgres が 12.0 から 13.0 へアップグレードされた際、リフト＆シフトのプロセスについていくつかの教訓を得ました）。以下は、Amazon LightSail サーバー（1GB RAM）への移行を試みる方々のための将来の参考となるステップバイステップガイドです。

元のサーバー

  • S3 へのバックアップを作成
  • cd /var/discourse
  • ./launcher rebuild # 簡単な移行のために最新のビルドを取得
  • ./launcher cleanup # 古いデータを削除しパッケージサイズを削減
  • ./launcher stop app # これを行わないと、後で Postgres を使用して再ビルドしようとした際に失敗します
  • tar -zcvf /var/discourse discourse.tar.gz

新しい Amazon LightSail サーバー

  • Amazon から Ubuntu 20.20 イメージをインストール（1GB RAM）
  • Docker をインストール
  • 2GB スワップ を作成 # これを行わないと再ビルドが失敗する可能性があります
  • vm.overcommit_memory=1 を設定 # これを行わないと、再ビルド中に Postgres で失敗する可能性があります
  • 元のサーバーから discourse.tar.gz を FTPS/転送
  • tar -zxvf discourse.tar.gz -C /
  • cd /var/discourse
  • app.yml 内の UNICORN_WORKERS を 2 に設定 # 1GB RAM で 2 を超えると、過度なディスクアクティビティによるスワップとスロットリングのリスクがあります
  • ./launcher rebuild
  • DNS を新しい Amazon サーバーを指すように変更

Discourse のセットアッププロセスを経ることなく、サーバーを移行（リフト＆シフト）するより簡単な方法はありませんか？

「いいね！」 1
6

discourse-setup を実行せずに済むという意味ですか、それとも Discourse を実行するために必要なコンテナをビルドせずに済むという意味ですか？後者の場合、古いイメージを新しいサーバーが使用できるリポジトリにプッシュすることで可能ですが、これは初心者には容易に扱えるものではありません。

あなたのプロセスは PG13 へのアップグレードによって複雑になりました。新しいサーバーでゼロから新しいイメージをビルドし、古いサーバーからのバックアップをリストアする方が少し簡単だったかもしれませんが、新しいサーバーで Let’s Encrypt 証明書を取得するための面倒な手順は依然として残ります。

「いいね！」 1
7

はい、それが新しいサーバーで ./discourse-setup を実行し、その後 S3 イメージから復元するのを妨げていた唯一の要因です（DNS がまだ旧サーバーを指している状態で、Web 管理コンソールにアクセスできない場合の方法については、AFAIK Discourse はブラウザでの IP アドレスへの応答を行わないため）。ライブシステムを持っており、DNS を旧システムから新システムへ即座に切り替える必要があったため、Let’s Encrypt 証明書がないことが私にとって唯一の障壁でした。
もし旧システムから新システムへ証明書を移行し、Let’s Encrypt エラーなしで ./discourse-setup を完了させ、Web コンソールなしで S3 バックアップから復元できる方法があれば、それがよりシンプルな方法になるでしょう。

8

containers 内の yml ファイルを上書きコピーする場合は、discourse-setup は不要です（新しいサーバーでメモリパラメータが異なる場合に調整できますが、後で行うことも可能です）。そのまま ./launcher rebuild app を実行するだけです。

9

なるほど、おっしゃっていることは理解できましたが、念のため私の理解を再確認させてください。

元のサーバーでは、Discourse のバックアップを S3（設定とサイトコンテンツ）に行うように設定されていました。

containers 内の yml ファイルをコピーすることで、元のサーバーのすべての設定が新しいサーバーに引き継がれます。そのため、新しいサーバーでは discourse-setup を実行する必要はなくなり、代わりに ./launcher rebuild app を実行すれば、元のサーバーの設定を使用して最新イメージをダウンロードし、Discourse を設定できるようになります。

現在、以下の 2 点が未解決です：

  1. Let’s Encrypt の証明書をどう転送するか（DNS はまだ元のサーバーを指しているため、再発行はできず、./launcher rebuild app を実行する前にこれを済ませる必要があると思われます）。
  2. リビルド後に S3 バックアップから Discourse（設定＋コンテンツ）をどう復元するか。DNS はまだ元のサーバーを指しているため、IP アドレスや localhost で Discourse の管理画面にアクセスする方法はあるでしょうか？あるいは、S3 バックアップをコンソール経由で復元することは可能でしょうか？
10

古い /var/discourse をコピーすれば、証明書が取得され、再構築が期待通りに実行されます。

コンテナ内からコマンドラインで復元できます。

11

詳細な手順をありがとうございます。私も同様のことを、新しいホストへの移行で行いました。
サイトは動作していたので、バックアップをやり直すのは避けたく、ここに記載されている手順に従いました。

ほぼうまくいきましたが、新しいホストでの再構築が失敗しました。
原因は、2つのホスト間でUID/GIDのマッピングが完全に同じではなかったため、Postgresの起動時にデータフォルダの所有権が正しくなく、エラーが発生したことでした。

これは他のインスタンスでも起こりうることで、幸いなことに修正方法があります。

この投稿のシナリオには、もう一つ追加の注意点があります。それは、コンテナがビルドされていないため、この段階では ./launcher enter app が機能しないことです。再構築にはかなりの時間がかかるため、docker ps を使用してビルド中のコンテナ名を取得し、コンテナに入ることができました。

docker exec -it <container_name> bash
chown -R postgres:postgres /shared/postgres_*

その後、再構築は失敗します（または CTRL+C で停止できません）。停止した後、再度実行するだけで、権限が修正されます。

./launcher rebuild app

そして、再び動作するようになりました :sweat_smile: 。

「いいね！」 1
12

RAM 1GBを使用している方は、少なくとも4GBのスワップを作成してください。そうしないと、再構築が失敗します。3.1.x to 3.2.0 upgrade hangs/fails on 1GB instance を参照してください。

「いいね！」 1