これは、多くの完璧な Discourse インストールとマイグレーションを経た後でも、私には理解できない問題です。
背景:
Discourse は Docker コンテナ内で正常に動作しており、Postgres DB の細かい調整を進めていました。
問題は、生投稿のリベイク（再焼成）結果に満足できず、計画通りに何も機能しなくなった時に発生しました。そのため、Postgres DB を破棄して再作成することにしましたが、アプリは様々な権限エラーなどを返し続けました。
そこで、「思い切ってやろう」と決め、「どうせだめなら」という勢いで、Postgres に直接アクセスして（うまくいかないことは分かっていたが試してみたかった）、DB からすべてのトピックと投稿を削除しました（DELETE FROM topics; DELETE FROM posts;）。これはある程度機能しましたが、結果には満足できませんでした（実験終了）。そこで、Discourse を最初から再構築し、古い /var/discourse を退避させ、git から最新のコードを取得してやり直すことにしました。
問題点
git pull から完全に new をビルドすると、ビルド自体は問題なく動作しましたが、サイトへアクセスして管理者ログインを作成する段階で問題が発生しました。
新しいインストールの管理者ログインページに行くと、破壊したはずの古いサイトが表示されたのです。これは驚きでした。
そこで、この新しいアプリに入り、DB からすべての Discourse テーブルを削除しようと試みました。実際に削除はできましたが、再びアプリをビルドすると、それは新しいサイトではなく、上記の壊れたサイトと同じものとして起動しました。
そこで、すべての /var/*discourse* ディレクトリを削除し、すべての Docker images を削除しました。これで totally clean になると思い、再び git から /var/discourse へ取得し、total scratch からビルドを開始しましたが、またもや古いサイトが表示されました。
「どうしてこんなことになるんだ…？」と考えました。
Docker コンテナの外で ps aux | grep postgres を実行すると、コンテナの外にも postgres プロセスが存在していることに気づきました（これは驚きでした。Discourse の Docker インストールはすべてコンテナ内にあると思い込んでいたためです）。そこで、どこをクリーンアップすればよいか探しましたが、手詰まりでした。
Google のリンクがすべて紫色になるまで検索し、あらゆる手を尽くしましたが、discourse のクリーンインストールができませんでした。
何か見落としていると思い、discourse を never installed（一度もインストールしたことがない）新しいサーバーを用意し、そこから discourse を最初からインストールしましたが、いつものように問題なく動作しました（別のサーバーでの話です）。
質問
私の質問は、つまり…インストールが何らかの理由で完全に破綻してしまった場合、サーバー（postgres を含む）をどのようにしてゼロの状態（ground zero）に戻せば、この問題が解決し、完全に新しいインストールを開始できるのでしょうか？
長くなってしまい申し訳ありません。The Question だけでも助けを得られたかもしれませんが。
ありがとうございます。
michaeld
2020 年 3 月 15 日午前 9:19
2
テーブルを削除または空にするのではなく、データベース全体を削除してください。
DBを削除しようとしましたが、権限エラーが繰り返し発生します。
/var/www/discourse# su postgres -c 'psql'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
postgres=# drop database discourse;
ERROR: database "discourse" is being accessed by other users
DETAIL: There are 3 other sessions using the database.
何か心当たりはありますか？
pfaffman
2020 年 3 月 15 日午前 9:44
5
私の最善の推測では、実行中の Docker コンテナを削除しなかったようですが、イメージは削除したとおっしゃっています。何か他の兆候が現れたはずです。
あるいは、コンテナ内のものではなく、外部の PostgreSQL を使用しているのでしょうか？
通常、/var/discourse/shared を削除して再構築すれば解決します。
ありがとうございます。
直前の discourse データベースセッションをすべて終了させたところ、discourse データベースを削除できるようになりました。
現在、./launcher rebuild app の手順を再度実行中です。結果が分かり次第、また報告します。
./launch rebuild app は機能しませんでした。そこで、次に以下を行いました：
その後：
Building app
WARNING: We are about to start downloading the Discourse base image
This process may take anywhere between a few minutes to an hour, depending on your network speed
Please be patient
Unable to find image ‘discourse/base:2.0.20200220-2221’ locally
エラーなしで再構築と起動を行っても、まだ動作しません。
そのため、LETSENCRYPT オプションを無効にして再度試みました：
* Optional email address for Let's Encrypt warnings? (Enter 'OFF' to disable.) []: OFF
しかし、依然として数時間前に破壊したインスタンスが構築されています。そのインスタンスでは複数のテーマをインストールしていたため、```discourse``` DB を ```drop``` した後でも、このビルドにはそれらのテーマがそのまま残っています：
Start compiling CSS: 2020-03-15 10:16:20 UTC
```discourse``` 全体を削除し、すべての Docker イメージとコンテナを削除し、```rm -rf /var/discourse``` でディレクトリを削除してゼロから再構築しても、なぜ数時間前に削除しようとしたビルドからインストールされたすべてのテーマがまだ表示されるのでしょうか？
新規インストールではこれは理にかなっていません。
さて、やり直して LETSENCRYPT テンプレートとメールオプションをコメントアウトし、正しく再ビルドできるようになり、お祝い管理者ログインページが表示されるようになりました。
進歩です！
次に、app.yml を編集して SSL を再度有効にしてみます。
さて、それは興味深いですね…
SSL（LETS ENCRYPT）を有効にしてアプリを再構築すると、2 つの異なるサイトが表示されます…
HTTP: 予想通り新しいサイト
HTTPS: 古い壊れたサイト
うーん。これは本当に不可解です！
ビルドのたびに、以下のようにすべての古い Docker イメージなどを削除していました。
docker system prune -a
したがって、Docker イメージの問題ではありません。
問題は LETSENCRYPT の SSL 証明書に関連していると考えています。同じサーバー IP 上でビルド処理中にサブドメインを変更し、新しい SSL 証明書を生成すると正常に動作しますが、元のサブドメインに戻ると問題が再発します。
そのため、一時的に問題のあったサブドメイン（もともとステージング用ドメインでしたが）の使用を中止し、他の対応に移りました。
ご提案いただきありがとうございました。
お気をつけて。
pfaffman
2020 年 3 月 15 日午後 3:26
12
ただし、未使用の画像のみが削除されます。実行中のコンテナがないことを確認しましたか？
Stephen
2020 年 3 月 16 日午前 2:56
13
複数のコンテナをお持ちのようですね。containers フォルダには app.yml 以外のファイルはありますか？
docker psを実行すると、実行中のコンテナが1つだけ表示され、/var/discourse/containers には app.yml ファイルが1つしか存在しません。
とはいえ、素晴らしいアイデアをありがとうございます！
本当に感謝しています。