在ECS维护DockerCompose服务时,固定数据库和缓存镜像版本,备份MySQL并验证恢复,检查Redis持久化策略,升级前预拉镜像,记录旧镜像标签、配置文件、备份文件和卷名以便回滚。
这是一份 ECS 上维护 Docker Compose 基础服务的操作记录,场景不算复杂:一个小型业务环境,用 Compose 跑着 app、mysql、redis 和一个反向袋里。说白了,就是日常维护时那些绕不开的活儿——数据库备份、缓存检查、镜像版本锁死、升级前预热,外加万一翻车怎么回滚。

长期稳定更新的攒劲资源: >>>点此立即查看<<<
几个维护目标拎一下:
先跑一把 docker compose config,确认当前生效的 compose 配置长什么样。尤其是 MySQL 服务,建议把命名卷写明确,不要依赖默认的匿名卷,不然后面 volume 名称乱得你认不出来。
services:
mysql:
image: docker.1ms.run/mysql:8.4
environment:
MYSQL_ROOT_PASSWORD: change-me
MYSQL_DATABASE: app
volumes:
- mysql-data:/var/lib/mysql
volumes:
mysql-data:
用 docker volume ls 看看有哪些卷,再用 docker volume inspect 项目名_mysql-data 确认挂载点。这里有个常见坑:如果项目目录改过,Compose 项目前缀会跟着变,新卷的名字就变了,旧数据可能就丢了。所以这一步别跳过。
用 docker compose exec 执行 mysqldump,把备份导出来:
docker compose exec mysql sh -c 'mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" app' > mysql-app.sql
光备份不够,得恢复验证。跑一遍:
cat mysql-app.sql | docker compose exec -T mysql sh -c 'mysql -uroot -p"$MYSQL_ROOT_PASSWORD" app'
要是恢复失败,别急着推进升级步骤——先排查用户权限、密码是否一致、数据库名、字符集、MySQL 版本差异这些因素。恢复不通过,升级就是赌运气。
Redis 的角色决定了处理方式。如果只是缓存,重建一下影响有限,重启就完事。但如果它承载着队列或者会话,那就必须挂载 /data 卷,并确认持久化策略——比如开启 AOF:
services:
redis:
image: docker.1ms.run/redis:7
command: ["redis-server", "--appendonly", "yes"]
volumes:
- redis-data:/data
另外别忘了一件事:云服务器上的安全组和端口暴露。Redis 默认端口 6379,千万别直接暴露到公网上,不然就是给黑客送大礼。
升级前先把目标镜像拉到本地,这样升级过程中就不需要联网下载了:
docker pull docker.1ms.run/mysql:8.4
docker pull docker.1ms.run/redis:7
docker pull docker.1ms.run/nginx:1.27-alpine
确认预拉成功后,再走升级流程:
docker compose pull
docker compose up -d
动手维护之前,把下面这些东西记下来,最好是写成文档或者贴到笔记里:
compose.yaml 内容(可以 git 提交一份)。在 ECS 上用 Compose 跑服务,说白了就是把镜像、容器、数据卷这三件事分开处理。容器随便重建,镜像随时重拉,但数据卷必须先备份、再验证恢复结果,才能放心操作。维护窗口的精力应该花在升级本身,而不是临时抱佛脚排查备份能不能用。提前做好回滚预案,翻车也不慌。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述