背景
在对 Rocket.Chat 从 7.9 升级至 7.10.x 的过程中，修改了 docker-compose.yml 中 Rocket.Chat 镜像版本号，随后执行：
docker compose pull
结果出现拉取失败，错误信息指向 MongoDB 镜像，而非 Rocket.Chat 本身。
错误现象
执行 docker compose pull 时出现如下关键报错：
Error manifest for bitnami/mongodb:7.0.15 not found
manifest unknown: manifest unknown
同时，Rocket.Chat 镜像拉取被中断：
Image registry.rocket.chat/rocketchat/rocket.chat:7.10.2 Interrupted
初步排查结论
docker-compose.yml中 仅修改了 Rocket.Chat 镜像版本- MongoDB 服务配置未发生任何变更
- Rocket.Chat 从 7.9 → 7.10.0 的升级过程此前是成功的
因此问题并非配置写错或版本不兼容。
根本原因分析
问题的根源在于 Bitnami MongoDB 镜像的 tag 已在远端 registry 中不存在：
bitnami/mongodb:7.0.15
Docker 在执行 docker compose pull 时，会对 compose 文件中所有服务镜像执行拉取操作：
- 即使本地已有镜像
- 即使当前并不打算升级 MongoDB
一旦 registry 中不存在该 tag，就会直接报错并中断整个 pull 流程。
为什么之前升级没有问题？
原因通常是以下之一（或组合）：
- 本地已经缓存了
bitnami/mongodb:7.0.15镜像 - 之前执行的是
docker compose up -d，而不是pull - MongoDB 容器未被重建，因此未触发拉取
因此，“之前能升级成功”和“现在 pull 失败”是可以同时成立的。
为什么 docker compose up -d 可以正常执行？
docker compose up -d 的行为是：
- 优先使用本地已有镜像
- 只有在镜像不存在时才尝试拉取
因此在本地已有 MongoDB 镜像的情况下：
docker compose up -d
可以正常启动或重建容器，而不会触发远端 tag 不存在的问题。
解决方案
方案一（临时恢复运行）
直接使用：
docker compose up -d
前提条件：
- 本地仍存在可用的 MongoDB 镜像
- MongoDB 数据卷未损坏
该方案可以快速恢复服务，但不适合作为长期解决方案。
方案二（推荐，长期稳定）
修改 docker-compose.yml 中 MongoDB 镜像版本，避免使用可能被下架的精确小版本 tag。
不推荐（存在风险）
image: bitnami/mongodb:7.0.15
推荐写法一：锁主版本
image: bitnami/mongodb:7.0
优点：
- 仍限制在 7.0 主版本
- 避免具体 patch 版本被移除
推荐写法二：锁定完整构建版本（最可复现）
image: bitnami/mongodb:7.0.14-debian-12-rX
（以实际存在的 tag 为准）
方案三（绕过失败镜像）
如果需要临时拉取其他镜像，可使用：
docker compose pull --ignore-pull-failures
该方式不会因为单个镜像失败而中断整个拉取流程，但不解决根本问题。
经验总结
- Docker 镜像 tag 并非永久存在
- 尤其是第三方发行版（如 Bitnami）
docker compose pull会严格校验所有服务镜像docker compose up -d更适合已有镜像的增量升级- 数据库类服务应避免使用过于精确、不可控的 tag
- 生产环境建议锁定：
- 主版本，或
- 完整构建版本 / digest
最终状态
- 使用
docker compose up -d成功启动服务 - 问题确认为 远端镜像 tag 消失
- 服务本身与数据未受影响