VS Code多容器开发容器：重建引发关联服务容器崩溃问题

问题描述 #

配置了三个Docker Compose服务：API服务器、站点服务器、Redis支撑服务，项目结构及核心配置如下：

项目结构 #

app
├── .devcontainer
│   ├── api
│   │   └── devcontainer.json
│   ├── compose.override.yaml
│   └── site
│       └── devcontainer.json
├── api (目录内容与问题无关)
├── compose.yaml
└── site (目录内容与问题无关)

核心配置文件 #

compose.yaml：

services:
  api:
    image: python:3.11-slim
    command: sleep infinity

  site:
    image: node:23-slim
    command: sleep infinity

  cache:
    image: redis:7.4.2

.devcontainer/compose.override.yaml：

services:
  api:
    volumes:
      - .:/app:cached

  site:
    volumes:
      - .:/app:cached

.devcontainer/api/devcontainer.json：

{
    "name": "API",
    "dockerComposeFile": ["../../compose.yaml", "../compose.override.yaml"],
    "service": "api",
    "workspaceFolder": "/app/api"
}

.devcontainer/site/devcontainer.json：

{
    "name": "Site",
    "dockerComposeFile": ["../../compose.yaml", "../compose.override.yaml"],
    "service": "site",
    "workspaceFolder": "/app/site"
}

初始运行正常，但先打开API开发容器后，对站点服务执行「重建并重新打开」时，API开发容器会崩溃；反之亦然。经排查，重建其中一个服务会导致共享同一绑定挂载的另一个服务容器被重建（容器ID变更），Redis服务不受影响。

问题解答 #

1. 共享同一卷的服务是否会因其中一个重建而全部被重建？ #

是的，在当前配置下，共享同一绑定挂载卷（.:/app:cached）的服务，当其中一个执行重建操作时，另一个服务的容器也会被连带重建。

2. 原因是什么？ #

• Docker Compose会将共享相同绑定挂载的服务视为同一服务栈的强关联组件，当重建目标服务时，Compose会重新解析整个配置栈，为保证挂载的一致性，会连带重建所有使用该绑定挂载的服务。
• VS Code Dev Containers的「重建并重新打开」操作本质是调用docker compose up --build类命令，而两个服务共享同一份主Compose文件和override文件，Compose会将它们归为同一栈，重建时会更新所有受挂载变更影响的服务。Redis未使用该绑定挂载，因此不受波及。

3. 有无方法阻止该现象？ #

有三种可行方案：

• 配置独立的绑定挂载路径
  修改.devcontainer/compose.override.yaml，让两个服务分别挂载各自的子目录：

  services:
    api:
      volumes:
        - ./api:/app:cached
  
    site:
      volumes:
        - ./site:/app:cached
  

  同时更新各自devcontainer.json的workspaceFolder为/app（因为现在挂载的是子目录到/app）。

• 拆分Compose配置栈
  为API和Site分别创建独立的override配置文件：

  • 为API创建.devcontainer/api/compose.override.yaml，仅配置API的挂载；
  • 为Site创建.devcontainer/site/compose.override.yaml，仅配置Site的挂载。
    然后修改各自devcontainer.json的dockerComposeFile路径，指向独立的override文件，使两个服务分属不同的Compose栈，重建时互不影响。

• 使用命名卷替代绑定挂载
  将绑定挂载替换为Docker命名卷，不过这种方式会降低开发时代码实时同步的便利性，需结合卷同步机制调整，适合代码修改频率较低的场景。

内容的提问来源于stack exchange，提问作者MichiganAgain