嗯…… 
脚本甚至不需要访问 /var/discourse（为什么需要？！）。
整个问题源于几件事：
- 对 docker 是什么、它是如何工作的以及它提供了什么功能存在巨大的误解
- 将 docker 和 docker-compose 的概念混为一谈（它们不一样！）
你可以拥有一个完全隔离的设置，它几乎不接触主机环境……
经过大量的研究，似乎整个“设置”脚本是为了让非常不熟悉技术的人能够尽可能简单地进行安装而创建的。它会进行检查，指导用户并设置好一切。这可能是一件好事，但它在任何试图偏离设想路径哪怕一丁点的情况下都会完全失效。
在最基本的设置中，你甚至可能不需要访问任何主机目录——所有内容都将包含在有限的环境中（镜像将用于创建容器，所有必需的存储都将通过 docker 卷处理 [当你想要迁移到其他地方或访问文件时会存在问题，但我们现在讨论的是基础知识]）。
它还试图确保 DNS 正确，尝试设置证书、反向代理、SMTP 等等——同样，提供这种简单的设置是完全没问题的。
但是！
问题不在于放弃这些，而是 另外 提供一个纯粹的 docker 镜像（它已经存在了，脚本和脚本使用的模板都在使用它！discourse_docker/templates/postgres.template.yml at main · discourse/discourse_docker · GitHub 和 discourse_docker/launcher at main · discourse/discourse_docker · GitHub
- 正确的版本控制：将镜像标记为已发布的 discourse 版本（3.4.5 或其他）
- 对预期的环境变量（驱动数据库/redis/etc 连接）以及可以挂载到主机的可能路径/卷的合理、简单的文档。
仅此而已……
看看上面提到的 miniflux 指南：Miniflux Installation with Docker - 它提供了关于镜像（以及哪些仓库提供它们）和可配置的环境变量的详细信息。
或者 MySQL docker 镜像：https://hub.docker.com/_/mysql - 同样 - 提供了一个解释可配置内容的指南（特别是查看“环境变量”部分）。
没有人会说：“你必须使用 mysql 启动器来构建 mysql 镜像才能使用它”，或者 Redis 也是如此——在这种情况下，你只需使用现有的镜像，这就是使用 docker 的关键和要点。然而，在 discourse 的情况下，突然之间这变成了一个“坏”的解决方案，每个人都在喊：“你必须构建自己的镜像！”——为什么？！