10.1 API 服务与远程管理

10.1 API 服务与远程管理

本节摘要：podman system service 按需启动一个无状态的 REST 服务端，兼容 Docker API 的核心端点；podman remote 经 SSH 隧道让客户端操作远端引擎；podman machine 在 macOS 与 Windows 上管理承载引擎的 Linux 虚拟机。三者合起来是 Podman 的"服务器形态"——按需而生、随会话而灭，与 dockerd 的常驻服务端形成方法论级对比。

先跑通：三十秒的 REST 服务端

# 启动 API 服务（rootless，unix socket 方式）
podman system service --time 0 unix:///run/user/1000/podman/podman.sock &
# 解读 --time 0：空闲不超时退出（生产按需配超时）；
# socket 放在用户运行时目录，属主是你自己

# 直接用 curl 操作它
curl -s --unix-socket /run/user/1000/podman/podman.sock \
    http://d/v4.0.0/libpod/containers/json | head -c 300
#   [{"Id":"2b8e...","Names":"web","Image":...
# 返回容器列表——完整的 REST 语义

# 兼容 Docker API 端点（给走 Docker 协议的工具用）
curl -s --unix-socket /run/user/1000/podman/podman.sock \
    http://d/containers/json | head -c 200
#   [{"Id":...}] —— Docker 风格的响应结构
# IDE 插件、监控代理改个 socket 路径就能接入（第 9.1 节的踩坑记录兑现）
​

与 dockerd 的差异要落到行为上理解：system service 挂掉（或被你 kill）时，容器一切如常——conmon 还在监控、systemd 还在值守、journald 还在收日志。API 层只是观察与操控的窗口，不是生命中枢。生产上把它做成 systemd 服务常驻也可以，但那是你的选择而不是架构的强制——权力形态由部署者决定。

podman remote：把 CLI 半径扩到远端

remote 子命令让本地 podman 客户端经 SSH 操作远端引擎，所有日常命令透明转发：

# 声明一个远端连接（一次配置）
podman remote add build-server --connection ssh://dev@10.0.0.21/run/user/1000/podman/podman.sock
# 默认走 SSH 隧道到远端的 rootless socket

# 切换默认连接后，命令完全透明
podman --remote ps
# 列出的是 build-server 上的容器
podman --remote run -d nginx:alpine
# 在远端机器上以远端用户身份跑容器

# 管理连接
podman remote list
#   Name          URI ...
#   build-server* ssh://dev@10.0.0.21/...
​

对比 Docker 的远程方案（DOCKER_HOST 加 TLS 证书或 SSH 上下文），podman remote 的选择是把"通道"直接押在 SSH 上——认证、加密、审计复用系统既有体系，不用为容器引擎单独养一套证书基础设施。代价是依赖远端 SSH 可达；对跳板机后的机房，这反而是优点（SSH 能到的地方容器就能管）。

podman machine：macOS 与 Windows 的官方形态

非 Linux 平台上 Podman 必须跑在 Linux 虚拟机里（容器是内核机制，容器之道在内核）。podman machine 把这件事一体化：创建、启动、SSH 配置、socket 转发全自动：

# macOS 上的完整体验（Windows 的 WSL 后端同理）
podman machine init
#   Downloading VM image ... Done
podman machine start
#   Starting machine ...
# 此后本机 podman 命令自动转发进虚拟机

podman run -d -p 8080:80 nginx:alpine
# 端口自动从虚拟机映射到 macOS 宿主，浏览器直接访问
​

与 Docker Desktop 的架构对比一句话可概括：同为"虚拟机加客户端"，Docker Desktop 的服务端常驻且带 GUI 商业生态；podman machine 的服务端按需、纯命令行、rootless 语义完整（虚拟机里你的容器仍是普通用户进程）。选哪个看你在乎图形界面生态还是无守护进程哲学的一致性——第 9.3 节决策表的"个人开发机"行在非 Linux 平台的延伸。

一个完整案例：三台服务器的统一管理面

背景：三台应用服务器（第 9 章迁移后的成果）分散在两个机房，运维希望在跳板机上统一查看与操作。操作：跳板机配置三个 remote 连接；日常巡检脚本循环 podman --remote -c <连接> ps 加 systemctl --user -M dev@<主机> status（systemd 的远程语法配合，容器与服务的两层状态一起收）；应急操作走同一通道。结果：没有部署任何新的管理服务端，管理面就是 SSH 加既有 CLI——零新增攻击面。解读：无守护进程架构下"统一管理"不等于"建一个中枢"，而是把已有工具的远程能力组合起来；中枢模式（像 dockerd 那样）反而会引入新的特权点。变式：需要 API 化的场景（监控平台抓数据）在每台服务器上用 Quadlet 起一个 system service 定时单元，仍然无常驻特权进程。

本节要点回顾

• service 是门卫不是中枢：无状态、可退出，容器生命不系于它
• Docker API 兼容端点：IDE 与旧工具改 socket 路径即可接入
• remote 押注 SSH：认证加密审计复用系统体系，免养证书基础设施
• machine 是非 Linux 平台的官方形态：虚拟机加客户端，rootless 语义完整
• 统一管理不必建中枢：remote 加 systemd 远程语法的组合已够用