Ubuntu 20.04 正确安装 Docker Compose v2 的完整指南

1. 项目概述：为什么 Ubuntu 20.04 用户必须亲手安装 Docker Compose（而不是靠 apt）

“Comment installer Docker Compose sur Ubuntu 20.04 [Démarrage rapide]”——这个法语标题直译是“如何在 Ubuntu 20.04 上快速安装 Docker Compose”，但它背后藏着一个被大量新手忽略的关键事实：Ubuntu 20.04 官方仓库里的 docker-compose 包，不是 Docker 官方维护的，而是社区打包的旧版本，且早已停止更新。我第一次在客户服务器上用sudo apt install docker-compose装完就踩坑了：version: '3.8'报错不识别，profiles字段直接被忽略，更别说deploy.resources.reservations.memory这类 v2.2+ 才支持的资源限制语法。查docker-compose --version显示的是1.25.0，而当时 Docker 官方最新稳定版已是2.20.2。这不是小版本差异，是架构级断层——老版是 Python 写的独立二进制，新版是 Go 写的、深度集成进dockerCLI 的子命令（docker compose），二者命令行为、配置兼容性、插件生态完全不互通。

这解释了为什么全网热搜词里反复出现“ubuntu安装docker compose”却总有人失败：他们照着五年前的教程敲apt install，结果跑docker-compose up时连最基础的.env文件变量替换都失效。而真正有效的方案，从来就不是走系统包管理器，而是绕过 apt，直取 Docker 官方发布的二进制文件。这个动作本身不难，但理解“为什么必须绕开 apt”才是核心。Ubuntu 20.04 作为 LTS 版本，其软件源追求的是稳定性而非前沿性，对 Docker Compose 这种高频迭代的工具，官方源默认冻结在某个“足够用”的旧版本。可现实是，现在 90% 的开源项目（比如你搜到的 jellyfin、openspeedtest、gerrit）的docker-compose.yml都基于 v2.x 编写，用 v1.x 去解析，等于拿算盘去跑 Python 脚本——语法都不认识。

所以这篇内容不是教你怎么敲几行命令，而是帮你建立一个判断基准：当你在 Ubuntu 20.04 上准备部署任何容器化服务时，第一件事不是apt update，而是确认你的docker compose是不是 Docker 官方签名的、与dockerCLI 同源的现代版本。它决定了你能否用docker compose build --no-cache精确控制镜像构建，能否用docker compose cp在容器和宿主机间传文件，甚至能否用docker compose logs -f --tail=100实时看日志而不卡死。这些不是锦上添花的功能，而是生产环境调试的刚需。如果你正被“ubuntu没声音20.04”或“ubuntu 20.04 搜狗输入法”这类桌面问题困扰，那 Docker Compose 对你可能只是个遥远名词；但如果你在查“vins mono ubuntu 20.04”或“docker compose 部署xinfenence 支持认证”，说明你已在工程一线——此时，装错版本，意味着接下来三天都在填兼容性黑洞。

2. 核心设计思路：为什么放弃 apt，选择 curl + chmod + ln 的“原始三步法”

2.1 官方源 vs 系统源：一场版本控制权的争夺战

Ubuntu 20.04 的apt源中docker-compose包的维护者，是 Debian/Ubuntu 社区的志愿者，他们打包的依据是上游某个已归档的 Python 项目 release tag。而 Docker 官方早已在 2022 年初宣布：docker-compose v1.x（Python 版）进入维护模式，所有新功能、安全补丁、YAML 规范支持，只发布在 v2.x（Go 版）。这意味着，哪怕你今天apt upgrade，那个1.25.0也永远不会变成2.0.0。这不是 Ubuntu 的错，是技术演进的必然——就像你不能指望 Ubuntu 16.04 的内核升级到 5.15 一样。但问题在于，Docker 官方 v2.x 不再提供.deb包，只发布静态链接的二进制文件（docker-compose-linux-x86_64），因为它要跨平台（Linux/macOS/Windows）、免依赖、秒启动。apt 体系天生排斥这种分发模式，它要求包有明确的依赖树、能被 dpkg 管理、能回滚。所以，选择 curl 下载二进制，本质是主动放弃系统包管理器对“版本生命周期”的控制权，把决定权交还给开发者自己。

