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 --tail100实时看日志而不卡死。这些不是锦上添花的功能而是生产环境调试的刚需。如果你正被“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.xPython 版进入维护模式所有新功能、安全补丁、YAML 规范支持只发布在 v2.xGo 版。这意味着哪怕你今天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.52023 年 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_VERSIONv2.18.1 elif [[ $DOCKER_API 1.44 ]]; then COMPOSE_VERSIONv2.20.2 else COMPOSE_VERSIONv2.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_64ARM64 服务器请换为 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_INTERFACEeth0 - TZAsia/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变量TZAsia/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中的-aappend至关重要漏掉会导致用户被踢出其他组如sudo组引发权限灾难。4. 常见问题与排查技巧实录那些官方文档不会写的血泪教训4.1 问题速查表高频报错与一招解决报错信息根本原因解决方案实测耗时docker-compose: command not foundPATH未包含/usr/local/bin或安装路径错误echo $PATH检查确认/usr/local/bin在其中若缺失export PATH/usr/local/bin:$PATH并写入~/.bashrc2 分钟ERROR: Version in ./docker-compose.yml is unsupporteddocker-compose.yml使用了新版语法如profiles但 Compose 版本太低docker-compose --version查版本降级docker-compose或升级docker-compose.yml的version字段如从3.9改为3.85 分钟ERROR: failed to solve: rpc error: code Unknown desc failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount.../Dockerfile: no such file or directorydocker compose build时上下文路径错误Dockerfile 不在指定目录docker compose build --no-cache --progressplain .加--progressplain看详细路径确认Dockerfile与docker-compose.yml在同一目录或用-f指定正确路径8 分钟ERROR: for jellyfin Cannot create container for service jellyfin: invalid mount config for type bind: bind source path does not existvolumes中宿主机路径不存在如./config目录未创建mkdir -p ./config ./media创建所有挂载点目录再docker compose up -d1 分钟ERROR: Service jellyfin failed to build: The command /bin/sh -c apt-get update returned a non-zero code: 100构建时网络超时或 apt 源不可达docker compose build --no-cache --build-arg http_proxyhttp://your-proxy:3128如有代理或临时换国内源在Dockerfile中RUN sed -i s/archive.ubuntu.com/mirrors.tuna.tsinghua.edu.cn/g /etc/apt/sources.list15 分钟4.2 “ubuntu 20.04 cc-switch” 类问题显卡驱动与容器 GPU 加速的隐性冲突网络热词里出现的ubuntu 20.04 cc-switch指的是 Ubuntu 20.04 的 NVIDIA 显卡驱动切换工具nvidia-prime。这与 Docker Compose 有何关系当你部署jellyfin或xinfenenceAI 推理服务时如果想启用 GPU 硬解如--gpus all就会触发这个冲突。现象是docker compose up启动容器后nvidia-smi在容器内不可见日志报failed to initialize NVML: Unknown Error。根本原因在于cc-switch切换的是宿主机 X11 图形会话的驱动而 Docker 的--gpus机制需要直接访问/dev/nvidia*设备文件和libnvidia-container运行时。解决方案分三步确认宿主机 NVIDIA 驱动已正确安装nvidia-smi在宿主机终端必须能输出 GPU 信息安装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在docker-compose.yml中启用 GPUservices: 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-configGerrit 是代码审查系统部署时需连接外部 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.yml4.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_PLUGINmysql_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_VERSIONv2.12.2 ;; 1.42) COMPOSE_VERSIONv2.15.1 ;; 1.43) COMPOSE_VERSIONv2.18.1 ;; 1.44) COMPOSE_VERSIONv2.20.2 ;; *) COMPOSE_VERSIONv2.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是最直接的诊断工具但新手常犯两个错误一是不加-ffollow看不到实时日志二是不加--tailN日志太多刷屏。正确姿势是# 实时跟踪 jellyfin 服务的最后 100 行日志 docker compose logs -f --tail100 jellyfin # 跟踪所有服务的日志用服务名前缀区分 docker compose logs -f --tail50 --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 权限能直接操作宿主机内核模块、网络栈一旦容器被攻破整台服务器沦陷。替代方案是精准授权