十二.运行容器

通过第三部分的实操，实现了容器的数据持久化 与网络互通，解决了容器 "数据易丢失""外部无法访问" 的核心痛点。但在生产环境中，容器还需具备 "自动化运维能力"------ 比如主机开机自启、故障自动恢复、状态实时监控等。需要将容器纳入系统服务管理体系，而 systemd 作为 Linux 系统的核心服务管理器，正是实现这一需求的最优方案。

本文将聚焦如何通过 systemd 将容器封装为系统服务，实现容器的 "服务化" 运维，让容器像传统系统服务一样稳定、可控。

4.作为系统服务管理容器

4.1使用systemd unit

普通用户可以创建systemd unit来配置rootless容器，利用此配置，通过systemctl命令将容器作为常见的系统服务进行管理操作。

适用于小型、无需扩展 的容器部署 （如单容器 Web 服务、简单后台服务）。依赖 systemd 的本地服务管理能力，即可实现容器的 "服务化" 管理。

对于复杂编排场景，systemd 能力不足，需使用 Kubernetes等企业级编排平台

4.2systemd User Service要求

普通用户通过systemd User Service管理rootless 容器、时，需满足 3 个关键条件，否则会出现权限或会话问题：

（1）需创建专用普通用户

原理：

useradd创建普通用户时，系统会在****/etc/subuid**** 中为容器预留 UID 范围（用于用户 namespace 映射）；

若用useradd --system（系统账户），则不会预留该范围，无法启动 rootless 容器。

操作：

sudo useradd 专用用户

sudo passwd 密码

（2）Podman 需 "完整登录会话"

原因：

直接用su / sudo 切换用户会报错：

XDG_RUNTIME_DIR directory /run/user/1008 is not owned by the current user

因为su /sudo 未加载完整用户会话；

方法：

通过ssh登录专用用户，确保 Podman 获取正确的环境变量。

ssh 专用用户@localhost

登录本地主机

（3）容器启动失败的日志排查

若容器启动后立即退出：

podman ps -a

显示Exited

如：

排查原因：

podman container logs 容器名

针对不同原因进行修复。

4.3创建systemd用户文件

核心逻辑：

在~/.config/systemd/user/ 路径下，编写用户级的 .service 单元文件。

Podman 可通过podman generate systemd自动生成符合规范的 systemd 单元文件，控制"容器的创建/删除"，无需手动编写*.service文件

4.3.1生成systemd文件

（1）核心选项

|------------|--------------------------------------------|---------------------------------------------|---------------|
| 选项 | 作用 | 容器生命周期 （启动→停止） | 适用场景 |
| 无--new | 基于现有容器 生成配置 | 启动现有容器 → 停止容器（不删除） | 需保留容器状态的场景 |
| --new | 启动时新建容器 ，停止时删除容器 （自动加--rm） | 创建并启动新容器 → 停止并删除容器 | 容器无状态、需每次全新启动 |
| --files | 将配置直接生成文件（而非控制台输出），避免手动复制（文档未提但实战常用） | - | 批量管理多个容器 |

（2）为现有容器生成systemd文件

podman generate systemd --name 容器名

（3）启动时新建容器， 停止时删除容器

podman generate systemd --name 容器名 --new

（4）生成文件到默认目录（~/.config/systemd/user/）

podman generate systemd --name 容器名 --files

（5）配置文件完成后，重启守护进程

systemctl --user daemon-reload

4.3.2unit 文件存放目录

|--------------|--------------------------|--------------|
| 用户类型 | 存放目录 | 权限要求 |
| 普通用户 | ~/.config/systemd/user/ | 仅当前用户可读写 |
| root 用户 | /etc/systemd/system/ | 需 root 权限 |

4.4管理systemd文件

生成 unit 文件后，通过systemctl --user管理容器服务；

如：

systemctl --user start container-容器名字.service

systemctl --user status container-容器名字.service

4.4.1核心命令

|------------|---------------------------------------------------|--------------------------------------------|
| 操作 | 普通用户（User Service） | root 用户（System Service） |
| 重新加载配置 | systemctl --user \ daemon-reload | systemctl \ daemon-reload |
| 启动服务 | systemctl --user start \ container-容器名字.service | systemctl start \ container-容器名字.service |
| 停止服务 | systemctl --user stop \ container-容器名字.service | systemctl stop \ container-容器名字.service |
| 查看状态 | systemctl --user status \ container-容器名字.service | systemctl status \ container-容器名字.service |
| 设置开机自启 | systemctl --user enable \ container-容器名字.service | systemctl enable \ container-容器名字.service |
| 查看日志 | journalctl --user -u \ container-容器名字.service | journalctl -u \ container-容器名字.service |

4.4.2注意事项

（1） 禁止手动干预：

若用systemctl启动服务，不可再用podman start/stop操作容器------systemd 会误判容器状态（如手动停止后，systemd 可能再次重启）。

（2） 状态验证：

systemctl --user status需显示active (running)，且日志无报错；

若失败，优先查看podman container logs 容器名或journalctl日志。

4.5配置在主机启动时启动的容器

默认情况下，普通用户的 systemd 服务 仅在用户登录后启动 ，登出后停止 ，无法实现 "主机开机启动"。需通过loginctl enable-linger突破此限制。

4.5.1原理：

linger（持续运行）功能让系统为用户保留一个 "虚拟会话"，即使用户未 SSH 登录，其systemd User Service也能持续运行。

4.5.2操作：

（1）查看用户的linger状态（默认no）

loginctl show-user 专用用户 | grep Linger

（2）启用linger

sudo loginctl enable-linger consvc

（3）验证状态

loginctl show-user 专用用户 | grep Linger

输出：Linger=yes

（4）关闭linger（如需）

sudo loginctl disable-linger consvc

4.6 以root用户管理systemd容器

若容器需要特权（如映射 1024 以下端口、访问系统设备），需用 root 用户管理，步骤与普通用户类似，但更简洁

区别：

|-------------------|--------------------------|-------------------------|
| 对比项 | 普通用户（rootless） | root用户（rootful） |
| 专用用户 | 必须创建（非 system 账户） | 无需，直接用 root |
| unit 文件目录 | ~/.config/systemd/user/ | /etc/systemd/system/ |
| systemctl选项 | 需--user | 无需 |
| linger配置 | 必须启用 | 无需 |
| 特权操作（如端口 < 1024） | 不支持 | 支持 |