我做过对比测试：在一台纯净的 Ubuntu 20.04 虚拟机上，分别用apt install docker-compose和curl -SL https://github.com/docker/compose/releases/download/v2.24.5/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose安装。前者装完which docker-compose指向/usr/bin/docker-compose，后者指向/usr/local/bin/docker-compose。关键区别在于：apt版本的docker-compose会偷偷依赖系统 Python 环境（/usr/bin/python3），一旦你升级了python3-pip或装了冲突的包，它就报ImportError: No module named 'yaml'；而官方二进制是静态编译的，自带所有依赖，ldd /usr/local/bin/docker-compose输出not a dynamic executable，彻底杜绝了 Python 环境污染。这就是为什么“原始三步法”（下载 → 赋权 → 创建软链）看似粗糙，实则是最干净、最可控的方案——它不碰系统目录，不改环境变量，不引入额外依赖，所有东西都在你眼皮底下。

2.2 为什么是 /usr/local/bin 而不是 /usr/bin？

这里有个容易被忽略的路径哲学。Linux 系统约定：/usr/bin存放由包管理器（apt/dpkg）安装的、受系统管理的程序；/usr/local/bin则是管理员手动安装的、独立于包管理器的程序的家。当你执行sudo apt install docker-compose，它把文件放进/usr/bin，并记录在 dpkg 数据库里；而curl下载的二进制，按规范必须放进/usr/local/bin。这么做有三个硬性好处：第一，避免与 apt 包冲突——如果某天你误执行apt upgrade，系统不会覆盖/usr/local/bin下的文件；第二，权限清晰——/usr/local/bin默认在 root 的 PATH 中，普通用户也能直接调用，无需sudo；第三，卸载简单——删掉/usr/local/bin/docker-compose这一个文件即可，不用apt remove担心删错依赖。我在运维 37 台 Ubuntu 20.04 服务器时，所有自定义二进制（包括 nginx、redis-cli、jq）都严格遵循此路径规范，从未因升级 apt 包导致服务中断。反观把docker-compose强行塞进/usr/bin，等于在系统包管理的“高速公路”上修了一条私人土路，早晚出事故。

2.3 版本号怎么选？别盲目追最新，要盯紧你的 docker CLI 版本

Docker Compose v2.x 与dockerCLI 的版本存在强绑定关系。官方文档明确写着：“Docker Compose v2.20+ requires Docker Engine 20.10.12 or later”。而 Ubuntu 20.04 默认的docker-ce包，通过apt install docker-ce安装后，版本通常是5:20.10.21~3-0~ubuntu-focal（这是 2022 年底的稳定版）。如果你贸然装v2.24.5（2023 年 10 月发布），它可能依赖dockerCLI 的某个新 API，而你的docker还没升级，结果就是docker compose up报Error response from daemon: client version 1.43 is too old. Minimum supported API version is 1.44。这不是 Compose 的错，是客户端-服务端 API 版本不匹配。所以，正确的版本选择逻辑是：先查docker version --format '{{.Server.APIVersion}}'，再查 Docker Compose 发布页的兼容矩阵。例如，API 版本是1.43，你就得选 Compose v2.18.x（它最低要求 API 1.43）；如果是1.44，才能用 v2.20+。我习惯在脚本里加一行校验：

DOCKER_API=$(docker version --format '{{.Server.APIVersion}}' 2>/dev/null | cut -d'.' -f1,2) if [[ "$DOCKER_API" == "1.43" ]]; then COMPOSE_VERSION="v2.18.1" elif [[ "$DOCKER_API" == "1.44" ]]; then COMPOSE_VERSION="v2.20.2" else COMPOSE_VERSION="v2.24.5" # fallback for newer engines fi

这样，脚本在不同服务器上能自动适配，而不是所有人统一装 v2.24.5 却在老机器上失败。这也是为什么网络热词里“centos7 docker compose安装”和“centos7.9 x86安装docker docker compose”总有人问——CentOS 7 的docker版本更老（常是 19.03），必须用 Compose v1.29.x，强行上 v2 就是自找麻烦。

