元のサーバーを数時間シャットダウンできないため、すべての動作を確認し、サーバーを切り替えるまで、名前を変更しました。
不要です。ワイルドカード証明書をお持ちであれば、Hosts ファイルを編集してローカルの DNS 設定を変更し、バックアップ自体を復元することができます。
その後、公開 DNS を切り替えるだけです。
意味がわかりません。
テスト中は a.domain.com を稼働させておく必要があります。
また、復元中のコピーの Discourse インターフェースにアクセスして、すべてが正常かどうかを確認する必要があります。
そのため、別のサーバー上のコピーにアクセスするための別の URL が必要です。
なので、復元後に Discourse と Nginx のホスト名を単純に変更します。
すべて問題がなくなったら、新しいサーバーの名称を a.domain.com に変更し、古いサーバーをシャットダウンして、DNS の a.domain.com を新しいサーバーに指し替えます。
上記は正しくありません。ローカルマシンのHOSTSファイルを編集するか、ローカルDNSにエントリをハードコーディングすることで、同じDNS名を使用してローカルマシンを新しいサーバーに接続させることができます。
ローカルマシンを持っていません。
両方のサーバーはインターネット上、つまりクラウドサーバーにあります。
Windows マシンから ssh を使用しています。
もしかしたら、ローカルホスト名を変更してマシンの IP を設定できるかもしれませんが、サーバー側で名前を変更するよりも複雑です。
ホスト名の変更が問題の原因になると思いますか？
問題にはならないはずです…
@ariznaf さん、
はい、sidekiq プロセスが追加のアバターの画像やプロフィール画像を再構築する十分な時間が経過した後も、このカスタムアバターの問題が再び発生しているのを確認しています。ただし、これは nginx を Unix ドメインソケットへのリバースプロキシとして設定した場合 のみです。
小さなアイコンのアバターは問題ありませんが、プロフィールカードやプロフィールページでは機能しません（以前にキャッシュされ、そのキャッシュがまだ有効な場合を除く）。
以下の操作を行うとすぐに、
nginx -s stop; ./launcher start web-only
カスタムアバター画像の問題は解消されます（ブラウザでまだ表示/キャッシュされていない画像の場合）。
そして、すぐに以下の操作を行うと、
./launcher stop web-only; nginx
カスタムアバター画像の問題が、まだ表示/キャッシュされていない画像に対して再び発生します。
HTTPS にエラーはなく、これは force_https のせいでもありません（全く無関係です）。
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
79 | force_https | 5 | t | 2020-04-16 05:51:13.165124 | 2020-04-16 05:51:13.165124
(1 row)
この問題は、モバイル（iOS、最新バージョン）、デスクトップ、Chrome（最新）、Safari（最新）など、すべての環境で確認されています。
nginx を Unix ソケットへのリバースプロキシとして使用すると、カスタムアバター画像に奇妙な影響が生じています。
現時点では、@ariznaf さんにお知らせするのは恐縮ですが、私たちは問題を特定できず、解決策も持っておりません。
nginx を Unix ソケットへのリバースプロキシとして設定した場合、Discourse アプリ（コンテナ）が、nginx を Unix ドメインソケットへのリバースプロキシとして使用しない設定の場合のように、これらのカスタムアバター画像を再構築していない「ように感じられます」。
もしかすると、sidekiq が nginx を Unix ソケットへのリバースプロキシとして設定 した環境を好まず、この再構築プロセスのスケジューリングや実行を拒否しているのでしょうか？（笑） @riking さん？
奇妙ですね。
以下はフォローアップです：
私たちが議論している Unix ソケットを使用したリバースプロキシ設定では：
しかし、force_https を確認すると：
Last login: Fri Apr 17 06:29:58 2020 from 159.192.216.252
# cd /var/discourse
# ./launcher enter data
# su postgres -c 'psql discourse'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
discourse=# select * from site_settings where name like '%http%';
id | name | data_type | value | created_at | updated_at
----+-------------+-----------+-------+----------------------------+----------------------------
80 | force_https | 5 | t | 2020-04-18 03:33:10.641567 | 2020-04-18 03:33:10.641567
(1 row)
そして当然ながら、ブラウザの証明書にエラーはありません（Chrome は正常に動作しています）：
そのため、私の「知識不足な」推測では、この設定において force_http 設定/メソッドにこれらの画像が含まれていないのではないかということです。カスタムアバター（およびプロフィールページの画像）を除いて、他のすべての点は問題ありません。
これが私の「Discourse の知識レベルを超えた」推測です。
更新：
さらに調査した結果、すべての nginx reverse proxy to unix socket 設定で /shared/uploads（ファイル）の大部分が欠落していることがわかりました。このステップは、私が読んださまざまなチュートリアルやハウツー文書に含まれていませんでした。そのため、次にメタでこのトピックに関するウィキを見かけたときは、そのチュートリアル/ウィキ/ハウツーにこのステップを追加するようにします。
残っている小さな問題点は、ファビコンに関するものです：
これを修正するための推奨方法をご存知の方がいれば、ぜひ教えてください。ありがとうございます！
再アップロードしてください。それが最も迅速な解決策です。
ソケットを使用している際に、HTTPS テンプレートが無効化されていることを忘れ、force_https を手動で有効にしない限り、Discourse は SSL の背後にあることを認識できないため、昨日私が提案した通りです。
force_https を有効にすれば、アセットを再アップロードしてパスを修正できます。
私はこれに対して一切返信していませんでした。組み込みのバックアップ機能を使用しない、何らかの失敗したサーバーデータ転送によって /uploads/ が完全に抜け落ちていたと思い込み、それをあなたが理解できるような方法で説明する方法が全くわからなかったからです。
はい…nginx リバースプロキシの設定にはこのガイドに従いましたが、これはスタンドアロン環境向けの設定であり、スタンドアロンモードでは転送が必要なかったため、uploads については言及されていませんでした：
また、2 つのコンテナ用のガイドも従いましたが、これも DB のリストアやアップロードディレクトリの転送については言及されていませんでした：
私たちは物事を簡単に理解できます。参考までに、あなたが欠かしていた説明のヒントをここに示します：
この構成に関する主要なチュートリアルには、DB のリストアを行うか、アップロードを新しいコンテナに手動で転送する必要があるという事実が抜け落ちています。なぜなら、私たちはそれを記載していなかったからです。
もちろん、今回も 100% 自力で解決した後には理にかなっています（再び！）。なぜなら、チュートリアルには載っていないからです。笑
問題がわかれば、すべてが簡単になります。
PS: 締めくくりとして。さまざまなチュートリアルを書いてくださった皆様に感謝します。大変役立ちました！心から感謝しています。当方では、この設定は完了し、今後どの Discourse サイトでもスタンドアロン構成は使用しません。通常の「デフォルト」は、リバースプロキシを介して Unix ソケットに接続する 2 つのコンテナ構成です。これは、ほぼダウンタイムゼロでリアルタイムに更新やコンテナの切り替えを行うのに最適です。素晴らしいですね！！
Discourse は最高です！！
Jeff @codinghorror と Sam @sam、お疲れ様でした！ブラボー！
これは比較的簡単に動作させることができますが、前述の通り、私たちは S3 や他のクラウドストレージサービスは使用しておらず、物事を「シンプル」に保つことを好んでいます。そのため、バックアップは単に rsync でオフサイトストレージに同期するだけです。私たちはこの方法が好ましいと考えています……デバッグすべきことが一つ減りますし、S3 がなくても「生き延び」られます。
これが役立つかどうかはわかりませんが、画像の最適化は、最適化タスクを実行するジョブがインターネットドメイン名を通じてサーバーにアクセスできない場合に失敗する傾向があります。
これは、より複雑なリバースプロキシ設定で期待通りに動作しない理由を説明するかもしれません。
ケインさん、ありがとうございます。
ご存知かと思いますが、Discourse の標準的な UI を通じたバックアップ方法以外の代替手段を試していました。
標準的なバックアップ方法からのリストアを毎回試みる際に問題が発生し、このサイトの公式チュートリアルに記載されている手順を常に遵守していたためです。
いずれにせよ、冒頭で述べたとおり、私が試したのは UI インターフェースを使用したバックアップからのリストアであり、標準的なバックアップ手順および推奨されるリストア手順に従ったものです。
スタンドアロン Discourse の標準インストールとの唯一の違いは、ソケットを介して Discourse に接続するリバースプロキシとして Nginx を使用している点です。
発見された主な問題はアバターに関連するもので、アバターが失われ、デフォルトのプロフィール画像に置き換えられていたようです。
あなたは、これは Sidekiq ジョブによって再構築される必要があると教えてくれました。しかし、そのジョブは実行すると即座に「OK」ステータスで成功して終了するようですが、アバターは変更されません。
バックアップは私たちにとって非常に重要です（誰がそれを無視できるでしょうか？）。したがって、指示を非常に慎重に守り、ここで提示された他のアイデアも試して、さらにテストを実施します。
私たちは Discourse を非常に気に入っており、満足しています。単に、最近攻撃を受けたこともあり、サーバー障害に備えて、堅牢なリストア手順が確立されていることを確認したいだけです。
この問題の解決に向けたテストや情報提供をご希望であれば、喜んで最善を尽くし、必要な情報を提供いたします。
どうやら、システムがアバターのミニチュア画像にアクセスできないのは確かなようです。
ただし、ルーター、SSL、その他すべての設定が正しく行われており、フォーラムの残りの部分は正常に提供されているようです。
何らかの設定ミスがあった場合、Discourse フォーラムにアクセスして他のコンテンツを表示することはできず、502 エラーなどのエラーが発生したはずです。
@neounix
S3 を使用しているのは、UI からバックアップをオフサイト保存するための最も簡単な方法だからです。
S3 が最適な選択肢ではないかもしれません。しかし、バックアップの保存場所自体が問題の原因ではありません。バックアップにアクセスして復元できないという問題ではないからです。
復元は正しく行われています。
@stephan
app.yml では、SSL テンプレートと Let’s Encrypt テンプレート、そしてポートを公開する expose セクションをコメントアウトしました。
SSL は nginx が処理するため、ソケットを暗号化する必要はないはずです。
これは誤っていますか？それでも SSL テンプレートを使用すべきでしょうか？
これが問題だった場合、復元後にアバターだけでなくフォーラムのどの部分も表示できなくなるはずですが、誰にもわかりません…
さらにテストを行います。皆様のご協力に感謝いたします。
@ariznaf … やあ！
私がこの問題を 2 つの異なるサーバーで解決した方法は、元のセットアップから /shared/uploads ディレクトリを socket-only セットアップに手動でコピーすることでした。その後、この問題は解消しました。
私が素早く確認できた方法は、uploads ディレクトリのサイズを比較することでした。単純に次のようにします（共有ディレクトリにいると仮定します）：
du -sh uploads
それらを比較したとき、問題が何だったかが分かりました
あなたも確認してみてはいかがでしょうか？これで問題の特定に役立つことを願っています。
PS: S3 に対して否定的なわけではありません。ことわざにあるように、各人の好きにすればよいのです……
私があなたの意図を正しく理解しているか確認させてください。
バックアップを作成する際、アップロードファイルも保存するように設定しています（サムネイルは含みませんが、サムネイルも保存できることをテスト済みです。現在はサムネイルも保存しているので、再構築を待つ必要はありません）。
復元後、アップロードファイルも正しく復元されます。
つまり、アップロードファイルの復元が正しく行われず、手動で行う必要があるという意味でしょうか？
アップロードファイルを手動で復元するにはどうすればよいですか？
バックアップをダウンロードし、shared/standalone/uploads を untar しましたか？
もしそうであれば（私も試してみます）、復元ジョブに何らかのバグがあることは明らかだと思います。
ありがとうございます。
バックアップの作成と保存の代替方法を探していますが、Discourse の関係者は、標準的なバックアップ機能を使用することが唯一正しい方法だと主張しています。
ariznaf さん、こんにちは。
管理 UI からのリストアは行っておりません（Web インターフェースからのバックアップのみで、リストアは行いません）。ファイル（アップロードデータを含む）を sftp でコンテナに転送し、以下のようにしてリストアを行います。
cat /shared/neo/bin/restoreneo
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community7-2020-04-15-095302-v20200403100259.tar.gz
echo "discourse disable_restore"
discourse disable_restore
ただし、先日 nginx リバースプロキシを Unix ソケットに接続する 設定を作成した際は、データベースからのリストアは行いませんでした。データベースはすでに data コンテナ内に存在していたためです（これはハウツートピックでも言及されています）。
そのため、アップロードデータを新しいコンテナに手動でコピーする必要がありました。
あなたの状況は ours とは異なるようです。
参考になれば幸いです。
ありがとうございます。
コマンドラインから、インターフェースで行っているのと同じ手順（復元を有効にし、データベースとアップロードを含む tgz ファイルから復元する）を実行されているようですね。
その後、アバターを動作させるために（ソケットと nginx リバースプロキシを使用）、アップロードのみを再度復元する必要があるとおっしゃいましたが、合っていますか？
@ariznaf さん、こんにちは…正確にはちょっと違います…
最初は、スタンドアロンのアプリを持っていました。その後、そのアプリをデータ用と Web 専用という 2 つの異なるコンテナに分離し、アップロードを含む大きなバックアップファイルからリストアを行いました。
その段階ではすべて問題なく進みました…
次に、socket-only という新しいコンテナを作成し、リバースプロキシを使用するように設定しました。
新しい socket-only コンテナではリストアは行いませんでした（データコンテナにはすでにデータベースデータが正常に含まれていたため）が、アップロードを手動でコピーし忘れたのです（これが私のミスでした）。通常のリストア手順を行っていれば、これは必要ありませんでした。
しかし、新しいコンテナでデータベースを手動で再度リストアする理由はありません。データを独自の「かわいらしい小さなコンテナ」に分離しているのがまさにその理由だからです。したがって、この状況では、アップロードを新しいコンテナにコピーする必要があります。実はこれは非常にうまく設計されています。
これで分かりましたか？
私が言ったこととは異なります。私が言いたいのは、バックエンドがフロントのnginxを介して自分自身にアクセスできないということです。あなたが言っているのはその逆です。
アップロードを最適化するために、Sidekiqジョブはhttp(s)を使用してそれを取得します。
いいえ、SSL テンプレートを無効化できますが、force_https は手動で有効化する必要があります。