释放小七猫的分享欲

不与大容量硬盘交互的容器服务

tags: NAS
@ 27/11/2025

不与大容量硬盘交互的容器服务

在我使用的服务中，有相当大的一部分是存储需求较低，甚至不需要与机械硬盘进行任何交互的，例如我常用的：

  • homepage：主页，纯文本配置
  • gitea：代码文件，占用也就几百兆
  • vaultwarden：密码管理，纯数据库
  • qinglong：计划任务，纯文本配置
  • 博客主页：文章、图片居多，但也就几个 G

……

这些服务读写频繁，小文件众多，更适合放在固态硬盘上。

如果我们后面要配置一台专门的 NAS 虚拟机的话，为什么不跑在虚拟机上呢？

  1. 这些服务不与机械硬盘交互，因此无论跑在那个节点，实际都是跑在固态硬盘上
  2. 直接放在 NAS 虚拟机上，服务的耦合性会很高，如果 NAS 虚拟机重启则会导致所有服务宕机，那么我们就失去了使用 PVE 的意义

基于这种思路，我们有两种方案可选：

LXC 容器+docker/podman（推荐）

首先下载一个 Debian12/Alpine Linux 的 CT 模板。这个模板会作为我们跑 docker 的基础镜像，因此越轻量越好。

然后基于这个镜像创建 LXC 容器，由于这些服务无需与外界交互，因此使用无特权容器即可。

不过我用的是 debian12 容器，后续操作类似。

换源

debian12：

sudo sed -i 's/deb.debian.org/mirrors.ustc.edu.cn/g' /etc/apt/sources.list

Alpine Linux:

sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g' /etc/apk/repositories

这里要注意，debian12 换源后，security.debian.org 这个是没法换的，因此可能还需要挂代理或者通过别的方式来加速下载才行。Alpine 没有这个问题，换了之后速度就很快。

安装 docker

先说 Alpine：

apk add docker docker-compose

完事

然后是 debian12，由于 debian12 官方源中的 docker 版本比较老，因此建议从官网根据官方教程安装。

如果 apt 安装的版本能跑起来你需求的容器的话，也可以从源安装。

所以你知道我为什么推荐 Alpine 了。

容器管理

root@container:~/appdata# pwd
/root/appdata
root@container:~/appdata# ls
gitea  halo  homepage  qinglong  vaultwarden

我在 root 用户目录下创建了一个 appdata 文件夹，专门用来存放 docker 数据，每一个子文件夹就是一个项目，所有的目录都按相对路径映射：

services:
  homepage:
    image: ghcr.io/gethomepage/homepage:latest
    container_name: homepage
    restart: always
    ports:
      - 7556:3000
    volumes:
      - ./config:/app/config # Make sure your local config directory exists
      - ./images:/app/public/images
      # - /var/run/docker.sock:/var/run/docker.sock

备份数据或者迁移数据，仅需要把整个 appdata 文件夹打包带走即可。

关于网络模式：如果没有端口冲突，建议一律使用 host 模式，提升网络性能，不过感知其实不强。

Pod

Podman 的 Pod 是将多个容器按 Kubernetes Pod 模型组织的逻辑单元，共享网络、IPC 等命名空间与资源约束，可统一启停、监控与迁移，适合本地开发 / 测试与 K8s 无缝衔接，支持 root/rootless 模式。

Pod 是“容器组合单元”（共享资源、同生命周期），docker-compose 是“多容器编排工具”（定义依赖、独立资源），定位和使用场景完全不同。docker-compose 实际上只是把多个容器按某种依赖关系进行启动并让它们协同工作，理论上你手动启动也能达成相同的效果。

但 Pod 想让多个容器“绑在一起”（共享网络、同步启停）。但你用 podman-compose 启动 docker/podman-compose.yml 文件时，实际上是创建了一个 Pod 来对这些容器进行管理，与 docker 的启动逻辑是不同的。

❯ podman pod list
POD ID        NAME        STATUS      CREATED      INFRA ID    # OF CONTAINERS
2328926f0329  pod_media   Running     3 hours ago              3
❯ podman ps -a
CONTAINER ID  IMAGE                                  COMMAND     CREATED      STATUS      PORTS       NAMES
36f7b762350a  docker.io/iyuucn/iyuuplus-dev:latest               3 hours ago  Up 3 hours  8780/tcp    IYUUPlus
2ebe6acec90b  docker.io/jxxghp/moviepilot-v2:latest              3 hours ago  Up 3 hours  3000/tcp    moviepilot-v2
a2e0ee331fe5  docker.io/cnk3x/xunlei:latest          /bin/xlp    3 hours ago  Up 3 hours              xunlei

其中 pod_media 这个 Pod 是 podman 根据文件夹目录自行创建的，docker-compose.yml 的编写方法与 docker 几乎一致。

至于你选择用 podman 还是 docker，根据自己的喜好进行选择即可。

使用 PVE 9.1 新增的 OCI 功能

这个功能还处于初级阶段，管理方式也与一般的 docker compose 差别较大，现阶段不推荐使用