People,
I know Discourse has standardised on Docker for distribution and support but it seems to me there are some reasonable arguments for also making Discourse available as a Podman container? I would be happy to have a go at producing something if at least one clued-up dev was prepared to help me . .
Regards,
Phil.
It is unlikely we can spend any time on it, but if you want to give it a go, go for it.
Thanks for the fast reply Jeff!
I will see if I can get some enthusiam going from the appropriate Fedora group . .
@codinghorror , Can you point me to a HOWTO for a completely manual install somewhere? - I have some familiarity with Rails etc . .
Here are the instructions: Beginners Guide to Install Discourse on Ubuntu for Development.
If you look at the install script in the Install Discourse Dependencies section of the guide, you’ll find the manual instructions there.
Thanks!
I will check it out . .
Docker 在 RHEL 8 中已被 Podman 取代。
为了留住 RHEL（以及 CentOS）客户，开始支持 Podman 安装似乎是顺理成章的选择。
根据 Podman 官网 的说法：
简单来说：‘alias docker=podman’
这体现了其与 Docker 的高度互操作性。
投资回报率看起来不错？
由于推荐的安装方式并不使用仓库提供的 Docker 包，因此我认为这无论在哪种情况下都不是一个需要考虑的问题。
只要 Docker 官方不取消对某个发行版的支持，我们就没问题。
我不太清楚支持 Podman 需要多少工作量，但我觉得企业客户并不喜欢“大概没问题”这种支持级别。
如果你运行的是 RHEL（CentOS）8 及以上版本，就必须从外部仓库安装 Docker，可能与 Podman 并存，而 RedHat 不会支持这种用例；或者你可以直接用 Podman 安装 Docker 镜像，但这也不受 Discourse 支持。
希望它能获得官方支持。
我认为随着 CentOS 8 的发布，这个问题会受到更多关注。
Docker 已原生支持 CentOS 8，并因此也支持 RHEL 8。我不清楚有什么场景需要同时运行两者，我是否遗漏了什么？
说 Docker 已被 Podman 取代可能并不准确，更准确的说法是 Podman 现已作为默认工具随系统提供。毕竟，谁会使用发行版自带的 Docker 版本呢？
支持责任一直由 Docker 承担，而非 Red Hat。如上所述，建议始终是使用 Docker 包，而非发行版自带的版本。
实际情况恰恰相反，但链接到的 RedHat 页面指出：
Red Hat 并未为 Red Hat Enterprise Linux (RHEL) 8 提供或支持
docker软件包。
podman容器引擎已取代docker，成为 Red Hat Enterprise Linux 8 系统的首选、受维护且受支持的容器运行时。
我并未将此解读为 RedHat 对 Docker 提供了“支持”。
如果这意味着放弃对 RHEL 客户的支持，那是 Discourse 自己的选择。
查看 Docker 仓库，他们不提供 RHEL 软件包，仅提供 CentOS 软件包。
Podman 旨在与 Docker 100% 兼容，因此我真的不确定我们是否需要做任何事情。
或许可以稍微编辑一下安装文档，添加一个关于 Podman 安装的参考（例如，只需说明它受支持，并在文档开头提示将命令 docker 替换为 podman），这样人们就不会疑惑它是否受支持了？
在我们测试完成之前，我们不会采取任何明确的立场。
据我所知，人类历史上从未有人尝试过使用 Podman 安装 Discourse。
我认为这里存在一些误解。我们了解 Podman，团队中的许多人也支持它取得成功，因为这对整个自由开源软件（FOSS）生态系统都有好处，但是：
它并不受支持。
我们的托管服务使用的是 Ubuntu / Debian。因此，我们目前没有运行 RHEL 的客户。
即使它被证明在当前状态下可以正常工作，我也会对任何关于支持的提法持非常谨慎的态度。
除非 Docker 放弃 CentOS/RHEL，否则这是不必要的；即使这种情况发生，Discourse/Docker 也不会是第一个在发行版层面有特定要求的应用程序。
这里最让我感到沮丧的是，猜测的内容与实际完成的工作量之间的巨大差距。
如果你一开始就这样说，我的反应会完全不同：
过去 30 天我一直在 Podman 上使用官方的 Discourse Docker 安装方案，以下是我发现的一些小问题，以及我对这个设置的喜爱之处！
这里的整个前提似乎是：为我们干活，我不愿意尝试，也不愿意做任何工作，这对你和社区来说将是一个大问题。
我非常不喜欢这种做法。
这很好地概括了我的回应。我们这里使用的是可预测的技术，没有必要也没有空间发表末日预言。
我也不太喜欢这种来回争论，本应该忍住不说话，而不是参与进来。
说这句话时，我原本以为你需要做一些额外的工作才能让功能正常运行。但如果它本应做到 100% 兼容，而只需替换一条命令即可，那倒是很不错。
我的建议是，你可以为那些因使用 Podman 而非 Docker 而陷入困惑的用户提供指引。
我不太清楚你们的具体开发模式，但我想这应该是一个由社区驱动的模式，用户需要先自行尝试解决问题。
我花了一个半小时左右尝试了一下。Podman 在命令层面兼容，但在输出层面不兼容，因此当 launcher 尝试解析输出时会感到困惑。（区分它们并不难，docker --version 的回复是 podman version 1.0.5，所以这并非严重障碍。）
不存在 docker0 网络设备。Podman 中默认的 overlay 存储驱动程序基本上是 overlay2 的实现，并与其别名，但输出中并未显示 overlay2，且 docker info 命令的输出略有不同。我使用了 --skip-prereqs 来绕过检查。共享目录未自动创建；我尚未调查原因。我运行了 mkdir -p /var/discourse/shared/standalone/log/var-log 以继续操作。接下来，我遇到了权限问题，原因是 SELinux 处于强制模式但未针对 /var/discourse 进行配置。
如果您将目录卷挂载到容器中，并添加 :z 或 :Z，容器引擎会将卷下的内容重新标记为
container_file_t。
z选项告诉 Podman 两个容器共享卷内容。因此，Podman 会使用共享内容标签对内容进行标记。共享卷标签允许所有容器读取/写入内容。Z选项告诉 Podman 使用私有非共享标签对内容进行标记。只有当前容器可以使用私有卷。
我决定暂时在此临时安装上执行 我将 setenforce 0，稍后再处理。volumes 更改为使用小写的 :z，如下所示：
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared:z
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log:z
经过这些小幅修改，我成功启动了 Discourse。Redis 对内核支持透明大页表示不满，建议禁用该功能，并更改内存超分设置。在兆字节的日志输出中，可能还有很多其他有用的调试信息被我略过了！
./launcher start app
...
--restart 选项不受支持。
请使用 systemd 单元文件来重启容器
我修改了脚本以不使用 --restart，并发现 start 模式也需要 --skip-prereqs，这最终让我尝试执行 docker run，此时出现：
./launcher start app --skip-prereqs
...
+ /usr/bin/docker run ... -e DOCKER_HOST_IP= --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared:z -v /var/discourse/shared/standalone/log/var-log:/var/log:z --mac-address 02:9c:01:9b:0e:17 local_discourse/app /sbin/boot
--mac-address 选项目前不受支持
因此，它肯定无法开箱即用，而我也不知道需要多少工作量来修复 launcher 以使其兼容 Docker 或 Podman。处理前置条件检查将“自动完成”，并且通过预先检查 Podman 可能并不太难，但我不知道关于网络设置的假设深入到了配置栈的哪个层面，而且看起来这种网络模式根本不受 Podman 支持。
基于这一顾虑，我计划不投入精力使 launcher 在 Podman 下运行。我只是报告初步快速实验的结果。
话虽如此，对于更了解该技术栈的人来说，这项工作可能并不困难。今年春天，我所有的开发工作都是在 Fedora 29 上进行的手动开发安装，只需进行一些微不足道的调整，例如使用 dnf 代替 apt-get，以及一些包名称的轻微转换，完全不使用 Docker 或 Podman。我预计，既精通 Podman 又熟悉整个 Discourse 技术栈常规管理的人，可能会发现这是一项中等难度但相对容易的工作。如果我知道所有需要完成的工作内容，我就能更好地判断这是否属于那种容易“腐烂”并需要持续维护的工作。但是……我不知道。