Docker Compose共享Volume：先启容器能否获取后启容器文件？

Docker Compose 配置 #

version: "3"
services:

  db:
    container_name: db
    image: mysql
    ports:
      - "3306:3306"
    volumes:
      - initdb:/docker-entrypoint-initdb.d/:ro
  
  web:
    container_name: web
    image: my_web
    volumes:
      - initdb:/initdb/:ro
    depends_on: 
      - db

volumes:
  initdb:

场景与疑问 #

my_web镜像内置了/initdb/create_schema.sql文件（构建镜像时生成，未存储在宿主机磁盘）。由于web服务依赖db服务，db容器会先于web容器启动。

测试发现db容器可以读取到来自web容器的create_schema.sql文件，现咨询：该文件的可用性是有明确保障的，还是随机出现的？同时希望了解Docker Volume的创建与容器映射时机，判断共享数据的可用性是否能得到保障。

文件可用性是随机的，无明确保障 #

你测试中出现的db能读到文件的情况只是偶然，绝对不能依赖这个行为。核心原因是depends_on仅控制容器的启动顺序，不会等待web容器完成文件同步后再启动db容器：

• db启动时，web容器可能还在初始化流程中，镜像里的create_schema.sql还没机会被同步到共享volume；
• 只有当web容器先启动完成，把文件复制到volume后，db重启才能读到文件——但你的配置里db先启动，所以大概率读不到，能读到只是巧合。

Docker Volume的创建与映射时机 #

• Volume创建时机：Compose启动时，会优先创建所有定义的命名卷（比如这里的initdb），和服务启动顺序无关。
• 容器映射时机：容器启动阶段，Docker会将卷挂载到容器指定路径，此时分两种情况：
  • 如果卷是空的，且容器镜像的挂载路径有内容，Docker会把镜像里的文件复制到卷中；
  • 如果卷已有内容，会直接覆盖容器挂载路径的内容（镜像里的内容会被隐藏）。

如何保障共享数据的可用性 #

要让db稳定读取到create_schema.sql，可以调整为以下方案之一：

• 方案1：把create_schema.sql放在宿主机目录，用绑定挂载（bind mount）替代命名卷，同时挂载给db和web服务；
• 方案2：修改db服务的启动逻辑，添加等待机制——比如在启动脚本中检查共享卷里的create_schema.sql是否存在，存在后再执行数据库初始化；
• 方案3：直接把create_schema.sql打包进mysql镜像，或者利用官方mysql镜像的初始化机制，将脚本放在宿主机目录挂载到/docker-entrypoint-initdb.d/。

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