我把 SaaS 从 Docker 迁移到 Rootless Podman：三个月踩坑实录

📌 一句话摘要

本文作者分享了将 SaaS 产品底层容器架构从 Docker 迁移到 Rootless Podman 的三个月实战经验，详细记录了端口绑定、Volume 挂载权限和 Compose 兼容性等核心踩坑过程与解决方案，并总结了迁移后的实际收益与个人思考。

📝 详细摘要

文章以第一人称视角，详细记录了作者将 SaaS 产品 GoPanel 的底层容器架构从 Docker 迁移到 Rootless Podman 的完整过程。作者首先阐述了迁移动机：Docker Daemon 的 Root 权限在多租户 SaaS 场景下存在安全风险，而 Rootless Podman 的普通用户运行模式、无守护进程架构以及与 Systemd 的原生集成更具吸引力。随后，文章重点剖析了迁移过程中遇到的三个核心坑：Rootless 模式下无法绑定 1024 以下端口（通过修改内核参数解决）、Volume 挂载因 UID 映射机制导致的权限错乱（通过 --userns=keep-id 和 SELinux 标签 :Z 解决）、以及从 Docker Compose 到 Podman 的兼容性问题（推荐使用 podman play kube 对接 Kubernetes YAML）。最后，作者分享了迁移后的实际收益，包括内存占用下降和与 Systemd 的深度集成带来的管理便利性，并坦诚地介绍了其项目 GoPanel 对 1Panel 的借鉴以及未来的架构规划。文章末尾还附带了作者的个人经历归档项目链接。

💡 主要观点

- 迁移动机源于 Docker Daemon 的 Root 权限在多租户 SaaS 场景下的安全风险。 Docker Daemon 以 Root 运行，成为高价值攻击目标。Rootless Podman 以普通用户身份运行容器，即使容器内拥有 Root 权限，在宿主机层面也只是一个普通用户，提供了更好的隔离性。

Rootless Podman 的三大核心坑：端口绑定、Volume 权限、Compose 兼容性。 普通用户无法绑定 1024 以下端口，需修改内核参数；Volume 挂载因 UID 映射机制导致权限错乱，需使用 --userns=keep-id 并注意 SELinux 标签；Docker Compose 在复杂网络场景下兼容性不佳，推荐使用 podman play kube。

迁移后的核心收益是资源利用率提升和与 Systemd 的深度集成。 在约 50 个轻量服务的测试环境中，观察到内存占用有一定幅度下降。Podman 可直接生成 Systemd 服务文件，实现自动重启、开机启动和异常恢复，管理模型更干净。

💬 文章金句

- Docker 的核心架构依赖 Docker Daemon 。Docker Daemon 通常以 Root 权限运行。对于多租户 SaaS 场景来说，它天然会成为一个高价值目标。

Rootless Podman 最大的特点之一就是：容器可以完全以普通用户身份运行。即使容器内部拥有 Root 权限。在宿主机层面，它依然只是一个普通用户。
Podman 本身没有中心化守护进程。容器本质上就是普通 Linux 进程。整个运行模型更加接近 Linux 原生系统。

📊 文章信息

AI 初评：84

来源：V2EX

作者：olddogs

分类：软件编程

语言：中文

阅读时间：8 分钟

字数：1831

标签：容器化, Docker, Podman, SaaS, 后端开发

阅读完整文章

我把 SaaS 从 Docker 迁移到 Rootless Podman：三个月踩坑实录

🤖 問 AI