Podman存储路径迁移实战：从根目录告警到稳定运行

1. 根目录告警：Podman存储路径的典型问题

那天早上刚到公司，运维群里的报警消息就炸开了锅——生产服务器的根目录空间只剩下不到5%。作为团队里负责容器化部署的成员，我立刻意识到这很可能是Podman存储路径的问题。登录服务器用df -h一看，果然/var/lib/containers目录吃掉了近80%的空间。

这种情况在长期运行Podman的环境中太常见了。默认安装时，Podman会把所有容器镜像、层数据都存放在/var/lib/containers下。随着业务增长，这个目录就像个贪吃蛇，不知不觉就吞掉了整个根分区。我见过最夸张的案例，一个机器学习团队的Jupyter Notebook容器，因为频繁安装Python包，半年就让存储膨胀到1.2TB。

为什么这是个严重问题？ 根分区被占满会导致系统级故障：日志无法写入、新用户无法创建、甚至SSH都登录不了。去年我们有个测试环境就因此瘫痪了8小时。更麻烦的是，像GitLab、Jenkins这类服务如果和容器混部，存储冲突会导致关键业务中断。

通过podman info命令，我确认了当前配置：

bash复制$ sudo podman info | grep -A5 "store"
  store:
    configFile: /etc/containers/storage.conf
    containerStore:
      number: 7
    graphDriverName: overlay
    graphRoot: /var/lib/containers/storage

这里的关键是graphRoot参数，它决定了容器数据的存放位置。在默认情况下，这个路径会像黑洞一样持续吞噬根分区空间。接下来我要做的，就是把这个"黑洞"迁移到专门的存储设备上。

2. 方案选型：符号链接 vs 配置修改

面对存储迁移，通常有两种主流方案：

2.1 符号链接方案

这是我最初尝试的方法，看起来简单直接：

1. 停止所有容器和服务
2. 把/var/lib/containers移动到新位置（比如/data/containers）
3. 创建符号链接：ln -s /data/containers /var/lib/containers

**