Docker+Spring Boot+Redis+RabbitMQ部署BI看板

1. 这套四件套到底在解决什么问题

先把话说在前面：Docker + Spring Boot + Redis + RabbitMQ 这个组合，很多人第一眼看到会觉得是"堆技术栈"，尤其是刚接手一个数据看板类项目的时候，很容易产生一种错觉——是不是把能加的中间件都加上了显得专业？我一开始也这么想，直到真正把一个 BI 项目从单机脚本跑成能对外服务的系统，才明白这四个东西各自卡在一条非常具体的痛点上，少一个都不行，多一个也没必要。

BI 项目跟普通的增删改查后台有个本质区别：它的读操作极重、计算极慢、数据源极杂。一张看板背后可能是三五个业务库的联表聚合，跑一次几十秒到几分钟不等；用户打开页面的时候不会等你算完，他会反复刷新、切换筛选条件、导出表格。如果每次都实时打到底层数据库，轻则把业务库拖慢，重则直接引发线上告警。所以这类项目天然需要三样东西：一个能把重计算从请求链路里摘出去的异步通道（RabbitMQ）、一个能扛住高频重复读取的缓存层（Redis）、一个能保证"我这台机器跑得起来，别人那台也跑得起来"的运行环境（Docker），以及一个把业务逻辑组织清楚的应用框架（Spring Boot）。

我用一个生活化的类比串一下这四者的关系。把 BI 系统想象成一家餐厅：Spring Boot 是前厅和后厨的组织架构，决定了点单、传菜、出餐怎么流转；Docker 是把整间厨房标准化打包成集装箱，搬到哪里都能原样展开；Redis 是备餐台上提前切好的配菜，客人点单时直接抓一把就走，不用现切；RabbitMQ 是传菜口的单据夹，前厅把复杂的定制单夹上去，后厨按顺序慢慢做，前厅不用站在窗口干等。缺了传菜夹，前厅和后厨就会互相堵死；缺了备餐台，每单都现切，出餐速度直接崩。

这篇内容写给谁？我给三类人画个像。第一类是后端开发，手上有个 BI 或者报表类项目要上线，本地跑得好好的，一到服务器就各种环境问题；第二类是刚接触容器化的同学，会写 Dockerfile 但不知道一个多服务项目该怎么编排、数据怎么持久化、启动顺序怎么控制；第三类是负责交付的人，需要把这套东西部署到客户的机器上，对方环境不明、网络受限、还要能反复重装。如果你属于这三类中的任何一类，下面的内容基本能覆盖你 80% 的疑问。

需要提前说明的是，本文涉及的所有具体配置、镜像版本、参数取值，都是基于我在实际项目里反复调过的常见实践给出的参考值，不是唯一正解。不同规模的项目取舍会不一样，比如日活几十人的内部看板，Redis 用单机就够了；如果是几百人同时在线并且有大量定时刷新，那缓存策略和队列的并发度就得重新算。我会在每个环节标注出"为什么这么选"以及"什么情况下要改"，你按自己的场景对号入座。

还有一点很关键：这类项目的部署难点从来不在"把四个服务跑起来"，而在"跑起来之后能不能稳定、能不能重启、能不能迁移"。我见过太多人 docker run 四条命令跑通了截图发群里，结果服务器一重启，数据全没了，队列里的任务全丢了，缓存和数据库状态不一致，页面白屏。所以接下来的内容会花大量篇幅在持久化、启动依赖、健康检查、故障恢复这些"不出彩但致命"的地方。

2. 服务编排前必须先想清楚的三件事

动手写 docker-compose.yml 之前，有三件事如果不提前想明白，后面必然返工。这三件事分别是：数据落在哪里、服务之间怎么通信、启动顺序怎么保证。听起来像是老生常谈，但在 BI 项目里每一条都有它的特殊性。

2.1 数据落盘：哪些必须持久化，哪些丢了也无所谓

