新しいサーバーへのディスコースインスタンスの移行

インストール
1

\u003e 質問する前に、まず検索しましたか？検索するには右上にある🔍を押してください

こんにちは、

ご支援いただければ幸いです。それを踏まえた上で、私の問題と、セルフホスト型Discourseインスタンスの目標について話し合いたいと思います。

問題

現在、DiscourseインスタンスをホストしているサーバーとしてHetznerを使用しています。UploadsとBackups用のボリュームをアタッチしました。現在のDockerコンテナとイメージ、およびapp.ymlなどは、サーバー自体の/var/discourseの下にホストされています。

このサーバーは3〜4年以上使用していますが、その間、サーバー自体（ボリュームではない）のスペースの問題に常に悩まされてきました。アプリを再構築または再起動するたびに、イメージとDockerコンテナがボリュームではなくローカルサーバーにインストールされるため、スペースの問題が発生していました。再構築できるように、Dockerおよびすべてのイメージ/コンテナを削除し、クリーンな再インストールを常に必要としていました。SQLデータもボリュームではなくローカルサーバーにアタッチされていると考えています。

目標

今後、何が最適なのかわかりません。Postgres DBとDockerイメージ用の新しいボリュームに特定のフォルダやファイルを移動することでしょうか？もしそうなら、その方法についてサポートしていただけると幸いです。それとも、新しいサーバーで最初からやり直し、サーバーのバックアップを作成し、すべてのボリュームが適切に設定された場所にある新しいサーバーに復元することでしょうか？

これらすべてを踏まえて、app.ymlを適切に設定して、バックアップ、アップロード、DB、またはDockerイメージなどが個別にスケールできるように、すべてのスペースを占有するもののためのボリュームを設定することについてサポートしていただけると幸いです。

現在仕事中なので、後でapp.ymlファイルを提供できます。ゲームに先んじて進めたいと思っています。

2

私はAWSでDiscourseをホストしており、これまでのところ/var/discourseを独自のEBSボリュームにマウントし、移行が必要なときにそのボリュームを異なるEC2インスタンスにアタッチするという方法で大きな成功を収めています。x64からARMへのアーキテクチャ変更（EC2インスタンスをt3a.largeからr7g.largeに変更）も完全に実施しましたが、/var/discourseボリュームを再マウントした後、アーキテクチャの切り替えがあったにもかかわらず、簡単なlauncher rebuild appでオンラインに戻ることができました。

要するに、/var/discourseがマウント可能なボリュームに保存されていれば、フォーラムのすべての状態が実質的にスイングマウント可能な状態になります。ホストをセットアップしてDockerをインストールできれば、/var/discourseをそれにマウントし、launcher rebuild appを実行すれば稼働できます。（ホスト間でapp.ymlで指定されたホスト名などが一定であると仮定します。）

3

このセットアップのサンプル app.yml を提供していただけますか？また、「/var/discourse」の内容を別のボリュームに移動するだけで簡単なことですか、それともリポジトリを新しいボリュームにクローンする必要がありますか？

データベースファイルはどうなりますか？

4

現在作業中の app.yml のサニタイズされたコピーを以下に示します。

5

そして、DBのすべてのコンテンツは /var/discourse に保存されるのですか？ では、/var/discourse のすべてのコンテンツをマウント可能なボリュームに移動すれば、既存のすべてのデータを使用し続けるはずですか？

6

標準のシングルコンテナ・セルフホストインストールを使用しているので、すべてデフォルト設定のままセットアップされています！

7

質問ですが、/discourseフォルダをマウント可能なボリュームに移動した後も、Dockerでコンテナとイメージがボリュームではなくローカルドライブで実行されてしまう問題にまだ苦労しています。これを修正する方法について何かアイデアはありますか？

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.