这是我在多次完美的 Discourse 安装和迁移后仍然无法解决的问题。
背景：
我们之前在一个 Docker 容器中顺利运行 Discourse，当时正在处理一些 PostgreSQL 数据库的细微问题。
问题出在我们对重新烘焙（rebaking）原始帖子的结果不满意，导致一切都不按计划进行。于是我们决定删除 postgres DB 并重新创建它；但应用程序不断出现各种权限错误等问题。
随后，我们决定“彻底一点”，以一种“管它呢”的方式直接动手；我们直接进入 postgres（明知这可能行不通，但还是想试试），从数据库中删除了所有 topics 和 posts（DELETE FROM topics; DELETE FROM posts;）。这稍微有点效果，但我们对结果仍不满意（实验结束），于是决定从头重建 Discourse，将旧的 /var/discourse 移走，然后从 git 拉取代码重新开始。
问题所在
当我们从 git 拉取代码并完全 new 构建时，构建过程本身一切正常，直到我们访问网站创建管理员登录账户时出了问题。
当我们尝试为新安装设置管理员登录时，看到的竟然是我们之前已销毁的旧网站！这让我们非常惊讶。
于是我们决定进入这个新应用，尝试从数据库中删除所有 Discourse 相关的表，我们也确实这么做了；但令人惊讶的是，当我们再次重建应用时，它并不是一个全新的站点，而是上面提到的那个损坏的旧站点。
接着，我们删除了所有 /var/*discourse* 目录，并移除了所有 Docker images，以为这样就能实现 彻底干净 的状态，然后再次从 git 拉取到 /var/discourse，并以为是从 完全从零开始 构建；但令人惊讶的是……旧网站依然存在。
我们不禁疑惑：“这怎么可能？？”
我们在 Docker 容器外部执行了 ps aux | grep postgres，发现 postgres 进程实际上存在于容器之外（这让我们很惊讶，因为我们错误地认为 Discourse Docker 安装 的所有内容都在容器内部）；于是我们尝试寻找清理的方法，但一无所获。
我们搜索了无数遍，连 Google 链接都变紫了，尝试了各种方法……却始终无法获得一个干净的 discourse 安装。
我们怀疑自己可能漏掉了什么，于是换到一台 从未安装过 Discourse 的新服务器上，从头安装 discourse，结果一切顺利，和往常一样（另一台服务器）。
问题
我的问题是：当一个安装彻底失控（无论通过何种方式）时，我们该如何将整个服务器（包括 postgres）恢复到初始状态，从而彻底解决该问题，并实现一个完全全新的安装？
抱歉写了这么长一篇，其实可能只需要 问题 部分就足以获得帮助了。
谢谢。
尝试删除数据库时，我不断收到此权限错误：
/var/www/discourse# su postgres -c 'psql'
psql (10.12 (Debian 10.12-1.pgdg100+1))
输入“help”以获取帮助。
postgres=# drop database discourse;
错误：数据库“discourse”正被其他用户访问
详情：有 3 个其他会话正在使用该数据库。
有什么线索吗？
pfaffman
(Jay Pfaffman)
5
我最大的猜测是，您并没有删除正在运行的 Docker 容器，但您声称已经删除了镜像。而且，您似乎应该会得到其他提示。
或者，您使用的是外部 PostgreSQL，而不是容器中的那个？
通常，删除 /var/discourse/shared 目录并重新构建即可解决问题。
谢谢。
我们刚刚终止了所有之前的 discourse 数据库会话，这让我们得以删除 discourse 数据库。
现在再次执行 ./launcher rebuild app 操作。稍后我会回来汇报结果。
./launch rebuild app 未生效；因此我们接下来采取了以下操作：
随后：
正在构建 app
警告：即将开始下载 Discourse 基础镜像
此过程可能需要几分钟到一小时不等，具体取决于您的网络速度
请耐心等待
Unable to find image ‘discourse/base:2.0.20200220-2221’ locally
2.0.20200220-2221: Pulling from discourse/base
bc51dd8edc1b: Pulling fs layer
27ae5d171719: Pulling fs layer
bc51dd8edc1b: Download complete
bc51dd8edc1b: Pull complete
27ae5d171719: Verifying Checksum
27ae5d171719: Download complete
27ae5d171719: Pull complete
blah blah…
blah blah…
blah blah…
即使在不报错的情况下重新构建并启动，问题仍未解决。
因此，我们再次尝试，关闭 LETSENCRYPT 选项：
* Optional email address for Let's Encrypt warnings? (Enter 'OFF' to disable.) []: OFF
但系统仍在构建之前（数小时前）已销毁的实例，因为在该实例中我们安装了多个主题，即使我们 ```drop``` 了 ```discourse``` 数据库，这些主题仍然保留在此次构建中：
开始编译 CSS：2020-03-15 10:16:20 UTC
正在为默认主题编译 CSS 2020-03-15 10:16:20 UTC
预编译目标：桌面 深色
预编译目标：移动 深色
预编译目标：桌面 rtl 深色
预编译目标：移动 rtl 深色
预编译目标：桌面主题 深色
预编译目标：移动主题 深色
预编译目标：管理后台 深色
预编译目标：桌面 浅色
预编译目标：移动 浅色
预编译目标：桌面 rtl 浅色
预编译目标：移动 rtl 浅色
预编译目标：桌面主题 浅色
预编译目标：移动主题 浅色
预编译目标：管理后台 浅色
预编译目标：桌面
预编译目标：移动
预编译目标：桌面 rtl
预编译目标：移动 rtl
预编译目标：桌面主题
预编译目标：移动主题
预编译目标：管理后台
CSS 编译完成：2020-03-15 10:16:27 UTC
在我们已删除整个 ```discourse``` 数据库、清除所有 Docker 镜像和容器、删除 ```rm -rf /var/discourse``` 并从零开始重新构建的情况下，为什么仍然能看到数小时前我们试图彻底销毁的构建中所安装的所有主题？
这在一次全新安装中完全说不通。
好的，我们重新开始，注释掉了 LETSENCRYPT 模板和邮件选项，成功重新构建并进入了庆祝管理员登录页面。
有进展！
现在将编辑 app.yml，尝试重新启用 SSL。
好吧。这很有趣……
如果我启用 SSL (LETS ENCRYPT) 重新构建应用，会得到两个不同的站点……
- HTTP：按预期显示新站点
- HTTPS：显示旧的损坏站点
嗯……这真让人困惑！
每次构建前，我们都会执行以下操作清除所有旧的 Docker 镜像等：
docker system prune -a
因此，问题并非出在 Docker 镜像上。
我们认为问题与 LETSENCRYPT SSL 证书有关：因为当我们在同一服务器 IP 上更改子域名并在构建过程中生成新的 SSL 证书时，一切正常；但当我们换回原始子域名时，问题依然存在。
因此，我们暂时不再使用这个有问题的子域名（它本来也只是一个测试域名），并已转向其他方案。
感谢大家的建议。
祝一切平安。
pfaffman
(Jay Pfaffman)
12
但这只会删除未使用的镜像。你确定没有正在运行的容器吗？
Stephen
(Stephen)
13
听起来你有不止一个容器——你的 containers 文件夹里除了 app.yml 还有其他文件吗？
docker ps 仅显示一个正在运行的容器，且 /var/discourse/containers 中只有一个 app.yml 文件。
不过，非常感谢大家的好主意！
非常感激。