提示下面所有示例中的镜像名、服务名、路径、端口均为演示用途实际部署时按自己的项目替换。涉及密钥的配置一律不要写进公开的版本库。1. 先把两件事拆开看参数化启动与数据卷挂载各自解决什么1.1 镜像本身是“死”的麻烦全出在运行时输入Docker 的价值主张里最常被挂在嘴边的一句是“一次构建到处运行”但真正在一线折腾过的人都知道镜像只是把操作系统层、运行时、依赖和业务代码打了个包它是只读的、静态的、不会自己变。镜像跑起来之后要变成一个能对外服务的容器还需要一大堆外部输入监听哪个端口、连哪个数据库、密钥是什么、配置文件从哪来、业务数据写到哪里去、日志落在宿主机的什么位置、容器挂了要不要自动重启、给它多少内存多少 CPU。这些东西镜像里不可能写死写死了就失去了“到处运行”的意义。于是问题就变成了这些外部输入该怎么交给容器最原始的做法是每次上线手敲一长串docker run命令参数从聊天记录里翻、从上一台机器的history里翻、从某个同事的笔记里翻。这种做法在单机单容器的时候勉强能用一旦容器数量上去、环境从测试切到生产、或者半年后需要重建一次你就知道什么叫“考古式运维”了。参数化启动要干的事就是把这些外部输入从命令行里剥离出来变成一组有名字、有默认值、有校验、可版本管理的配置项。数据卷挂载要干的事则是把容器运行过程中产生或依赖的、必须活得比容器更久的那部分数据放到容器生命周期之外。这两件事看起来一个管“进”一个管“出”实际上是一体两面参数决定了容器怎么起挂载决定了容器起了之后数据落在哪、能不能留住、下次重建还能不能接上。1.2 参数化启动的价值不在“少打几个字”很多人第一次接触参数化直观感受就是“命令变短了”这其实是最不重要的一点。我把自己踩过的坑归拢一下参数化真正解决的是四类问题。第一类是可复现性。同一份配置在测试机、预发机、生产机上跑出来的容器应该是等价的差异只应该体现在少数几个明确声明的变量上比如数据库地址、副本数、日志级别。如果每次启动都是手敲命令那“等价”这件事根本无从验证只能靠人肉比对而人肉比对在凌晨三点是极不可靠的。第二类是可审计。参数写进配置文件、进了版本库谁在什么时候改了哪个值、为什么改都有记录可查。手敲的命令没有历史出了问题只能靠回忆回忆是世界上最不可靠的日志。第三类是减少漂移。所谓配置漂移就是线上实际运行的状态和文档里写的状态逐渐偏离。漂移的来源往往特别琐碎某次紧急修 bug 临时加了个环境变量、某次排查问题手动改了端口、某次重启顺手换了个挂载路径……这些临时动作没人记录几个月后线上就跑着一个谁也不认识的容器。参数化把“唯一入口”固定下来任何变更都必须改配置、走流程漂移的空间被大幅压缩。第四类是降低认知负担。一个新人接手项目最怕看到的是“你先这样那样跑起来具体参数问某某”。有了成型的启动配置和清晰的变量说明他能在半小时内把整套服务在本机拉起来这对团队的长期效率影响巨大。1.3 数据卷挂载划定了容器的“生命周期边界”容器设计哲学里有一条很重要的原则容器应该是无状态的、可随时丢弃重建的。这条原则没错但现实里绝大多数服务都是有状态的——数据库要存数据、应用要写日志、上传的文件要落盘、证书要读进来。这些有状态的部分如果留在容器的可写层里会带来三个直接后果容器一删数据就没了、镜像提交会让镜像体积膨胀、多个容器之间无法共享。数据卷挂载就是用来把这条边界画清楚的。容器的可写层只承载临时文件所有需要跨容器生命周期存在的东西一律挂到容器外面。这条规则听起来简单但它直接决定了你的备份策略、迁移方案和故障恢复时间。我见过太多团队业务代码写得挺规范但数据目录还放在容器可写层里某次误操作docker rm -f之后恢复靠的是三天前的一份手工导出的 SQL那三天里的数据全部蒸发。所以这两件事必须放在一起设计参数决定容器以什么姿态启动挂载决定它的数据在哪落地。只做参数化不做挂载规划容器的重建成本会高得离谱只做挂载不做参数化你依然在靠手敲命令维护一个脆弱的系统。2. 参数化启动的完整拆解从 docker run 到可复用的启动配置2.1 参数分层哪些必填、哪些调节、哪些慎用docker run的参数有几十个新手最容易犯的错误是照抄一条长命令却不知道每个参数意味着什么。我习惯把它们分成三层这样在整理配置的时候心里有数。层级参数作用处理建议必填基础层-d、--name、镜像与标签后台运行、容器命名、确定版本容器名要有业务语义标签禁止用latest必填基础层-p/--publish、-v/--mount端口暴露、数据挂载端口尽量绑到 127.0.0.1 再由外层转发调节层-e、--env-file注入环境变量统一走 env 文件不写在命令行里调节层--restart、--network重启策略、网络归属生产用unless-stopped或always调节层--health-cmd系列健康检查一定要写否则编排层无法判断真实状态调节层--memory、--cpus、--pids-limit资源约束不设上限的容器迟早会拖垮宿主机慎用层--privileged、--cap-add提权能不用就不用确需使用要写清理由慎用层--nethost、--pidhost共享宿主机命名空间破坏隔离仅限特定场景慎用层--rm退出即删除有状态服务绝对不能用这张表里我最想强调的是--name和标签这两条。容器名不是随便起的它应该能一眼看出这是哪个环境、哪个服务、哪个序号比如prod-order-api-01。标签更是如此latest在生产环境基本等于“我不知道我跑的是什么版本”回滚的时候你连该回到哪个镜像都说不清。用具体的版本号或者 Git 提交短哈希成本极低收益极高。资源约束那一条也值得多说两句。Docker 默认对容器几乎没有资源限制一个内存泄漏的服务能把宿主机吃到 OOM然后内核的 OOM killer 可能会挑一个“看起来最占内存”的进程杀掉那个进程未必是罪魁祸首。给每个容器设置--memory和--memory-swap本质上是在给故障划定爆炸半径让问题局限在一个容器里而不是扩散到整台机器。2.2 环境变量注入的三种方式与取舍环境变量是最常用的参数传递方式原因很简单几乎所有语言、所有框架都支持从环境变量读配置不需要改代码。注入方式有三类各有适用场景。第一种是命令行-e KEYVALUE。适合临时调试比如临时把日志级别调成 debug 排查问题。缺点非常明显值会出现在docker inspect的输出里、出现在 shell 历史里、出现在进程列表里密码类的值这么传等于公开。第二种是--env-file指定文件。这是我在单机部署里最推荐的方式一个服务一个文件权限设成 600内容纳入配置管理但密钥除外。这个文件有几点语法细节要注意每行一个KEYVALUE#开头是注释行内的#不是注释值里有空格要加引号值里的引号不会被解析掉而是原样保留。我就被这个“行内 # 不是注释”坑过一次一个带#的密码后半段被当成了值的一部分排查了半天才反应过来不是程序的问题。第三种是编排工具里的environment和env_file字段。适合容器数量多、有依赖关系的场景后面实操部分会详细写。注意环境变量不是保管密钥的地方。容器内的环境变量可以被同宿主机的其他高权限进程读取也会被各种诊断命令打印出来。真要有敏感信息走文件挂载 严格权限或者使用专门的密钥管理机制不要图省事塞进-e。还有一个特别容易被忽略的点环境变量的类型全是字符串。你要是写MAX_CONN100程序里拿到的就是字符串100某些语言的配置库会自动转换某些不会于是你得到的是“看起来配置生效了但实际行为诡异”的结果。稳妥的做法是在启动脚本里做一次显式校验把必填项和数字项都检查一遍缺了就带着明确信息退出而不是让服务带着错误配置跑起来。2.3 用启动脚本把参数收敛到一处当参数多到十几个的时候直接拼docker run字符串会非常痛苦尤其是路径里带空格、变量可能为空的时候。我的做法是写一个薄薄的 shell 脚本做三件事设默认值、校验必填、用数组拼参数。#!/usr/bin/env bash set -euo pipefail APP_NAME${APP_NAME:-order-api} APP_ENV${APP_ENV:-dev} IMAGE_TAG${IMAGE_TAG:?必须指定镜像标签} DATA_DIR${DATA_DIR:-/srv/${APP_NAME}/data} HOST_PORT${HOST_PORT:-8080} MEM_LIMIT${MEM_LIMIT:-512m} if [[ ! -d $DATA_DIR ]]; then echo 数据目录不存在: $DATA_DIR 2 exit 1 fi mkdir -p ${DATA_DIR}/logs ARGS( --detach --name ${APP_NAME}-${APP_ENV} --restart unless-stopped --memory ${MEM_LIMIT} --publish 127.0.0.1:${HOST_PORT}:8080 --mount typebind,source${DATA_DIR},target/app/data --mount typebind,source${DATA_DIR}/logs,target/app/logs --env-file ./config/${APP_ENV}.env --health-cmd curl -fsS http://127.0.0.1:8080/health || exit 1 --health-interval 15s --health-timeout 3s --health-retries 3 ) docker run ${ARGS[]} registry.local/${APP_NAME}:${IMAGE_TAG}这段脚本里有几个设计点值得解释。${IMAGE_TAG:?}是 bash 的参数展开语法变量为空时直接报错退出比后面跑到一半才失败要好。路径一律用绝对路径因为docker run的相对路径是按调用它的当前目录解析的你在不同目录下执行脚本会挂载到完全不同的地方这个坑非常隐蔽。参数用数组而不是字符串拼接是为了避开引号和空格解析的问题——docker run $ARGS这种写法在参数里出现空格时会静默拆错用${ARGS[]}才是安全的。脚本本身只是入口真正的配置值放在config/${APP_ENV}.env里不同环境各一份公共部分抽出来。这样一来“这套服务依赖哪些配置”这个问题有了明确答案看目录结构就知道了不需要去问人。2.4 端口映射与网络模式几个必须写进规范的选择端口映射看起来是-p 宿主:容器这么简单实际上有两个默认行为害过不少人。第一个是默认绑定到所有网卡。-p 8080:8080等于监听0.0.0.0:8080只要宿主机的防火墙没拦住这个端口对全网可见。很多“数据库被扫”的事故就是这么来的。显式写-p 127.0.0.1:8080:8080只让本机访问再由反向代理对外提供服务是最省心的做法。第二个是容器内进程监听的地址。如果应用在容器里绑的是127.0.0.1而不是0.0.0.0端口映射就不会生效因为容器内的 loopback 只在容器自己的网络命名空间里有效。表现是宿主机curl不通但docker exec进去curl localhost又是通的。这个现象新手很难自己定位记住一句话就行容器里的服务要监听0.0.0.0或::。网络模式方面默认的 bridge 网络适合绝大多数场景容器之间通过自定义网络的服务名互相访问比记 IP 靠谱得多。host模式能省掉一层 NAT性能略好但代价是端口直接占用宿主机、隔离性变差我一般只在特定性能敏感场景才用。还有一种情况是容器需要访问宿主机上的服务用host.docker.internal这个名字部分平台需要额外声明比硬编码网关 IP 更稳。3. 数据卷挂载三种方式的差异、权限坑与备份策略3.1 bind mount、volume、tmpfs 的边界在哪里Docker 提供三种挂载方式选错方式带来的麻烦往往在几个月后才爆发所以我倾向于一开始就把边界划清楚。对比项bind mountnamed volumetmpfs数据位置宿主机任意路径Docker 管理目录内存跨平台一致性差不同系统路径语义不同好好读写性能在部分桌面系统上偏慢接近原生最快是否随容器删除否否需显式删卷是备份便利性直接拷贝目录即可需借助临时容器不适用典型用途配置文件、证书、代码热加载数据库数据、对象存储后端临时缓存、会话判断方法可以简化成三句话需要人直接看、直接改的配置文件、证书、本地开发时的代码目录用 bind mount需要长期保存、由程序自己管理、不想关心宿主机路径的数据库、消息队列的数据目录用 named volume纯临时、丢了也无所谓、希望走内存加速的用 tmpfs。这里有个特别容易被误解的行为差异当 named volume 是空的第一次挂载到容器时Docker 会把镜像里对应目录的内容复制进卷里而 bind mount 不会做这个初始化宿主机目录是空的容器里看到的就是空的。这个差异导致的典型故障是用 bind mount 挂数据库数据目录宿主机目录新建为空容器启动时发现“数据目录存在但没有初始化”于是报错退出。用 named volume 就没这个问题。知道这个机制之后遇到类似报错就不会一头雾水了。3.2 权限与属主容器挂载事故的高发区挂载相关的报错里Permission denied大概能占一半。根源在于容器内的进程以某个 UID 运行而这个 UID 在宿主机上对应的用户可能对挂载目录没有写权限。先说最常见的情况。很多官方镜像会创建一个非 root 用户来跑服务比如 UID 1000。你 bind mount 了一个宿主机目录这个目录的属主是 root权限是 755那么容器内的 UID 1000 就没有写权限服务启动失败。解决办法有三个把宿主机目录chown给对应的 UID、启动容器时用--user指定一个有权限的 UID、或者接受用 root 跑不推荐。我不推荐第三种的原因很实际用 root 跑容器它写出来的文件在宿主机上也是 root 属主。某天你想用普通账号清理日志、修改配置发现改不动得sudo然后一不小心sudo删错东西或者用 root 跑了个脚本把目录权限整个改乱。这种小事故累积起来非常消耗精力。# 建立目录并把属主给到容器内运行用户对应的 UID sudo mkdir -p /srv/order-api/{data,logs,config} sudo chown -R 1000:1000 /srv/order-api/data /srv/order-api/logs sudo chmod 750 /srv/order-api/data # 启动时显式声明运行用户避免容器内外 UID 不一致 docker run -d --name order-api \ --user 1000:1000 \ --mount typebind,source/srv/order-api/data,target/app/data \ registry.local/order-api:1.4.2还有个隐性问题是UID 在宿主机上不存在。容器里 UID 1000 可能叫app宿主机上 UID 1000 可能叫别的或者根本没人用。权限判断只看数字不看名字所以只要数字对得上权限就没问题ls -l显示成一串数字也不代表出错。反过来如果你在宿主机上看到文件属主显示成 1000别急着重装系统先确认这是不是容器写入的。注意启用 SELinux 的环境里bind mount 还需要打标签否则即使权限位对了也会被拒绝访问。挂载时加上:z共享或:Z独占后缀即可只用于 bind mountnamed volume 不需要。3.3 只读挂载、传播模式与子路径配置文件、证书这类内容容器只需要读那就应该挂成只读。--mount typebind,source...,target...,readonly或者-v ...:ro一行的事收益是容器里的程序即使有 bug 也改不了这些文件少一种故障可能。传播模式propagation属于用得少但需要知道的东西。默认的rprivate意味着宿主机上某个挂载点下面再挂载新的文件系统容器里看不到。如果有“宿主机插个盘容器里要能读到”这类需求才需要改成rshared同时宿主机上那个挂载点本身也要是 shared 的。绝大多数业务用不到遇到“为什么宿主机上新挂的目录容器里是空的”时能想起来就行。volume-subpath是相对新的能力解决的是“一个卷里只挂其中一个子目录”的问题配合对象存储类的卷使用比较合适。日常业务里老老实实一个服务一个数据卷比研究这些高级特性实用得多。3.4 备份、迁移与清理别等到出事才想named volume 的数据在 Docker 管理目录下通常是/var/lib/docker/volumes/卷名/_data理论上直接拷贝也行但我不建议直接操作这个目录原因是不受 Docker 管理容易和运行中的容器状态不一致。标准做法是起一个临时容器挂载同一个卷用 tar 打包。# 备份 docker run --rm \ --mount typevolume,sourceorder-api-data,target/data,readonly \ --mount typebind,source/srv/backup,target/backup \ alpine:3.19 \ tar czf /backup/order-api-data-$(date %Y%m%d-%H%M).tar.gz -C /data . # 恢复 docker run --rm \ --mount typevolume,sourceorder-api-data,target/data \ --mount typebind,source/srv/backup,target/backup,readonly \ alpine:3.19 \ tar xzf /backup/order-api-data-20240101-0300.tar.gz -C /data备份这条命令里有两点值得说。一是readonly备份过程绝不该有写操作加了这个参数心里踏实。二是时间戳命名比backup.tar.gz这种固定名字强太多后者第二次执行就把第一次覆盖了真出事的时候你会发现只有一个最新备份而问题可能昨天就产生了。清理方面docker volume prune会删掉所有“没有被任何容器使用”的卷这个“没有容器使用”的判断在容器刚被删掉的瞬间就能成立所以误删风险不小。我的习惯是先docker volume ls看看确认哪些是明显废弃的再针对性docker volume rm。磁盘占满这类事故排查顺序一般是日志文件容器内或挂载目录里的日志没做轮转→ 悬空镜像旧的构建产物→ 停止的容器可写层里留了东西→ 无主卷。日志永远排第一因为它增长最快。4. 完整实操一套可复现、可迁移的参数化部署4.1 目录规划先定结构再写配置我把部署相关的文件按“配置与数据分离”的原则摆放这样升级、备份、迁移各有明确的边界/srv/order-api/ ├── config/ │ ├── common.env # 各环境共用 │ ├── dev.env # 开发环境 │ └── prod.env # 生产环境权限 600 ├── data/ # 业务数据挂载进容器 ├── logs/ # 日志挂载进容器 ├── backup/ # 备份落盘位置 └── compose.yamlconfig目录里放变量data和logs放运行期产物backup单独一个位置方便做异地同步。这套结构的好处是迁移到新机器把整个/srv/order-api打包带走改一下prod.env里的地址和端口就能跑起来不需要回忆任何命令。4.2 compose 文件把参数化的思路落成配置单容器用脚本就够了一旦有依赖关系应用 缓存 数据库用 compose 管理更清楚。下面这份去掉业务细节的版本重点展示参数是怎么从.env注入、卷是怎么声明的。services: api: image: registry.local/order-api:${IMAGE_TAG} container_name: ${APP_NAME}-${APP_ENV} restart: unless-stopped env_file: - ./config/common.env - ./config/${APP_ENV}.env environment: APP_ENV: ${APP_ENV} LOG_LEVEL: ${LOG_LEVEL:-info} ports: - 127.0.0.1:${HOST_PORT}:8080 volumes: - type: bind source: ./data target: /app/data - type: bind source: ./logs target: /app/logs - type: bind source: ./config/certs target: /app/certs read_only: true depends_on: cache: condition: service_healthy deploy: resources: limits: memory: ${MEM_LIMIT:-512m} cpus: 1.0 healthcheck: test: [CMD, curl, -fsS, http://127.0.0.1:8080/health] interval: 15s timeout: 3s retries: 3 start_period: 30s cache: image: cache-server:7.2 restart: unless-stopped command: [--maxmemory, ${CACHE_MAXMEM:-256mb}, --maxmemory-policy, allkeys-lru] volumes: - cache-data:/data healthcheck: test: [CMD, cache-cli, ping] interval: 10s timeout: 2s retries: 5 volumes: cache-data: name: ${APP_NAME}-cache-data这份配置里有几个刻意的选择。start_period设了 30 秒是因为应用启动要加载配置、连数据库这段时间内的健康检查失败不应该触发重启很多人漏了这个参数结果容器陷入“启动-检查失败-重启”的死循环。depends_on配了condition: service_healthy比默认的“启动顺序依赖”严格得多默认只保证容器起来了不保证里面的服务能用了。资源限制写在这里是为了让编排层在资源紧张时有依据做调度。.env文件放在 compose 文件同级目录compose 会自动加载它做变量替换# .env APP_NAMEorder-api APP_ENVprod IMAGE_TAG1.4.2 HOST_PORT8080 MEM_LIMIT768m CACHE_MAXMEM512mb LOG_LEVELinfo注意这里的层级.env负责 compose 文件里的${}替换env_file里的是注入容器的环境变量。两者格式类似但用途不同混起来容易出“为什么改了没生效”的问题——如果某个变量只在env_file里改了但.env里也有同名项实际注入的是env_file的内容反过来如果只在.env里改了容器里不会有这个变量除非 compose 文件里显式environment转发。这个规则建议在团队内部写成一句话贴在文档里。4.3 启动、验证与日志三个动作形成闭环启动本身没什么技术含量关键在启动之后怎么确认它是真的好了。# 1. 拉取镜像并启动 docker compose --env-file .env pull docker compose up -d # 2. 确认容器状态与健康检查结果 docker compose ps docker inspect --format {{.State.Health.Status}} order-api-prod # 3. 验证挂载是否按预期生效 docker inspect --format {{json .Mounts}} order-api-prod | python3 -m json.tool # 4. 查看最近日志带时间戳 docker compose logs --tail200 --timestamps api第二步的健康检查状态有三种starting、healthy、unhealthy。刚起来的几十秒内是starting属于正常如果一直卡在starting超过start_period加几轮检查基本就是服务真的没起来。这时候别急着看应用日志先docker exec进去确认端口有没有在监听因为“进程活着但端口没起来”和“进程直接退出了”是完全不同的排查方向。第三步的Mounts输出非常有用能直接看到每个挂载点的Type、Source、Destination、RW。我遇到过好几次“挂载路径写错一个字符导致挂到了空目录”的情况容器照常起来数据写进了容器可写层直到重建时才暴露。养成启动后核对一遍挂载的习惯成本几秒钟。日志方面--tail和--timestamps是我几乎每次都会带的。带时间戳能快速对齐“某次请求失败”和“某次重启”的时间关系没有时间戳的日志在排查时序问题时价值大打折扣。另外建议给 Docker 的日志驱动设一个上限默认的 json-file 驱动不限制大小日志能长到把磁盘吃满{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }这段配置放在/etc/docker/daemon.json里对所有容器生效。只对新建的容器生效已有容器需要重建这点要提前知道否则会以为配置没写对。4.4 升级与回滚把“改配置”变成可逆动作升级的流程我固定成四步目的只有一个任何时候都能一分钟内回到上一个可用版本。改.env里的IMAGE_TAG改成新版本号docker compose pull拉新镜像docker compose up -dcompose 会识别到镜像变化并重建对应容器docker compose ps加健康检查确认观察几分钟日志。出问题时把IMAGE_TAG改回上一个版本再执行一次up -d就完成了回滚。整个过程不涉及任何手工命令也不依赖记忆。前提是每个版本都有明确的标签且旧镜像没有被清理掉。所以我一般会保留最近三到五个版本的镜像用带条件过滤的清理命令而不是prune -a后者会把所有未使用的镜像全删回滚能力直接归零。数据结构变更的升级要额外小心。如果新版本需要改表结构而回滚时旧版本不兼容新结构那“改标签回滚”就不成立了。这种情况我的做法是应用层先兼容新旧两种结构跑一个版本做数据迁移确认稳定后再发一个只支持新结构的版本。多花一次发布换回来的是随时可回滚的底气。5. 常见问题排查速查表与避坑经验5.1 启动即退出先看退出码再看日志容器起来就退出是最常见的一类问题。排查顺序建议固定下来避免东一榔头西一棒子。现象优先排查常见原因退出码 0秒退启动命令主进程是前台阻塞型的被写成了后台运行或CMD是bash这类交互程序退出码 1有报错日志应用日志配置缺失、连不上依赖、端口占用退出码 137内存超过--memory限制被 OOM 杀掉退出码 139段错误二进制与架构不匹配或依赖的本地库版本不对退出码 143收到 SIGTERM被外部停止或健康检查失败触发编排层重启状态unhealthy但没退出健康检查配置检查命令里的地址写错比如用了 127.0.0.1 但服务监听在外网卡、超时太短退出码 0 秒退这条我单独说一下因为它太常见了。容器的生命周期绑定的是 PID 1 进程PID 1 退出容器就结束。如果你在CMD里写的是service xxx start tail -f /dev/null这类容器能活着但信号传递会有问题如果不小心写成了service xxx start启动脚本执行完就退出容器自然就停了。正确做法是让服务进程自己前台运行或者用exec把信号正确传递下去。健康检查失败但容器没退出这一类问题的隐蔽性更强因为从外面看容器是 running 状态编排层却一直认为它不可用。除了地址写错还有一个常见原因是检查命令依赖的工具镜像里没有比如用curl但基础镜像里只有wget检查命令直接报了 command not found被判为失败。写健康检查之前先用docker exec手动跑一遍那条命令能省掉很多来回。5.2 挂载与权限按这个顺序查八成就定位了挂载类问题的错误信息往往很笼统按顺序排查效率最高。# 1. 宿主机上的路径是否存在、是否是绝对路径 ls -ld /srv/order-api/data # 2. 宿主机目录属主与权限 stat -c %U %G %a /srv/order-api/data # 3. 容器内进程以什么用户运行 docker exec order-api-prod id # 4. 容器内看到的目录属主与权限 docker exec order-api-prod ls -ld /app/data # 5. 容器内实际能否写入 docker exec order-api-prod sh -c touch /app/data/.writetest rm /app/data/.writetest这五步走完问题基本就清楚了。第 2 步和第 4 步的属主数字对不上就是权限问题第 4 步显示目录是空的而宿主机上有文件大概率是挂载路径写错或者容器内有别的同名目录被覆盖了第 5 步失败但前面都正常那要看是不是 SELinux 或者只读挂载导致的。还有一个很隐蔽的情况容器内目标路径上原本有内容bind mount 之后被整个遮盖。比如镜像里/app/config目录自带一份默认配置你挂了一个宿主机空目录上去容器里看到的就是空目录程序读不到配置直接报错。这个行为不是 bug是挂载的本质——挂载点是覆盖不是合并。遇到“明明镜像里有这个文件容器里却找不到”的时候先怀疑挂载。5.3 数据与磁盘出问题时最疼的两类数据相关的问题我总结成三句话贴在团队文档里卷不要用相对路径声明、删容器前先确认数据在哪、备份要验证过恢复流程。第一条是因为 compose 里的相对路径是按 compose 文件所在目录解析的换个目录执行docker compose down再up可能就指向了另一个路径。用绝对路径或者命名卷没有歧义。第二条是习惯问题。docker rm -f之前先docker inspect看一眼挂载确认数据在宿主机上有落点。养成习惯之后删容器就不再是心惊胆战的操作。第三条最容易被跳过。备份文件生成成功不等于能恢复压缩包在传输过程中损坏、卷里的数据结构变了、恢复命令的路径写错了这些问题只有真的恢复一次才会暴露。我的做法是每季度挑一个非核心环境做一次完整恢复演练把它当成常规动作而不是应急动作。磁盘方面除了前面说的日志轮转还有两个容易被忽视的增长点一是停止的容器它们的可写层还占着空间docker ps -a里一堆 Exited 状态的容器加起来可能好几个 G二是构建缓存频繁构建的环境里缓存能涨到几十 G。定期清理是必要的但清理命令要带上条件比如按时间过滤别一上来就prune -a把所有东西都清掉。# 查看各类空间的占用明细 docker system df -v # 清理 7 天前的构建缓存 docker builder prune --filter until168h # 清理已停止超过 7 天的容器 docker container prune --filter until168h最后说一个我自己的习惯。每套部署配置写完我会刻意做一次“冷启动演练”把容器全删、数据卷保留、在一台干净的机器上按文档从头走一遍。这个过程能暴露出来的问题往往比看十遍配置要多。参数化也好、挂载规划也好最终要检验的不是配置写得多漂亮而是别人能不能照着它把服务跑起来以及出问题的时候能不能快速回到已知状态。这两件事做到了剩下的都是细节。