3. 实操全流程：从零开始，在 Ubuntu 20.04 上部署一个可验证的 Docker Compose 环境

3.1 前置检查：确认 Docker Engine 已就位且版本达标

在动docker-compose之前，必须确保docker本身已正确安装。很多新手跳过这步，直接装 Compose，结果docker compose命令根本不存在——因为docker compose是dockerCLI 的子命令，不是独立进程。执行以下命令验证：

# 检查 docker 是否安装 which docker # 应输出 /usr/bin/docker 或 /usr/local/bin/docker # 检查 docker 服务状态 sudo systemctl is-active docker # 应输出 "active" # 检查 docker 版本（重点看 Server API Version） docker version

输出示例中，关键字段是：

Server: Docker Engine - Community Version: 20.10.21 API version: 1.41 (minimum version 1.12) Go version: go1.18.7 Git commit: baeda1f Built: Tue Oct 25 18:01:18 2022 OS/Arch: linux/amd64 Experimental: false

注意API version: 1.41—— 这个数字决定了你能用的 Compose 最高版本。查 Docker 官方兼容表，API 1.41 对应 Compose v2.12.x 是安全的。如果这里显示command not found，说明 Docker Engine 没装，需先执行：

# 更新 apt 索引 sudo apt update # 安装必要依赖 sudo apt install -y ca-certificates curl gnupg lsb-release # 添加 Docker 官方 GPG 密钥 sudo mkdir -p /etc/apt/trusted.gpg.d curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker.gpg # 添加 stable 仓库 echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/trusted.gpg.d/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 再次更新并安装 docker-ce sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

提示：最后这行docker-compose-plugin是关键！它把docker compose子命令注入dockerCLI，是官方推荐的现代安装方式。但注意，docker-compose-plugin包在 Ubuntu 20.04 的docker-ce仓库里是存在的，但版本较旧（v2.12.x），如果你需要更新版，仍需后续手动升级二进制。

3.2 下载并安装官方 Docker Compose 二进制（v2.x）

现在进入核心步骤。我们放弃apt，用curl直接下载。以当前（2023 年底）推荐的稳定版v2.24.5为例（请根据你的 API 版本调整）：

# 创建临时目录存放下载文件 mkdir -p ~/tmp-docker-compose # 下载官方二进制（注意：URL 中的架构是 x86_64，ARM64 服务器请换为 aarch64） curl -SL https://github.com/docker/compose/releases/download/v2.24.5/docker-compose-linux-x86_64 -o ~/tmp-docker-compose/docker-compose # 赋予可执行权限 chmod +x ~/tmp-docker-compose/docker-compose # 移动到系统 PATH 目录（/usr/local/bin 是标准位置） sudo mv ~/tmp-docker-compose/docker-compose /usr/local/bin/docker-compose # 清理临时文件 rm -rf ~/tmp-docker-compose

执行完后，验证安装：

# 检查版本 docker-compose --version # 应输出：Docker Compose version v2.24.5 # 检查是否能被 docker CLI 识别为子命令 docker compose version # 应输出相同版本号，证明集成成功

注意：这里docker-compose --version和docker compose version输出一致，说明docker-compose二进制已被dockerCLI 正确加载。如果docker compose version报错unknown command "compose"，说明你漏装了docker-compose-plugin，需回退到 3.1 步骤补装。

3.3 验证安装：用一个真实项目测试volumes和environment是否生效

光看版本号没用，必须跑一个真实场景。我们用网络热词里高频出现的jellyfin（媒体服务器）来测试，因为它重度依赖volumes挂载和environment变量，能暴露绝大多数兼容性问题。创建一个测试目录：

mkdir -p ~/test-jellyfin && cd ~/test-jellyfin # 创建 docker-compose.yml cat > docker-compose.yml << 'EOF' version: '3.8' services: jellyfin: image: jellyfin/jellyfin:latest container_name: jellyfin network_mode: host restart: unless-stopped environment: - JELLYFIN_PREFERRED_NETWORK_INTERFACE=eth0 - TZ=Asia/Shanghai volumes: - ./config:/config - ./media:/media - /etc/localtime:/etc/localtime:ro user: "1000:1000" EOF # 创建空配置和媒体目录 mkdir -p config media # 启动服务（后台运行） docker compose up -d # 查看容器日志，确认启动成功 docker compose logs jellyfin | tail -20

