Docker卷挂载需求：容器RW/主机RO，AWS构建场景扩容方案咨询

核心实现思路 #

你提出的容器视角RW、主机视角RO挂载共享存储的需求完全可以实现，核心是利用Docker挂载特性结合Linux文件系统层，将EFS作为只读基础层，把容器的写操作重定向到本地临时存储，既复用EFS上的350GB基础数据，又避免共享存储的写入冲突，同时支持弹性扩缩容。

具体实现步骤 #

1. 主机侧只读挂载EFS #

在所有弹性扩容的EC2实例上，将EFS以只读模式挂载到主机固定目录，例如/mnt/efs-build-base：

mount -t nfs4 -o ro,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport <efs-dns-name>:/ /mnt/efs-build-base

可将该挂载命令加入实例启动脚本（如user data），确保实例启动后自动完成挂载。

2. 容器侧配置读写挂载 #

启动容器时，通过两种方式实现容器内的读写需求：

• 方式一：绑定挂载+临时存储
  将主机上的只读EFS目录挂载到容器的只读路径，同时为容器的写入目录挂载tmpfs（内存临时存储）或本地磁盘目录：

  docker run -d \
    -v /mnt/efs-build-base:/build/base:ro \
    -v /tmp/build-write:/build/workspace:rw \
    --name build-container \
    <your-build-image>
  

  容器内将构建临时文件、输出文件写入/build/workspace，容器终止时该目录数据自动丢弃；需保留的制品可从该目录同步到S3等持久存储。

• 方式二：overlayFS写时复制
  利用Linux overlayFS将只读EFS目录作为lower层，主机本地临时目录作为upper层和work层，合并后挂载到容器内：

  # 创建本地临时目录结构
  mkdir -p /tmp/overlay/upper /tmp/overlay/work /tmp/overlay/merged
  # 挂载overlayFS
  mount -t overlay overlay -o lowerdir=/mnt/efs-build-base,upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/work /tmp/overlay/merged
  # 启动容器挂载合并目录为RW
  docker run -d \
    -v /tmp/overlay/merged:/build:rw \
    --name build-container \
    <your-build-image>
  

  这种模式下，容器读取操作直接走EFS只读数据，写入操作会被复制到本地upper层，容器终止后删除本地upper和work目录即可清理临时数据。

弹性扩缩容配套优化 #

• EC2自动扩缩容：配置EC2 Auto Scaling Group，基于构建请求队列长度（如SQS队列深度）自动增减实例数量，实例启动时自动完成EFS挂载与Docker环境初始化。
• 制品存储自动化：在构建脚本中加入逻辑，将最终制品（如编译后的二进制包、镜像）同步到S3或ECR，不依赖本地存储。
• 本地缓存优化：对构建频繁使用的小文件，可在主机本地配置缓存（如用本地磁盘目录作为overlayFS的额外lower层），降低EFS读取压力。

注意事项 #

• EFS性能配置：根据构建需求选择合适的性能模式（通用型或最大IO型），避免共享存储IO瓶颈拖慢构建速度。
• 实例本地存储：若构建产生大量临时数据，建议选用带本地NVMe存储的EC2实例（如c5d、m5d系列），性能优于EBS临时存储。

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