BI 项目的数据可以粗暴分成四类，处理方式完全不同。第一类是业务元数据，比如看板的配置、图表的定义、用户的权限，这些通常存在关系型数据库里（MySQL 或 PostgreSQL），绝对不能丢。第二类是计算结果，比如昨天跑好的日报汇总表，丢了可以重跑，但如果重跑一次要半小时，那最好也持久化。第三类是缓存，Redis 里存的东西，理论上全是可再生的，丢了系统会变慢但不会出错。第四类是队列消息，正在排队的报表任务，丢了就意味着用户点了"生成"但永远等不到结果。

基于这个分类，我的做法是：数据库和 Redis 的数据目录、RabbitMQ 的队列数据，全部挂载到宿主机或者命名卷上；应用本身的 jar 包不挂载，打进镜像里。这里有个容易踩的坑——很多人图方便，把整个项目目录用 bind mount 挂进去，改代码不用重新 build。开发阶段这么干确实爽，但上线绝对不能这么玩，因为容器里的文件权限、路径、JVM 的工作目录都可能跟宿主机不一致，我在一个项目里遇到过挂载进去的配置文件因为 CRLF 换行符导致 YAML 解析失败，排查了整整两个小时。

具体到挂载方式，我倾向于用命名卷（named volume）而不是宿主机目录绑定，原因是命名卷由 Docker 管理，跨平台表现一致，备份可以用docker run --rm -v volume_name:/data -v $(pwd):/backup alpine tar czf /backup/backup.tar.gz /data这种通用方式打包。如果你有明确的运维规范要求数据必须落在指定目录，那用 bind mount 也没问题，但要记得先chown好属主，否则容器内的非 root 用户写不进去。

2.2 网络通信：容器名就是主机名，别再写 localhost

这是新手最容易栽的地方，没有之一。Spring Boot 的配置文件里写着spring.redis.host=localhost，本地跑得好好的，一进容器就报连接拒绝。原因很简单：容器里的 localhost 指的是容器自己，不是宿主机，也不是隔壁的 Redis 容器。在 Docker Compose 创建的自定义网络里，每个服务名会被自动解析成对应的容器 IP，所以正确的写法是把 host 改成服务名，比如spring.redis.host=redis、spring.rabbitmq.host=rabbitmq、数据库地址写成jdbc:mysql://mysql:3306/xxx。

这个机制值得多说两句，因为它决定了你怎么组织配置文件。我的习惯是在application.yml里全部用环境变量占位，比如${REDIS_HOST:localhost}，冒号后面是默认值。这样本地开发不设环境变量就自动走 localhost，容器里通过 compose 的 environment 段注入REDIS_HOST=redis，一份配置两处复用，不用维护两套 profile。这个技巧看起来小，但能省掉大量"我本地是好的"的扯皮。

另外要注意端口暴露的范围。compose 里的ports是把容器端口映射到宿主机，expose只是声明在容器网络内可见。数据库、Redis、RabbitMQ 的管理端口，除非你真的需要从宿主机连上去调试，否则上线时不要映射到宿主机，尤其不要写成0.0.0.0:6379:6379。我见过不止一个项目把 Redis 端口直接暴露在公网上，还没设密码，结果被扫描到之后塞满了垃圾数据。正确做法是只把 Spring Boot 应用的端口映射出去，其余服务靠容器内部网络互通。

2.3 启动顺序：depends_on 不等于"等它准备好"

Docker Compose 的depends_on只保证启动顺序，不保证被依赖的服务已经可以接受连接。MySQL 容器启动了，但从启动到能接受 TCP 连接中间有好几秒甚至几十秒的初始化时间，这时候 Spring Boot 冲上去连，直接抛异常退出。这就是为什么很多人加了 depends_on 还是启动失败。