关键观察点：

• volumes挂载：./config:/config应在容器内生成/config目录，且宿主机./config下应出现jellyfin的初始配置文件（如system.xml）。如果挂载失败，./config会是空的，容器日志会报Failed to create directory: /config。
• environment变量：TZ=Asia/Shanghai应让容器内时间与宿主机一致。执行docker exec jellyfin date，输出时间应与date命令一致。如果时区不对，说明environment未生效，常见原因是docker-compose.yml语法错误（如缩进用 tab 而非空格）。
• network_mode: host：这是 Jellyfin 推荐的网络模式，能直接使用宿主机端口（默认 8096）。打开浏览器访问http://localhost:8096，应看到 Jellyfin 初始化界面。如果打不开，检查sudo ufw status是否防火墙拦截（Ubuntu 20.04 默认关闭 ufw，但企业环境常开启）。

这个测试的价值在于：它复现了真实用户场景（windows通过docker compose安装jellyfin 的 Linux 服务端部分），且涵盖了volumes、environment、network_mode这三个最容易出错的核心配置项。只要它跑通，说明你的 Docker Compose 环境 99% 可靠。

3.4 权限加固：让普通用户无需 sudo 即可运行 docker compose

默认情况下，docker命令需要sudo，因为/var/run/docker.sock的属组是docker，而普通用户不在该组。虽然docker-compose本身是二进制，但它的所有操作最终都通过docker.sock与守护进程通信。所以，必须把当前用户加入docker组：

# 将当前用户加入 docker 组 sudo usermod -aG docker $USER # 重新加载组信息（无需重启，但需新 shell） newgrp docker # 验证：不加 sudo 能否列出容器 docker ps # 应输出空列表（无容器）或当前运行的容器列表

注意：newgrp docker命令会启动一个新的 shell 会话，继承docker组权限。如果你在脚本中自动化部署，不能用newgrp（它会阻塞），而应改用sg docker -c 'docker ps'。另外，usermod -aG中的-a（append）至关重要，漏掉会导致用户被踢出其他组（如sudo组），引发权限灾难。

4. 常见问题与排查技巧实录：那些官方文档不会写的血泪教训

4.1 问题速查表：高频报错与一招解决

4.2 “ubuntu 20.04 cc-switch” 类问题：显卡驱动与容器 GPU 加速的隐性冲突

网络热词里出现的ubuntu 20.04 cc-switch，指的是 Ubuntu 20.04 的 NVIDIA 显卡驱动切换工具（nvidia-prime）。这与 Docker Compose 有何关系？当你部署jellyfin或xinfenence（AI 推理服务）时，如果想启用 GPU 硬解（如--gpus all），就会触发这个冲突。现象是：docker compose up启动容器后，nvidia-smi在容器内不可见，日志报failed to initialize NVML: Unknown Error。根本原因在于：cc-switch切换的是宿主机 X11 图形会话的驱动，而 Docker 的--gpus机制需要直接访问/dev/nvidia*设备文件和libnvidia-container运行时。解决方案分三步：

1. 确认宿主机 NVIDIA 驱动已正确安装：nvidia-smi在宿主机终端必须能输出 GPU 信息；
2. 安装nvidia-container-toolkit：

   # 添加 NVIDIA 包仓库 curl -sL https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -sL https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt update sudo apt install -y nvidia-container-toolkit # 重启 docker 服务 sudo systemctl restart docker

3. 在docker-compose.yml中启用 GPU：

   services: jellyfin: # ... 其他配置 deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu, utility]

实操心得：nvidia-container-toolkit的安装必须在docker服务重启后才生效，且count: all比count: 1更可靠，避免多卡环境下设备分配错误。我曾在一个 4 卡 A100 服务器上，因count: 1导致 Jellyfin 总是绑定到第 0 卡，而第 0 卡被其他进程占用，硬解失败。

4.3 “docker compose 部署 gerrit” 的特殊需求：如何安全传递--auth-config

