如何将Docker卷映射到EC2主机文件系统以解决Chronicle队列读写权限问题

问题根源 #

• Dockerfile中对/tmp/my_app_data及其子目录的chown操作完全不生效：Docker运行时绑定挂载（bind mount）主机的/tmp/my_app_data目录到容器路径时，会直接覆盖容器内该路径的所有原有文件、权限配置，Dockerfile里提前做的权限修改不会生效。
• 主机侧的/tmp/my_app_data及其子目录的UID/GID和容器内nobody用户的UID/GID不匹配：默认情况下主机上该目录由root或EC2实例默认用户创建，权限通常为755，仅所有者拥有写入权限，容器内的nobody用户不属于所有者分组，自然无法写入文件标记消息已处理。
• Chronicle Queue本身要求读写双权限更新索引文件，仅读权限无法完成消息消费确认的流程。

修复方案 #

方案1：POC快速验证（可临时使用root权限） #

直接修改容器运行用户为root，跳过权限校验，最快完成功能验证：
删除两个Dockerfile中的USER nobody行，其余配置保持不变，重新构建镜像部署即可。

方案2：保留nobody用户运行的规范方案 #

1. 首先统一容器内nobody的UID/GID，避免不同基础镜像的nobody ID不一致，在Dockerfile开头添加如下命令，固定nobody用户UID/GID为65534：

RUN usermod -u 65534 nobody && groupmod -g 65534 nobody

2. 在EC2主机上执行权限修改，把共享目录的所有者改成对应UID/GID：

sudo chown -R 65534:65534 /tmp/my_app_data
sudo chmod -R 775 /tmp/my_app_data

3. 明确任务定义中的挂载点读写属性，避免默认配置异常：

"mountPoints": [
  {
    "readOnly": false,
    "containerPath": "/tmp/my_app_data",
    "sourceVolume": "chronicle"
  }
]

调试提示 #

如果修改后仍存在权限问题，可进入运行中的容器执行id和ls -l /tmp/my_app_data命令，确认当前运行用户和目录的所有者是否匹配，快速定位问题。

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