解决办法有三个层次，我说说我的取舍。最土的办法是给应用加重试，Spring Boot 连数据库本来就有重连机制，但 Redis 和 RabbitMQ 的客户端不一定那么宽容。稍微好一点的是在启动脚本里写一个 wait-for 循环，用nc -z或者curl轮询目标端口，通了再启动 java 进程。最规范的是用 healthcheck 配合depends_on的condition: service_healthy，让 Docker 帮你判断。我现在的标准做法是：数据库、Redis、RabbitMQ 全部配 healthcheck，应用服务用condition: service_healthy依赖它们，同时应用内部保留重试逻辑作为双保险。多写几行配置，换来的是"机器重启后自动全部拉起"这种确定性，非常值。

3. 逐个服务的配置细节与踩坑记录

这一节按服务拆开讲，每个服务我给出一份可以直接用的配置片段，重点讲那些文档里不写、但实际会卡住你的细节。所有配置基于 Compose 的 v3 语法，镜像版本建议锁死，不要用 latest。

3.1 MySQL：字符集、时区和初始化脚本

BI 项目里数据库的坑主要集中在三个地方。字符集必须是 utf8mb4，排序规则建议 utf8mb4_general_ci 或 utf8mb4_0900_ai_ci（取决于 MySQL 版本），否则中文看板名称、emoji 表情符号会存成问号。时区必须显式指定，容器默认是 UTC，而业务侧通常期望东八区，如果不设，你会发现页面上所有时间都差 8 小时，而且这种 bug 特别隐蔽，容易误判成前端问题。

mysql: image: mysql:8.0.35 container_name: bi-mysql restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_DATABASE: bi_platform TZ: Asia/Shanghai command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_general_ci - --default-time-zone=+08:00 - --max_connections=500 volumes: - mysql_data:/var/lib/mysql - ./init-sql:/docker-entrypoint-initdb.d:ro healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "-uroot", "-p${MYSQL_ROOT_PASSWORD}"] interval: 10s timeout: 5s retries: 10 start_period: 30s

关于max_connections，我给个估算思路。BI 项目的连接数不是按用户数算的，而是按"应用实例数 × 连接池大小 + 后台任务线程数"算。假设 Spring Boot 用 HikariCP，maximum-pool-size 设 20，应用部署 2 个实例，后台还有 5 个报表任务线程各开一个连接，那就是 45 个起步，留一倍余量设到 100 以上比较稳。但也要注意 MySQL 的内存占用和 max_connections 正相关，盲目调到 2000 反而可能 OOM，需要结合容器内存限制调。

docker-entrypoint-initdb.d这个目录是个好东西，里面的 .sql 或 .sh 文件只会在数据目录为空时执行一次，适合放建表语句和基础字典数据。但它有个陷阱：如果你后面改了初始化脚本，容器不会重新执行，因为数据目录已经有东西了。这是很多人困惑"为什么我加的字段没生效"的原因。改 schema 请老老实实用迁移工具（Flyway 或 Liquibase），初始化脚本只负责首次建库。

3.2 Redis：内存策略和持久化的权衡

Redis 在 BI 项目里的角色很明确——缓存查询结果和字典数据。既然是缓存，就一定要设过期时间和内存上限，否则内存一路涨到把容器撑爆。我的配置里必定包含maxmemory和maxmemory-policy allkeys-lru，这两个参数决定了内存吃满之后淘汰哪些 key。

redis: image: redis:7.2.4-alpine container_name: bi-redis restart: unless-stopped command: - redis-server - --appendonly - "yes" - --maxmemory - 1gb - --maxmemory-policy - allkeys-lru - --requirepass - ${REDIS_PASSWORD} volumes: - redis_data:/data healthcheck: test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"] interval: 10s timeout: 3s retries: 5

这里有个取舍要讲清楚：appendonly yes会开启 AOF 持久化，好处是重启后数据恢复得更完整，坏处是写性能有损耗并且 AOF 文件会持续增长。对纯缓存场景,其实可以不开启,反正数据可重建。但如果你的 Redis 里还存了一些"丢了会痛"的东西,比如分布式锁的令牌、短期的会话状态,那建议开启,并且配置appendfsync everysec,在性能和安全之间取个平衡。