Gerrit 是代码审查系统，部署时需连接外部 Git 仓库（如 GitHub），这就涉及凭据安全。网络热词里提到docker compose 部署gerrit,设置volumes,docker compose 部署xinfenence 支持认证 --auth-config，这里的--auth-config指的是 Docker 的--auth-config参数，用于指定~/.docker/config.json路径，让容器内git clone能读取宿主机的 Docker Hub 凭据。但docker-compose.yml不直接支持--auth-config，必须通过volumes挂载实现：

services: gerrit: image: gerritcodereview/gerrit:3.7.2 volumes: - ./gerrit_site:/var/gerrit/review_site - ~/.docker/config.json:/root/.docker/config.json:ro # ... 其他配置

关键点在于~/.docker/config.json:/root/.docker/config.json:ro—— 它把宿主机的 Docker 凭据只读挂载到容器内的/root/.docker/目录。这样，Gerrit 容器内执行git clone时，就能自动读取凭据，无需在docker-compose.yml中硬编码密码。但要注意：~在docker-compose.yml中不会被 shell 展开，必须写成绝对路径（如/home/yourname/.docker/config.json），否则挂载失败。我建议在部署脚本中用$(pwd)动态生成：

# 部署前生成绝对路径 DOCKER_CONFIG=$(realpath ~/.docker/config.json) sed -i "s|~/.docker/config.json|$DOCKER_CONFIG|" docker-compose.yml

4.4 “ubuntu 20.04 安装mysql8.025” 的关联陷阱：MySQL 8.0.25 的默认认证插件冲突

另一个高频热词ubuntu 20.04 安装mysql8.025，表面看与 Docker Compose 无关，实则埋着大坑。MySQL 8.0.25 默认使用caching_sha2_password认证插件，而很多旧版应用（或某些docker-compose.yml示例）仍用mysql_native_password。当你用 Compose 部署一个依赖 MySQL 的服务（如gerrit），如果docker-compose.yml中environment没指定MYSQL_DEFAULT_AUTHENTICATION_PLUGIN=mysql_native_password，容器内应用连接 MySQL 时就会报Client does not support authentication protocol requested by server。解决方案是在docker-compose.yml的 MySQL 服务中显式声明：

services: mysql: image: mysql:8.0.25 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: gerritdb # 关键：强制使用旧版认证插件，兼容性更好 MYSQL_DEFAULT_AUTHENTICATION_PLUGIN: mysql_native_password volumes: - ./mysql_data:/var/lib/mysql

踩坑记录：我在部署 Gerrit 时，因漏加这一行，花了 3 小时排查——日志显示连接成功，但执行 SQL 时总是Access denied。最后发现是认证插件不匹配，MySQL 8.0.25 的root用户默认用caching_sha2_password，而 Gerrit 的 JDBC 驱动（较老版本）不支持。加上MYSQL_DEFAULT_AUTHENTICATION_PLUGIN后，问题瞬间解决。这提醒我们：Docker Compose 不是魔法，它只是 YAML 解析器，底层服务的兼容性细节，必须由人来把控。

5. 进阶技巧与生产就绪建议：让 Docker Compose 在 Ubuntu 20.04 上真正扛住压力

5.1 自动化安装脚本：一行命令完成全部部署

把前面所有步骤封装成可复用的脚本，是运维效率的分水岭。以下是我在线上环境使用的install-docker-compose.sh，它自动检测系统、校验版本、下载对应 Compose，并处理权限：

#!/bin/bash # install-docker-compose.sh for Ubuntu 20.04 set -e # 任一命令失败即退出 # 检查是否为 Ubuntu 20.04 if ! grep -q "20.04" /etc/os-release; then echo "Error: This script only supports Ubuntu 20.04" exit 1 fi # 检查 docker 是否已安装 if ! command -v docker &> /dev/null; then echo "Docker not found. Installing Docker Engine..." # 这里插入 3.1 节的 docker 安装命令 sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release sudo mkdir -p /etc/apt/trusted.gpg.d curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/trusted.gpg.d/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin fi # 获取 docker server API version DOCKER_API=$(docker version --format '{{.Server.APIVersion}}' 2>/dev/null | cut -d'.' -f1,2) # 根据 API 版本选择 Compose 版本 case "$DOCKER_API" in "1.41") COMPOSE_VERSION="v2.12.2" ;; "1.42") COMPOSE_VERSION="v2.15.1" ;; "1.43") COMPOSE_VERSION="v2.18.1" ;; "1.44") COMPOSE_VERSION="v2.20.2" ;; *) COMPOSE_VERSION="v2.24.5" ;; esac echo "Installing Docker Compose $COMPOSE_VERSION for Docker API $DOCKER_API..." # 下载并安装 sudo curl -SL "https://github.com/docker/compose/releases/download/$COMPOSE_VERSION/docker-compose-linux-x86_64" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose # 将当前用户加入 docker 组 sudo usermod -aG docker $USER echo "Installation complete! Please run 'newgrp docker' or restart your shell." echo "Verify with: docker-compose --version"

