对 Podman 感兴趣吗？

开发
20

我花了一个半小时左右尝试了一下。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。

podman build 文档指出：

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 技术栈常规管理的人，可能会发现这是一项中等难度但相对容易的工作。如果我知道所有需要完成的工作内容，我就能更好地判断这是否属于那种容易“腐烂”并需要持续维护的工作。但是……我不知道。:roll_eyes: