1. 从“能跑”到“敢用”：第四篇要啃的硬骨头
Podman 容器这类无守护进程的工具，前面三篇基本把“入门到能跑”这条路铺完了：安装、仓库配置、镜像拉取、podman run 的常用参数、Pod 概念的初探、和 docker 命令的对应关系。真正把它放进一台需要长期稳定运行的机器上，问题才刚开始。我见过不少团队，演示环境里 podman run -d 一敲，网页能打开，就认为迁移完成了；等到机器重启、磁盘写满、同事离职、要升级镜像版本的时候，才发现容器没起来、日志找不到、数据卷权限是 root 的、改都改不动。
第四篇就干这一件事：把 Podman 从“命令行里的一次性玩具”变成“开机自启、故障自愈、可被审计的系统服务”。围绕这条主线，会拆四块内容：Rootless 模式下 UID 映射的底层账本、Quadlet 把容器注册成 systemd 服务的完整流程、buildah 与 podman build 的构建链路取舍、以及网络和存储在生产里最容易翻车的组合场景。最后再给一份排障速查表和几个真实踩坑复盘。
1.1 前三篇停在哪，第四篇补什么
回顾一下常见的学习路径：第一篇讲原理与安装，第二篇讲镜像与容器生命周期命令，第三篇讲 Pod、卷和基础网络。到这里，读者的典型状态是“单个容器能跑，但心里没底”。没底的地方具体有三处。
第一处是权限。rootless 模式是 Podman 的核心卖点之一，可很多人只是把命令前面加了个 sudo 就绕过去了，根本没用上 rootless。一旦真用普通用户跑起来，就遇到文件属主变成 100999、端口 80 绑不上、SELinux 拒绝访问。这些不是 bug，是用户命名空间和标签机制在按规则办事，规则没搞懂就寸步难行。
第二处是进程托管。podman run -d 起的容器，父进程是你的 shell 会话。SSH 一断、机器一重启，容器就没了。restart=always 在 docker 里是标配，Podman 因为无守护进程，压根没有全局的 restart 策略，它必须交给 systemd 来管。
第三处是构建与升级链路。镜像怎么来、怎么打标签、怎么在 rootless 下构建、怎么让 systemd 自动拉新版本。这几件事串不起来，就永远只能手动 docker pull 加手动重启，出事只是时间问题。
第四篇的定位就是补这三处，让整套东西能交付给别人维护。
1.2 本篇的三条主线与前置条件
写作的时候我刻意按三条主线组织，读者可以挑着看，但建议按顺序过一遍，因为后面依赖前面的结论。
主线一是权限与命名空间：搞清楚 rootless 下容器内的 root 到底是谁、subuid 怎么分配、网络包怎么出去的。这条线决定了你后面所有操作会不会被 EACCES 和 EPERM 拦住。
主线二是服务化：用 Quadlet 写声明式文件，让 systemd 生成 service，实现开机自启、崩溃重启、日志归集。这条线是本文最实用的一段，照着抄就能用。
主线三是构建与运维：镜像怎么自己造、怎么瘦身、怎么滚动升级。这条线决定了这套东西能不能长期活下去。
前置条件说清楚：主机建议用较新的发行版内核（5.10 以上会更省心），Podman 版本至少 4.4 以上，因为 Quadlet 在 4.4 才正式进入，4.5 和 4.6 逐步补齐了 .pod 引用、AutoUpdate 等能力。版本低于这个线，建议先升级，否则本文里的文件格式会有兼容问题。检查版本很简单：
podman --version podman info --format '{{.Host.Security.Rootless}}' systemctl --user --version | head -1第二条命令返回 true 说明当前是 rootless 会话。如果返回 false 而你又是普通用户，那说明你其实在用一个 rootful 的远程连接，别被误导了。
2. Rootless 的底层账本：普通用户凭什么能玩转容器
很多人对 rootless 的理解停留在“不用 sudo”，这太浅了。真正的问题是：容器里的进程自认为是 root，能读写 /etc/passwd，能 chown 文件，它凭什么在宿主机上只是一个普通用户？答案是 Linux 的用户命名空间，它给进程提供了一套“局部视角的 UID 世界”。
2.1 User Namespace 与 UID 映射的真实机制
创建一个用户命名空间时，内核允许进程在里面拥有一整套独立的 UID/GID 编号空间，同时维护一张映射表，把命名空间内的 ID 换算成宿主机的真实 ID。Podman 在 rootless 模式下做的第一件事就是调用 clone(CLONE_NEWUSER)，然后往 /proc/self/uid_map 里写映射规则。
默认规则大致是这样：容器内的 UID 0 映射到宿主机上启动 Podman 的那个普通用户，比如 UID 1000；容器内的 UID 1 到 65535 映射到宿主机 subuid 区间，比如 100000 到 165535。于是容器里的 root 在宿主机眼里就是 UID 1000，它去 chown 一个文件，宿主机上看到的是把文件属主改成 1000 或者其他从属 UID，绝不会真的动到系统的 root。
这套机制带来的直接后果是：容器内进程无法真正提权到宿主机的 root。就算容器里的程序有提权漏洞，它拿到的也只是命名空间内的 root，在宿主机上仍然被普通用户的权限约束着。这是 rootless 的安全价值所在，也是很多人第一次用会觉得“怎么啥都干不了”的原因。
另一个容易被忽略的点是文件属主显示。你在宿主机上用 ls -l 看容器写出来的文件，属主是一串陌生的数字，比如 100999。这不是错误，就是 subuid 换算后的结果。想正常查看和操作这些文件，需要用 podman unshare 进入同一个命名空间：
podman unshare ls -l /path/to/data podman unshare chown -R 33:33 /path/to/datapodman unshare 的本质是“给我一个和容器相同的用户命名空间再执行命令”。这条命令在排查卷权限问题时使用频率极高，记住它比记住一堆参数有用得多。
注意：不要在宿主机上直接用 sudo chown 去改容器写出来的文件属主。改了之后容器内的映射关系就对不上了，表现出来就是容器启动时报 Permission denied，而且很难第一时间联想到是属主被手动改过。
2.2 subuid 与 subgid：最容易翻车的一步
用户命名空间能映射多少 ID，完全取决于 /etc/subuid 和 /etc/subgid 这两个文件。它们的内容格式是 用户名:起始ID:数量，比如：
alice:100000:65536意思是给 alice 分配从 100000 开始的 65536 个从属 UID。新建用户时，多数发行版的 useradd 会自动写入这一行，但也有例外。容器启动时报Error: cannot find mappings for user alice或者newuidmap: write to uid_map failed，八成就是这里缺了。
检查方式很直接：
grep "$(id -un)" /etc/subuid /etc/subgid如果只输出一行或者干脆没输出，就需要手工补。补的时候有个关键细节：同一个用户在多行里重复出现，内核会取交集或者直接报错，所以改之前先看清楚有没有历史遗留。补完不需要重启，新起的进程立即生效。
还有一个更隐蔽的问题：newuidmap 和 newgidmap 这两个辅助程序的 setuid 位必须存在。它们负责在创建命名空间时写入映射表，普通用户没有 CAP_SETUID 权限，只能靠这两个带 setuid 位的程序代为执行。某些安全加固脚本会把 setuid 位批量清掉，结果就是 Podman 起容器失败但报错信息语焉不详。检查一下：
ls -l /usr/bin/newuidmap /usr/bin/newgidmap正常应该是 -rwsr-xr-x，带 s 位。丢了就用包管理器重装 shadow-utils 或 uidmap 包来恢复，别手贱 chmod 4755 了事，不同发行版的属主可能不一样。
提示：从属 UID 的数量决定了你能在容器里用多少个不同的 UID。如果容器里要跑一批不同属主的服务（比如同时跑多个用户身份的进程），65536 可能不够分，可以在 /etc/subuid 里把数量调大，但要保证各用户之间的区间不重叠。
2.3 rootless 网络栈：包是怎么出去的
rootful 模式下 Podman 用 netavark 或 CNI 创建 bridge 网络，veth 对一头插在网桥上，走的是内核标准转发。rootless 模式下没法创建网桥，因为那需要 NET_ADMIN 权限。早期方案是 slirp4netns，在用户态做 TCP/IP 协议栈转换，把容器的网络请求通过 socket 转发给宿主机进程。
现在的默认通常已经换成 pasta，它的思路不同：不新建网络接口，而是把宿主机上的网络能力“借用”给命名空间，直接从宿主机接口拿到路由和地址，性能比 slirp4netns 好不少，尤其是大流量场景。可以在创建容器的参数里显式指定：
podman run -d --network pasta:--map-gw -p 8080:80 nginx podman run -d --network slirp4netns:allow_host_loopback=true nginxslirp4netns 的 allow_host_loopback 很有用，它让容器能访问宿主机的 127.0.0.1 服务，做本地联调时很方便；代价是容器也能访问宿主机上的所有本地服务，安全上要掂量。
端口映射是另一个热点。rootless 下想映射 80 端口到宿主机，普通用户没权限绑定 1024 以下端口，于是 Podman 用一个 rootlessport 辅助进程，由它来监听端口再把流量转进容器。这个进程是 podman 命令的子进程，所以容器的生命周期必须和 podman 进程绑定。这就解释了为什么 rootless 下不能简单地“脱离 shell 后台运行”，必须交给 systemd。
如果确实想让普通用户绑定低端口，有两个路子。一是调整内核参数：
sudo sysctl -w net.ipv4.ip_unprivileged_port_start=0把非特权端口起点拉到 0，普通用户就能绑 80 了。这属于系统级改动，影响所有用户，落盘需要写 /etc/sysctl.d/ 下的配置文件。二是干脆在宿主机上用高端口，前面用反向代理转发。我个人更倾向第二种，改动面小，也便于统一管理。
2.4 存储驱动选择：overlay、fuse-overlayfs 与性能取舍
镜像分层需要联合文件系统。rootful 下直接用内核 overlay2 就完事，rootless 下情况复杂：内核 overlay 驱动在不带 CAP_SYS_ADMIN 的用户命名空间里，早期是不被允许的。Podman 的应对是内置 fuse-overlayfs，一个在用户态实现 overlay 语义的驱动，靠 FUSE 挂载。
新版本内核（大约 5.11 之后）开始支持在用户命名空间里使用原生 overlay，Podman 会自动检测并优先使用。所以同一台机器上，不同用户的存储驱动可能不一样。查一下就知道：
podman info --format '{{.Store.GraphDriverName}}'输出 overlay 说明走的是内核路径，性能最好；输出 fuse-overlayfs 说明走的是用户态路径，功能齐全但 I/O 有额外开销，大量小文件读写会明显慢。如果看到 vfs，那是最差的情况：每一层都完整拷贝一份，磁盘占用和启动时间都会很难看，只适合排查问题时临时用。
驱动选择可以写在 ~/.config/containers/storage.conf 里，但我不建议手动改，除非你有明确的性能诉求并且做过对比测试。默认策略已经是“能用原生就用原生，不能用就降级”，人为干预容易踩到版本兼容问题。
真正需要关注的是磁盘空间。rootless 的镜像和容器数据默认存在 ~/.local/share/containers/storage 下，属于用户家目录。如果家目录分区很小，跑几个镜像就满了，容器启动失败报 no space left on device。我的做法是单独挂一块盘，把 storage.conf 里的 graphroot 指过去，并在迁移数据时用 podman system migrate 让 Podman 重新初始化存储，而不是手工 mv 目录。
3. Quadlet 实战：把容器养成一个真正的系统服务
到这一步，容器能跑了，权限也理顺了，但它还是个“手动挡”。机器一重启、进程一崩，全靠人肉恢复。要想让它像 nginx、像数据库那样被系统管着，就得交给 systemd。
3.1 为什么放弃 generate systemd
老版本 Podman 提供 podman generate systemd --new --files 命令，把运行中的容器导出成 .service 文件。这个方案能用，但用久了会发现问题不少。
第一，它要求先有一个正在运行的容器，才能生成文件，本质是“先做后描述”，不符合声明式管理的思想。第二，生成的 service 里塞了一大串 --new 和 --replace 的参数，可读性差，改起来容易出错。第三，升级 Podman 版本后生成的模板可能变化，团队里不同机器生成的 service 不一致。
从 Podman 4.4 起，官方开始推 Quadlet，把方向改成了“先写描述文件，systemd 负责生成”。你只需要写一个 .container 文件，systemd 的生成器在 daemon-reload 时自动把它翻译成 .service。它成了唯一推荐的容器服务化方式，generate systemd 逐步被弃用。
3.2 一个可复用的 .container 文件逐行拆解
先说放置位置。系统级服务放 /etc/containers/systemd/，用户级服务放 ~/.config/containers/systemd/。rootless 场景下用后者，配合 systemctl --user 操作。目录不存在就建一个：
mkdir -p ~/.config/containers/systemd下面是一个可直接抄的文件，保存为 demo-web.container：
[Unit] Description=Demo web service Wants=network-online.target After=network-online.target [Container] Image=docker.io/library/nginx:1.25 ContainerName=demo-web PublishPort=8080:80 Volume=demo-data:/usr/share/nginx/html:Z Environment=TZ=Asia/Shanghai AutoUpdate=registry HealthCmd=curl -fsS http://localhost/ || exit 1 HealthInterval=30s HealthStartPeriod=10s [Service] Restart=always TimeoutStartSec=120 [Install] WantedBy=default.target逐块说明。[Unit]段是标准 systemd 元数据，Wants 和 After 指向 network-online.target，保证网络就绪后再启动容器，避免容器启动时拉不到镜像或者连不上外网。
[Container]段是 Quadlet 的核心。Image 写完整镜像名，带上 registry 前缀，别用短名，短名不同环境可能解析到不同的仓库，升级时会出现“明明改了 tag 却没变化”的乌龙。ContainerName 固定容器名，方便 podman ps 和日志排查时对上号。
PublishPort 的写法与 -p 参数一致，冒号左边是宿主机端口，右边是容器端口。Volume 里的 :Z 是 SELinux 标签参数，在开启 SELinux 的机器上必须带，否则容器访问挂载目录会被拒绝；在没启用 SELinux 的机器上带上也无害，属于可移植写法。Environment 用 KEY=VALUE 形式，一行一个变量，多个变量写多行。
AutoUpdate=registry 告诉 podman auto-update 这个容器的镜像来自仓库，允许自动检查更新。这个参数是后续做滚动升级的基础，但要注意它只是“允许”，真正触发还得靠定时任务调用 auto-update。
HealthCmd 和 HealthInterval 是健康检查。我强烈建议加上，因为 Restart=always 只能应对进程退出，应对不了“进程还活着但服务已经卡死”的情况。配合 systemd 的自动重启策略，健康检查失败会让容器被重建。
[Service]段用来补充 systemd 原生的服务属性。Restart=always 是崩溃自愈的关键，TimeoutStartSec 给启动留足时间，避免镜像大或者首次拉取时被 systemd 判定启动超时。
[Install]段的 WantedBy=default.target 决定开机自启。用户级服务默认目标是 default.target，别照抄系统级的 multi-user.target，抄错了 enable 之后不会生效。
3.3 多容器编排：.pod、.network、.volume 的配合
一个应用很少只有单个容器。数据库、缓存、应用本体通常要一起跑，还要共享网络。Quadlet 用四种文件类型来组织：.container、.pod、.network、.volume，分别对应容器、Pod、自定义网络和数据卷。
先定义网络和卷：
# app-net.network [Network] NetworkName=app-net Subnet=10.89.0.0/24# demo-data.volume [Volume] VolumeName=demo-data Driver=local再定义一个 Pod：
# demo-pod.pod [Pod] PodName=demo-pod PublishPort=8080:80 PublishPort=5432:5432容器加入这个 Pod，只需要在 .container 里写一行：
# web.container [Container] Image=docker.io/library/nginx:1.25 Pod=demo-pod.pod注意 Pod 引用的写法，用文件名而不是 PodName。这是 Quadlet 内部依赖解析的约定，写错了文件之间就关联不上，systemd 生成顺序也会出问题。这个语法在 Podman 4.6 之后才比较稳定，版本低的话建议用容器名直接传递网络参数的方式替代。
Pod 的价值在于共享网络命名空间。同一个 Pod 里的容器共用一套 IP 和端口，互相之间用 localhost 通信，跟同一台机器上的进程没什么区别。对于“应用加本地缓存”这种强耦合组合，用 Pod 比自定义网络再互连要简单，延迟也更低。
但 Pod 也有代价：它共享的是网络命名空间，端口不能冲突，一个容器占用了 80，另一个就绑不了。而且 Pod 内所有容器同生共死，pause 容器挂了整组都没了。所以我的经验是，叫得响的微服务之间用自定义网络隔离，只有确实需要 localhost 通信的才塞进同一个 Pod。
3.4 部署、验证与升级的完整流程
文件写完不是就生效了。systemd 的生成器只在 daemon-reload 时扫描目录，所以顺序是固定的。
第一步，重载生成器：
systemctl --user daemon-reload这一步会把 .container 翻译成对应的 .service，但不会打印任何东西。想看生成了什么，可以查：
systemctl --user list-unit-files | grep demo如果这里什么都没有，说明文件放错位置了，或者语法有错。语法错误通常会在 daemon-reload 时输出到 stderr，别忽略那几行警告，它往往就是问题根源。
第二步，启动并设为开机自启：
systemctl --user enable --now demo-web.service注意服务名来自文件名，demo-web.container 对应 demo-web.service，改文件名等于改服务名，已经在跑的服务会需要重新 enable。
第三步，验证。三个动作要连做：
systemctl --user status demo-web.service podman ps curl -I http://localhost:8080status 看服务状态和最近日志，podman ps 确认容器真的起来了，curl 确认业务可用。三者缺一不可，只看 status 显示 active 而容器实际在崩溃重启循环里的情况我遇到过不止一次。
第四步，rootless 场景必做的一步，开启 linger：
loginctl enable-linger "$(id -un)"不开这一项，用户级 systemd 实例只在用户登录期间存在，退出登录后所有 --user 服务全部停止。很多人就是漏了这一步，测试时好好的，一关 SSH 就全挂了。查看当前状态用 loginctl show-user $(id -un) | grep Linger，输出 Linger=yes 才算配置成功。
第五步，升级。镜像更新后不需要手动 restart，AutoUpdate 标记的容器可以用一条命令完成检查和重建：
podman auto-update输出里会列出哪些容器被更新、哪些跳过。想让它定期跑，再加一个 systemd timer，每天凌晨执行一次。需要提醒的是，自动更新意味着版本不可控，生产环境建议先在测试机跑一轮，确认没问题再放开，或者干脆关掉 AutoUpdate，用固定的版本标签加手动发布流程，稳字当头。
4. 构建链路：buildah 与 podman build 的取舍
服务化解决了“怎么跑”，接下来是“镜像从哪来”。长期用别人的镜像总归不踏实，业务代码迟早要打包进去。
4.1 无守护进程构建的原理差异
podman build 和 docker build 的命令行几乎一样，但底层完全不同。docker build 把上下文发给守护进程，由守护进程完成构建。Podman 没有常驻守护进程，它直接调用 buildah 的库，在调用者所在的命名空间里起一个临时容器，一层层执行 RUN，构建完提交成镜像。
这个差异带来几个实际影响。第一，构建过程以当前用户身份进行，rootless 下的权限问题会原样传导到构建阶段，比如 RUN 里 apt-get install 报权限错误。第二，构建过程可见，ps 能看到中间容器，调试时可以直接 exec 进去看现场。第三，没有构建守护进程意味着没有缓存共享的全局状态，构建缓存存在用户目录下，不同用户之间不互通。
buildah 本身也是一套独立的命令行工具，它的强项是细粒度操作：bud 构建、from 创建基础容器、run 执行命令、commit 提交、mount 挂载根文件系统直接改。如果你想在构建中途改个文件再继续，buildah 能给你这个自由度，podman build 则要求你把所有步骤写进 Containerfile。
我的用法是：日常构建用 podman build，简洁；需要交互式调试镜像内容时切到 buildah，灵活。
4.2 Containerfile 写法：多阶段、非 root、缓存利用
一个能上生产的 Containerfile，至少要满足三点：体积小、不以 root 运行、构建缓存能复用。下面这个结构可以直接套：
FROM golang:1.21-alpine AS builder WORKDIR /src COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o /out/app ./cmd/app FROM alpine:3.19 RUN adduser -D -u 10001 appuser COPY --from=builder /out/app /usr/local/bin/app USER 10001 EXPOSE 8080 ENTRYPOINT ["/usr/local/bin/app"]关键点在依赖层和代码层的分离。先 COPY go.mod 和 go.sum 再 RUN 下载依赖，最后才 COPY 全部代码，这样一来改业务代码不会让依赖层缓存失效，重新构建只要几秒。这个技巧不限于 Go，Node 里先 COPY package.json 再 npm ci，Python 里先 COPY requirements.txt 再 pip install，道理都一样。
多阶段构建解决的是“构建工具留在最终镜像里”的臃肿问题。构建阶段用大镜像，运行阶段用精简镜像，最终只拷贝产物。这里要注意 COPY --from 的路径必须存在，构建阶段的产物路径写错，报错信息会指向最终阶段，很容易被误导。
USER 10001 是安全基线。容器默认以 root 运行，一旦被攻破，攻击者在容器内部就是 root，虽然 rootless 下这个 root 是映射过的，但能少一层是一层。用数字 UID 而不是用户名，可以避免不同基础镜像里用户不存在的问题。
4.3 rootless 构建的四个坑
第一个坑是 chown。Containerfile 里写RUN chown -R appuser /app，在 rootless 下可能失败，因为容器内的 chown 需要映射范围内的目标 ID。解决办法是确保目标 UID 在 subuid 区间内，或者用 COPY --chown=10001:10001 在拷贝时就带上属主，这种写法不触发 chown 系统调用，最稳。
第二个坑是缓存目录权限。构建缓存在 ~/.local/share/containers/storage 下，如果中途用 sudo 跑过一次 podman，缓存文件属主就变成 root 了，之后普通用户构建会报 permission denied。修复方式是用 podman unshare 进去把属主改回来，或者干脆 podman system reset 清空重来。所以团队里要立规矩：这台机器上所有 podman 命令统一用普通用户执行，禁止 sudo。
第三个坑是网络。rootless 构建默认走的是用户态网络栈，构建过程中拉包的速度可能比宿主机慢。可以显式指定网络模式：
podman build --network=host -t demo:1.0 .--network=host 让构建过程直接用宿主机网络，速度提升明显，代价是构建过程能看到宿主机网络，只在可信环境下使用。
第四个坑是镜像层数与体积。rootless 下如果不支持原生 overlay，走的可能是 fuse-overlayfs，每多一层就多一次 FUSE 开销，构建时间会拉长。缓解办法是合并 RUN 指令，把 apt-get update 和 rm -rf /var/lib/apt/lists/* 写在同一个 RUN 里，既减少层数也减小体积。
4.4 镜像瘦身与版本管理策略
瘦身这件事，先量后减。构建完先看一眼：
podman images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" podman history demo:1.0history 会列出每一层的大小和来源命令，哪一层最大一目了然。常见的膨胀点有：包管理器缓存没清、编译工具留在运行镜像里、测试数据被打进去、日志文件被提交。
版本管理比瘦身更重要。我的建议是打两种标签：语义版本标签（如 1.4.2）和滚动标签（如 stable）。部署文件里引用语义版本，升级时改标签再重载服务；滚动标签只用于测试环境。永远不要在生产用 latest，因为它不可预测，同一份配置文件在不同时间拉下来的镜像可能完全不同，出了事故没法回溯。
推送前顺手做个清理：
podman image prune -f podman system dfsystem df 会显示镜像、容器、卷各占多少空间。rootless 环境的磁盘配额通常比较紧，定期看一眼能避免磁盘写满导致服务异常。
5. 网络与存储的组合拳：最容易翻车的部分
服务化了、镜像有了，剩下的坑基本都在网络和存储的连接处。这两块单独看都不复杂，组合起来就出问题。
5.1 Pod 共享网络命名空间的适用边界
前面提过 Pod 共享网络，这里展开说边界。共享网络命名空间意味着同一 Pod 内所有容器用同一个 IP、同一套端口空间。好处是通信走 localhost，没有额外转发开销，适合“主应用加 sidecar”的模式，比如应用加日志采集器。
坏处是同生共死和端口冲突。Pod 里有一个看不见的基础容器负责持有命名空间，它一旦异常，整组容器都会受影响。另外主应用想监听 8080，sidecar 也想监听 8080，那就直接冲突了。所以上 Pod 之前先画一张端口分配表，确认没有重叠。
跨 Pod 通信就得走网络。定义一个自定义网络，把多个 Pod 或者独立容器接进去：
podman network create --subnet 10.89.0.0/24 app-net podman run -d --network app-net --name db postgres:16 podman run -d --network app-net --name web -p 8080:80 nginx同一网络内的容器可以用容器名互相解析，这是 Podman 内置的 DNS 能力。注意容器名要唯一，重名会导致解析异常。rootless 下自定义网络的创建不走内核网桥，靠的是用户态的实现，功能上够用，极限吞吐比 rootful 差一些，业务量大的场景要实测。
5.2 卷、绑定挂载与 SELinux 标签
存储就三件事：数据放在哪、权限归谁、标签对不对。
放数据有两种方式。用命名卷（Volume），数据由 Podman 管理，位置在存储目录下的 volumes 子目录里，隔离性好，删除容器不影响数据。用绑定挂载（bind mount），直接把宿主机目录映射进容器，方便查看和备份，但要自己保证目录存在和权限正确。
podman run -d -v demo-data:/data nginx podman run -d -v /srv/web:/usr/share/nginx/html:Z nginxSELinux 标签是这块最大的坑。开启 SELinux 的机器上，不加 :Z，容器访问绑定目录会被拒绝，日志里能看到 AVC denied 记录。:Z 表示给这个目录打上私有标签，只有当前容器能用；:z 表示共享标签，多个容器可以共用。选哪个取决于这个目录是不是被多个容器共享。
加了 :Z 之后，宿主机上 ls -Z 看目录，标签会变成 container_file_t 之类。如果之后用普通进程去读写这个目录（比如用 rsync 备份），可能反而被拒绝。备份的时候加上 --copy-links 或者干脆用 tar 加 --selinux 参数保留标签。这些细节不写进运维手册，接手的人一定会踩。
5.3 属主错乱的根治方法
数据卷里文件属主变成陌生数字，是 rootless 下最常见的困惑。根因还是 UID 映射：容器里以 uid 33 写入文件，宿主机上就显示成 subuid 起点加 33。
根治方法只有一个：所有涉及卷内文件的操作，都在同一个用户命名空间里执行。查看用 podman unshare ls，改属主用 podman unshare chown，复制文件进去用 podman unshare cp。养成这个习惯，就不会出现“容器里的服务读不到自己写的文件”这种玄学问题。
如果容器本身支持指定运行用户，更省事的做法是在 .container 文件里加一行 User=。让容器以某个明确的 UID 运行，写入的属主就固定了，配合 podman unshare 初始化一次目录属主，之后就不用再管。
[Container] User=10001:10001 Volume=demo-data:/data:Z初始化目录属主只需要做一次：
podman unshare chown -R 10001:10001 ~/.local/share/containers/storage/volumes/demo-data/_data路径不用死记，podman volume inspect demo-data 能看到实际位置。
6. 常见问题与排查技巧实录
前面讲的都是“应该怎么做”，这一节讲“做错了怎么找回来”。我把这几年遇到的典型问题整理成表，再挑几个值得展开的复盘。
6.1 排障速查表
| 现象 | 最可能的原因 | 排查动作 | 处理办法 |
|---|---|---|---|
| 服务 enable 后开机不自启 | 没开 linger | loginctl show-user $(id -un) | 执行 loginctl enable-linger |
| daemon-reload 后没有生成 service | 文件位置错或语法错 | systemctl --user list-unit-files | 挪到正确目录，看 reload 报错 |
| 容器启动即退出 | 入口命令结束或配置错 | podman logs 容器名 | 改 ENTRYPOINT 或补前台命令 |
| 绑定目录读不到 | SELinux 标签缺失 | 查看 journal 中 AVC 记录 | 挂载参数加 :Z |
| 端口映射不生效 | 端口被占用或 rootless 限制 | ss -lntp 查端口 | 换端口或调整内核参数 |
| 拉镜像超时 | 网络或仓库配置 | podman info 看 registries | 调整仓库配置或换镜像源前缀 |
| 磁盘写满无法启动 | 存储目录所在分区满 | podman system df | 清理无用镜像与卷 |
| 权限拒绝但属主看着对 | UID 映射错位 | podman unshare ls -l | 用 unshare 内 chown 修正 |
表格能覆盖大部分情况，剩下的是需要看现场的组合问题。
6.2 三个值得展开的现场复盘
第一个现场：某次迁移后，容器能起但健康检查一直失败，systemd 每隔几十秒重启一次，日志里看不出所以然。后来发现是健康检查的命令用了 curl，而精简基础镜像里根本没装 curl，命令直接返回 127，被判定为不健康。教训是 HealthCmd 用的工具必须在镜像里存在，最保险的是用容器里已有的工具，比如 wget 或者应用自带的健康检查接口调用。加健康检查之前先 podman exec 进去手动跑一遍那条命令，确认能返回 0。
第二个现场：服务跑了一周突然起不来，报错是no space left on device。看磁盘还剩不少，df 显示家目录分区用了 70%。查 podman system df 发现一堆悬空镜像占了十几个 G，都是每次构建打新标签留下的旧层。清理之后立刻恢复。这之后我加了定时任务，每周跑一次 podman image prune -f，并且给存储目录单独划了分区。
第三个现场：同事在机器上执行了一次 sudo podman ps，之后普通用户的构建就报权限错误。原因是 sudo 那次操作在 root 的存储目录里留下了文件，同时缓存目录的部分文件属主被改。最终用 podman system reset 清空当前用户的存储目录重新拉取才彻底解决。这件事之后我们在机器上加了提示，明确写着这台机器只允许普通用户执行 podman。
6.3 日常运维的几个习惯
第一个习惯是日志集中看。systemd 托管的容器，日志会进 journal，用journalctl --user -u demo-web -f追。别在服务器上只用 podman logs，那个只在容器还活着的时候有效，容器重建之后日志就断了。
第二个习惯是变更前先备份描述文件。~/.config/containers/systemd 整个目录用版本管理管起来，每次改动都有记录。容器挂了能重建，描述文件丢了要重新推导，那才是真麻烦。
第三个习惯是定期验证开机自启。重启一次机器比什么都实在，尤其在做完 linger 配置之后。本地虚拟机里做一次 reboot，看服务能不能自己回来，这一步花不了几分钟，能挡住后面很多事故。
第四个习惯是给关键容器设资源上限。.container 文件里可以写：
[Container] Memory=512m PidsLimit=256不设上限的容器一旦内存泄漏，会拖垮整台机器。rootless 下这些限制同样生效，前提是 systemd 版本支持对应的 cgroup 控制。
第五个习惯是把升级当成一次小发布。改标签、reload、验证、观察日志，四步走完再收工。滚动更新听起来优雅，但没有验证环节的自动更新，本质上是在赌，赌输了就是半夜被叫起来。
我个人在几台小机器上跑这套组合跑了两年多，最深的体会是：Podman 的学习曲线不在命令本身，而在“把所有权的边界想清楚”。搞清楚哪个进程以什么身份运行、数据落在谁家的命名空间里、服务由谁拉起、日志往哪流，剩下的就是查手册和试错。上面这些文件模板和排查路径，都是从“服务莫名挂了”和“权限说不上来的拒绝”里攒出来的，直接拿去用能少走不少弯路。