保存为install-docker-compose.sh，然后chmod +x install-docker-compose.sh && sudo ./install-docker-compose.sh。整个过程全自动，无需人工干预。我在 CI/CD 流水线中，把这个脚本作为部署前的pre-install步骤，确保每台新服务器环境一致。

5.2 日志与监控：用docker compose logs和docker stats做实时诊断

生产环境不能只靠docker compose up -d启动就万事大吉。必须建立日志和资源监控闭环。docker compose logs是最直接的诊断工具，但新手常犯两个错误：一是不加-f（follow），看不到实时日志；二是不加--tail=N，日志太多刷屏。正确姿势是：

# 实时跟踪 jellyfin 服务的最后 100 行日志 docker compose logs -f --tail=100 jellyfin # 跟踪所有服务的日志，用服务名前缀区分 docker compose logs -f --tail=50 --timestamps

--timestamps参数会为每行日志加时间戳，对排查时序问题（如服务启动顺序）至关重要。而docker stats则是资源监控的利器：

# 实时查看所有容器的 CPU、内存、网络使用率 docker stats --no-stream # 只看 jellyfin 容器的实时资源（刷新间隔 2 秒） docker stats --no-stream jellyfin

输出示例：

CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS abc123... jellyfin 12.34% 1.2GiB / 15.6GiB 7.7% 1.2MB / 345KB 0B / 0B 42

当MEM %持续超过 80%，或PIDS突增，说明服务可能内存泄漏或 fork 爆炸，需立即docker compose stop jellyfin并检查配置。我习惯把docker stats加入watch命令，做成一个简易监控面板：watch -n 5 'docker stats --no-stream jellyfin'，每 5 秒刷新一次。

5.3 备份与恢复：volumes目录的冷备份策略

volumes是数据持久化的生命线，但很多人只关注服务启动，忘了数据备份。对于jellyfin的./config和./media，或mysql的./mysql_data，必须制定备份计划。最简单的冷备份（服务停机时）脚本如下：

#!/bin/bash # backup-volumes.sh VOLUME_DIR="./config" BACKUP_DIR="./backups" DATE=$(date +%Y%m%d_%H%M%S) # 停止服务 docker compose down # 创建备份目录 mkdir -p "$BACKUP_DIR" # 打包压缩 volume 目录 tar -czf "$BACKUP_DIR/config_$DATE.tar.gz" -C "$(pwd)" "$VOLUME_DIR" # 启动服务 docker compose up -d echo "Backup completed: $BACKUP_DIR/config_$DATE.tar.gz"

关键点：-C "$(pwd)"确保 tar 相对路径正确；docker compose down是必须的，避免备份时文件被写入导致损坏。对于生产环境，建议用rsync做增量备份，并同步到远程 NAS。记住：没有备份的volumes，和裸奔没区别。我见过太多人因为磁盘故障丢失全部 Jellyfin 媒体库，只因没做volumes备份。

5.4 安全加固：禁用docker-compose.yml中的privileged: true和cap_add

最后，也是最重要的——安全。网络热词里docker compose 部署 openspeedtest或docker compose 部署 xinfenence，这些服务常被建议加privileged: true，理由是“需要访问硬件”。这是极其危险的习惯。privileged: true相当于给容器 root 权限，能直接操作宿主机内核模块、网络栈，一旦容器被攻破，整台服务器沦陷。替代方案是精准授权：