还有一个细节:BI 的查询缓存 key 设计。我一般用看板ID:筛选条件哈希:数据版本号这样的结构,数据版本号在底表更新时递增,这样既能命中缓存,又能在数据变更后自动失效,不用去遍历删除 key。这个设计比单纯用 TTL 要精准得多,尤其是那种"数据每天凌晨更新一次,但白天要看实时"的场景,靠 TTL 根本对不齐。

3.3 RabbitMQ：管理界面、持久化队列与消息确认

RabbitMQ 是这套组合里最容易被低估的组件。很多人只是拿它做"发个消息就完事",结果发现任务丢了、消息重复消费了、队列堆积把内存吃光了。BI 项目的异步任务通常有三类:报表生成、数据同步、邮件通知,它们的可靠性要求不一样,队列要分开建。

rabbitmq: image: rabbitmq:3.12.10-management container_name: bi-rabbitmq restart: unless-stopped environment: RABBITMQ_DEFAULT_USER: ${MQ_USER} RABBITMQ_DEFAULT_PASS: ${MQ_PASSWORD} RABBITMQ_DEFAULT_VHOST: /bi volumes: - rabbitmq_data:/var/lib/rabbitmq ports: - "127.0.0.1:15672:15672" healthcheck: test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"] interval: 15s timeout: 10s retries: 5 start_period: 40s

镜像选带-management后缀的版本,自带网页管理界面,排查队列堆积特别方便。但注意端口映射我写的是127.0.0.1:15672:15672,只在宿主机本地可访问,公网碰不到。如果你需要远程看管理界面,用 SSH 隧道转发,不要把 15672 直接开到公网。

消息不丢需要三件事同时成立:队列声明为 durable、消息发送时设 deliveryMode 为持久化、生产者开启 confirm 回调。前两个是配置,第三个是代码。我在项目里吃过一次亏:队列是持久化的,但发送消息时用的是默认的瞬时模式,服务重启后队列还在,消息没了。Spring Boot 里对应的配置是spring.rabbitmq.publisher-confirm-type=correlated和publisher-returns=true,然后在 RabbitTemplate 上设置 confirm 回调,发送失败时打日志告警,这样至少能发现问题。

消费者这边,一定要手动 ack,并且配置spring.rabbitmq.listener.simple.acknowledge-mode=manual。自动 ack 的问题是消息一到消费者手里就被标记为完成,如果处理过程中抛异常,消息就永久丢了。手动 ack 虽然要写几行代码,但能保证"处理成功才确认",失败了可以让消息重回队列或者进死信队列。死信队列一定要建,这是我强烈建议的:给每个业务队列配一个x-dead-letter-exchange,消费失败超过重试次数的消息进死信,人工排查后再决定怎么处理。没有死信队列,失败的消息要么丢,要么无限重试把队列堵死。

3.4 Spring Boot 应用:多阶段构建与 JVM 参数

应用镜像我自己写 Dockerfile,不用现成的 openjdk 镜像直接扔 jar 进去。多阶段构建能把镜像从 600MB 压到 200MB 左右,而且运行阶段用 JRE 而不是 JDK,减少面积也减少安全面。

FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn clean package -DskipTests -B FROM eclipse-temurin:17-jre-jammy WORKDIR /app RUN groupadd -r appuser && useradd -r -g appuser appuser COPY --from=builder /build/target/*.jar app.jar RUN chown -R appuser:appuser /app USER appuser EXPOSE 8080 ENTRYPOINT ["java", \ "-XX:MaxRAMPercentage=75.0", \ "-XX:+UseG1GC", \ "-Djava.security.egd=file:/dev/./urandom", \ "-Duser.timezone=Asia/Shanghai", \ "-jar", "app.jar"]

几个参数值得解释。MaxRAMPercentage=75.0让 JVM 按容器内存限制的 75% 来分配堆,比写死-Xmx512m灵活得多,容器内存调大调小都不用改启动参数。用 G1 是因为 BI 应用里会有大对象(比如几十万行的查询结果),G1 对大堆和停顿控制更友好。user.timezone显式指定时区,和数据库时区保持一致,能避免一类非常恶心的日期偏移问题。

用非 root 用户运行这件事,很多人图省事直接用 root,但一旦容器被攻破,root 权限就是灾难。创建普通用户只需要三行,成本极低。注意chown要在USER之前执行,顺序反了会报权限错误。

还有一个坑:Dockerfile 里COPY pom.xml单独一层再mvn dependency:go-offline,是为了利用 Docker 的层缓存。只要 pom 不变,依赖下载这一层就命中缓存,构建时间从几分钟降到十几秒。但如果你项目里有多模块,记得把子模块的 pom 也一起 copy,否则 go-offline 会失败。这个细节我在第一次写多阶段构建时完全没意识到,构建报错还以为是镜像问题。

4. 一次完整的启动与验证流程

配置文件写完之后,真正的考验才开始。我给自己定了一套固定的验证顺序,每一步确认通过再进行下一步,这样出问题能立刻定位到是哪一层。

4.1 基础设施先行:先起三个中间件,单独验证

不要一上来就docker compose up -d全家桶,出了问题你不知道是谁的锅。我的做法是先只启动 mysql、redis、rabbitmq 三个服务:docker compose up -d mysql redis rabbitmq,然后用docker compose ps看状态。健康检查通过的话,STATUS 那一列会显示healthy。如果一直是starting,用docker compose logs mysql --tail 50看日志,八成是密码没配、端口冲突或者数据目录权限问题。

三个服务都 healthy 之后,我习惯手动连一下验证。MySQL 用docker exec -it bi-mysql mysql -uroot -p进去执行show variables like 'character_set_server'确认字符集;Redis 用docker exec -it bi-redis redis-cli -a 密码 ping看是否返回 PONG;RabbitMQ 直接浏览器打开 http://127.0.0.1:15672 用配置的账号登录,看 Overview 页面有没有红色告警。这三步花不了两分钟,但能提前排掉 90% 的环境问题。

4.2 应用启动:盯住三行日志

应用容器起来之后,docker compose logs -f app盯日志。健康启动的日志里,有三行关键信息必须出现:第一行是 Spring Boot 的 banner 之后打印的 profile 信息,确认它读到了正确的配置;第二行是数据库连接池初始化完成的日志,通常是HikariPool-1 - Start completed;第三行是 Tomcat 或 Netty started on port 8080。这三行都出现,基本说明应用起来了。

如果卡在启动阶段不动,优先怀疑两个地方。一是配置里的 host 名写错,比如还是 localhost,日志里会有Connection refused;二是 healthcheck 判断有问题导致应用一直在等依赖。前者看日志能直接定位,后者可以临时把 depends_on 的 condition 去掉试一下,如果去掉就能起,说明是健康检查的 test 命令写错了,常见于密码变量在 test 数组里没被正确展开。

4.3 端到端验证:触发一个异步报表任务

服务都起来了不等于功能正常,BI 项目最需要验证的是那条异步链路。我的验证方法是:登录系统,找一个数据量中等(几千行)的看板,点"生成报表"或者"导出",然后观察三件事——页面上任务状态是否从"排队中"变成"处理中"再变成"完成";RabbitMQ 管理界面里对应队列的 Ready 和 Unacked 数字是否有变化;Redis 里是否出现了这个任务的结果缓存 key。

这条链路走通,说明 Spring Boot 发消息、RabbitMQ 投递、消费者处理、写缓存这一整套是通的。如果任务一直卡在"排队中",先看 RabbitMQ 队列里有没有消息堆积——有堆积说明消费者没起来或者没消费;没消息说明生产者压根没发出去,回去检查 RabbitTemplate 的配置和交换机路由键。

这里分享一个排查技巧:在消费方法的第一行和最后一行各打一条日志,带上消息 ID 和耗时。任务卡住的时候,看日志能立刻区分是"没收到消息"还是"收到了但处理到一半卡住"。后者通常是数据库慢查询或者外部接口超时,跟队列本身无关。这个日志成本极低,但排障效率提升非常明显。

5. 上线之后才会暴露的四个问题

前面讲的都是"怎么跑起来",这一节讲"跑起来之后哪里会翻车"。这几个问题我在不同项目里都遇到过,共同特点是:本地和测试环境永远复现不了,只在真实负载下出现。

5.1 容器内存超限被静默杀掉

表现是应用毫无征兆地重启,日志里没有任何异常堆栈,只有 Docker 的事件记录能看到 OOMKilled。原因通常是 JVM 堆设得太大,加上堆外内存(线程栈、Metaspace、直接内存)超过了容器限制。举个例子:容器限制 1G,JVM 按 75% 分配堆是 768M,看起来还有余量,但 BI 应用里 Netty 的直接内存、文件映射、线程栈加起来很容易再吃掉两三百兆,加起来就超了。

处理办法是堆比例别超过 70%,并且给容器留足余量。如果容器限制 1G,堆设 600M 左右比较稳。另外可以用docker stats观察实际内存曲线,如果内存长期贴着上限,不是调 JVM 参数的问题,而是该扩容了。还有个小技巧:开启-XX:+HeapDumpOnOutOfMemoryError并把 dump 路径挂到卷上,真出问题的时候有现场可分析。

5.2 Redis 大 key 导致的请求毛刺

BI 场景特别容易产生大 key,比如把整个看板的查询结果序列化成一个 JSON 塞进 Redis,几十万行数据下来就是几十兆。单次读写的耗时倒还好,但它会阻塞 Redis 的单线程,导致其他请求出现几十毫秒甚至上百毫秒的毛刺。更麻烦的是删除大 key,del一个几十兆的 key 可能阻塞好几秒。

我的处理原则是:单 key 控制在几十 KB 以内,超过就拆分或者只缓存分页后的结果。如果必须缓存大结果,用 hash 结构按行分片存,读取时按需取。删除大 key 用unlink而不是del,它是异步回收,不阻塞主线程。这些都是在被毛刺折腾过之后才记住的。

5.3 队列堆积引发的连锁反应

某个数据源响应变慢,消费者处理一个任务从 2 秒变成 30 秒,队列消息迅速堆积到几万条。RabbitMQ 在内存水位告警之后会开始把消息刷盘,磁盘 IO 飙升,进而拖慢同一台机器上的数据库。这是一个典型的雪崩链路。

防御手段有三层。第一层是给队列设长度上限,x-max-length配合x-overflow reject-publish,队列满了直接拒绝新消息,让生产者感知到压力而不是无限堆积。第二层是消费者的并发度别设太高,concurrency设 2 到 4 就够了,设太高反而会把数据库连接池占满。第三层是监控队列深度,超过阈值就告警,人工介入比自动扩容更可控。

5.4 时区不一致导致的报表数据错位

这个问题最隐蔽。数据库设了 +08:00,JVM 设了 Asia/Shanghai,但 JDBC 连接串如果没加serverTimezone=Asia/Shanghai,驱动可能按 UTC 解释时间戳,结果"今日"的统计范围整体偏移 8 小时,凌晨生成的数据会莫名其妙少一段或者多一段。表现是用户反馈"昨天的报表数字不对",但你查代码逻辑完全没问题。

排查方法很直接:在应用启动时打一条日志,输出TimeZone.getDefault()和数据库的@@global.time_zone,两边对照。连接串里统一加上serverTimezone参数,前端传给后端的时间统一用带时区的格式,这三个地方对齐了,这类问题基本绝迹。

6. 备份、迁移与一鍵重建

部署的最后一环不是"跑起来",而是"坏了能快速恢复"。BI 项目的数据重要性决定了这套机制必须提前准备好,而不是出事之后再想。

6.1 备份脚本:三个数据源分别处理

数据库用mysqldump导出,注意加--single-transaction参数避免锁表,--routines --triggers保证存储过程和触发器不丢。Redis 用BGSAVE触发快照后拷贝dump.rdb,或者直接打包 AOF 目录。RabbitMQ 的队列定义(交换机、队列、绑定关系)可以用rabbitmqadmin export导出成 JSON,消息内容一般不建议备份,重放业务事件比备份消息更合理。

#!/bin/bash set -e DATE=$(date +%Y%m%d_%H%M%S) BACKUP_DIR=/opt/backup/${DATE} mkdir -p ${BACKUP_DIR} docker exec bi-mysql sh -c 'exec mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" \ --single-transaction --routines --triggers --all-databases' \ > ${BACKUP_DIR}/mysql.sql docker exec bi-redis redis-cli -a "$REDIS_PASSWORD" BGSAVE sleep 3 docker cp bi-redis:/data/dump.rdb ${BACKUP_DIR}/redis.rdb docker exec bi-rabbitmq rabbitmqctl export_definitions /tmp/defs.json docker cp bi-rabbitmq:/tmp/defs.json ${BACKUP_DIR}/rabbit_defs.json find /opt/backup -type d -mtime +7 -exec rm -rf {} +

脚本里最后一行是清理 7 天前的备份,不加的话磁盘迟早被撑满——我见过一个项目备份跑了半年没人管,把 500G 的盘占满了,然后数据库写不进去,整个系统只读。备份也要配定时任务,用宿主机 crontab 跑这个脚本比放在容器里靠谱,容器重建了定时任务还在。

6.2 迁移到新机器:镜像与数据的分离搬运

迁移的完整流程是:先在旧机器上docker save导出镜像(或者推到私有镜像仓库),把 compose 文件、环境变量文件、备份出来的数据一起打包;新机器上docker load导入镜像,恢复数据卷,再docker compose up -d。

有个细节必须注意:.env 文件里存着数据库密码、Redis 密码这些敏感信息,千万别提交到 git。我的做法是.env进.gitignore,仓库里只放一个.env.example说明需要哪些变量,真实的值通过部署时的配置文件或者环境注入。同理,compose 文件里也不要硬编码密码,全部用${VAR}引用。

数据卷的恢复方式:新建同名卷,然后把备份的数据拷贝进去。用docker run --rm -v mysql_data:/target -v /opt/backup/xxx:/source alpine sh -c "cp -a /source/. /target/"这种一次性容器操作,比手动找 Docker 的存储路径靠谱,因为不同系统的存储路径不一样,而且直接操作/var/lib/docker有风险。

6.3 一键重建:把整个流程脚本化

我最终把上面这些整合成三个脚本:deploy.sh负责首次部署(检查环境、创建目录、启动中间件、等健康、启动应用),backup.sh负责备份,restore.sh负责从备份恢复并重建环境。这三个脚本放在仓库根目录,新人接手或者客户现场部署,照着 README 跑三条命令就行。

这套东西的价值不在于省时间,而在于"确定性"。手动敲命令,每次都可能漏一步;脚本化之后,同样的输入必然得到同样的结果。我在一个交付项目里就是因为有了 restore.sh,客户服务器硬盘故障后半小时内整套系统恢复完毕,数据一条没丢。如果没有这个脚本,光是回忆当时怎么配的就要花半天。

最后分享一个个人的习惯:每次改完 compose 或 Dockerfile,我都会在一台干净的测试机上从头跑一遍完整流程,从空目录到服务可用。这个过程大概二十分钟,但能抓出所有"我本地有缓存所以没问题"的隐患。容器化最大的谎言就是"在我机器上是好的"——既然都容器化了,就应该做到在哪台机器上都一样好。