3.2 共享存储与生态协同

3.2 共享存储与生态协同

本节摘要：Podman、Buildah、Skopeo 共享的 containers/storage 让镜像在三件工具间零拷贝流转，也带来 Docker 工作流里没有的协同玩法：构建即产出、复制即入仓、同一份缓存多方复用。本节实操验证共享机制，盘点外围生态（compose 兼容层、桌面集成、IDE 插件）的衔接方式，并明确家族模型的留白处——你需要自己拼的拼图有哪些。

零拷贝流转：亲眼验证一次

共享存储的价值讲概念容易虚，直接动手。三个工具先后操作同一个镜像，观察存储只此一份：

# 用 skopeo 把镜像直接拉进本地存储（不经过 podman）
skopeo copy docker://docker.io/library/redis:7-alpine \
    containers-storage:docker.io/library/redis:7-alpine
#   Copying blob 4a1d... done
#   Copying config ... done

# podman 直接能跑它——没有"导入"步骤
podman images | grep redis
#   docker.io/library/redis  7-alpine  ...  12.1 MB
# 注意大小：实际磁盘占用约等于一份镜像，
# podman images 显示的是共享存储里的同一份数据

# buildah 基于它构建衍生镜像，同样不搬运数据
buildah from docker.io/library/redis:7-alpine
#   redis-working-container
# 解读：得到一个"工作容器"——构建过程的基础（第 4.2 节展开）
​

反向同理：buildah 构建出的镜像 tag 好之后，skopeo 可以直接从 containers-storage 把它推到仓库，podman 可以直接 run。对比 Docker 工作流里 docker save / docker load 的 tar 包来回倒腾，共享存储省的不只是时间——它消除了"导出文件"这个中间形态，也就消除了版本错配与磁盘占用这两类隐患。

共享的另一面：rootless 与 rootful 是两套仓

第 2.1 节提过的事实，在生态语境下会再次咬人，值得单独强调：共享发生在"同一用户、同一权限模式"内。rootless Podman 与 rootful Podman 的存储目录不同，Buildah 同样分模式。实操里最典型的症状：

# 普通用户构建了镜像
buildah bud -t myapp:dev .
podman images | grep myapp
#   localhost/myapp  dev  ...

# 换 rootful 场景（比如某个旧脚本用 sudo 调用）
sudo podman images | grep myapp
#   （空）——sudo 那一侧的存储里没有它

# 家族内的正确共享姿势：保持同一身份。
# 确实需要跨身份搬运时，用 oci-archive 过桥：
skopeo copy containers-storage:myapp:dev \
    oci-archive:/tmp/myapp.tar
sudo skopeo copy oci-archive:/tmp/myapp.tar \
    containers-storage:myapp:dev
​

这条"过桥"路径也是与 Docker 世界互通的标准做法——oci-archive 是 OCI 标准定义的镜像归档格式，任何遵守标准的引擎都能读。

外围生态：兼容层与拼装件

家族模型把功能拆给专业工具，外围就得靠"拼装件"衔接既有工作流。几件常用的：

compose 兼容层。Podman 官方提供了 podman-compose（社区实现的 Docker Compose 兼容层），把 compose 文件里的服务翻译成 podman run 参数。它能跑通大部分标准 compose 文件——服务依赖、网络、卷映射都支持。局限也要心里有数：它没有 Docker Compose 那么成熟的伸缩与状态管理，Compose Spec 里较新的字段跟进有延迟；复杂编排更推荐第 8 章的 play kube 路线。

# 典型使用：在既有项目目录里直接跑
podman-compose up -d
#   podman create ... db
#   podman create ... web
#   解读：逐服务翻译成容器创建，网络建为 podman network
​

桌面与 IDE 集成。各大 IDE 的容器插件大多走 Docker API 协议，Podman 从 3.x 起提供兼容的 socket（默认激活方式见第 10 章），插件里改一个 socket 路径就能连。Podman Desktop 则是独立的图形管理界面，同时管理容器、Pod、镜像与机器（Windows/macOS 的虚拟机环境）。本教程不展开 GUI，但知道这些衔接点的存在很重要——迁移不要求你抛弃趁手的工具。

镜像安全工具。扫描类工具大多能直接对着本地存储或远程仓库工作，家族模型下它们与 skopeo 是并列关系：skopeo 拿 digest、扫描器拿 digest 去查——这条链路是第 6.3 节签名验证的地基。

留白处：你需要自己拼的拼图

诚实地列出家族模型的空位。跨机器的镜像"内容寻址缓存"（Docker 的 registry mirror 语义）在 containers/storage 里没有完全等价物，需要配置仓库的 mirror 参数；构建缓存的分布式共享（团队共用构建缓存）目前要靠自建方案；监控与事件流没有统一插件市场，第 7.3 节的事件与日志是主要观测入口。这些空位不致命，但迁移评估时要把它们列进成本栏——第 9 章的迁移案例会专门算这笔账。

本节要点回顾

• 共享存储三向零拷贝：skopeo 拉取、buildah 构建、podman 运行，同一份数据
• 共享有身份边界：rootless 与 rootful 是两套仓，跨身份用 oci-archive 过桥
• compose 有兼容层：podman-compose 覆盖大部分标准场景，复杂编排转 play kube
• IDE 经 Docker 兼容 socket 接入：改一个路径，不用换工具
• 留白处要记账：分布式缓存、监控插件市场是家族模型的成本栏