我们组织运营着一个 Web 应用和一个论坛，还有一些其他应用（如 Bitwarden）。为了实现开发与生产环境的一致性（dev/prod parity）并简化开发流程，我已将所有服务容器化，并使用 Docker Compose 进行编排。我们在生产环境中使用非常相似的 Compose 文件来运行这些服务，对于我们的基本需求来说效果很好。
现在我想将论坛迁移到 Discourse，但正在努力寻找如何维持开发与生产环境的一致性，同时保持开发流程的简洁性。
官方文档指出，尽管 Discourse 使用 Docker 进行安装和运行，但它并不像其他 Docker 容器那样完全符合容器化范式：你无法将其添加到 Compose、Swarm 或 Kubernetes 堆栈中，像运行其他应用容器那样将其与数据库和 Redis 容器连接起来。官方也不鼓励采用替代方案或提出建议，以避免社区分裂，因此我并非要质疑这一做法。
我已经接受这样一个事实：与运行和管理我堆栈中的其他服务不同，在生产环境中我将需要运行一台专用的虚拟机，并以不同的方式对其进行管理。但我仍然好奇如何实现我的核心目标：一个简单且与生产环境具有良好一致性的开发设置。
作为背景说明，我目前的开发流程是：“安装 Docker，克隆代码库，然后运行 docker-compose up”。根据 本地安装指南，我们现在需要先在系统上安装 9 个依赖项（如 Ruby、PostgreSQL 等），然后才能手动克隆并配置 Discourse 本身。在我看来，Docker（以及 Docker Compose）的一大优势就是无需在系统上运行 PostgreSQL 和 Redis 等服务（也避免了 Windows 开发者在配置这些服务时遇到的问题）；只需运行一个堆栈，所有进程都会被隔离在临时容器中。是否有任何方法可以保留这一优势？
另一个问题是，由于我们是一个由志愿者组成的小团队，大多数其他开发者使用的是 Windows 10 家庭版。据我所知，该版本不支持 WSL，因此他们无法按照 Windows 安装指南进行操作（尽管 Docker 本身可以在 Windows 10 家庭版上运行）。