Docker容器中file://的工作机制及LocalStack S3 CORS配置报错排查

先明确file://的作用与容器特性 #

file://是AWS CLI的参数前缀，作用是告诉CLI从本地文件加载JSON配置内容，替代直接在命令行中输入冗长的JSON字符串。在Docker容器环境中，这个路径指向的是容器内部的文件系统路径，和宿主机的文件系统完全隔离——也就是说，宿主机上的文件如果没复制到容器里，容器内的命令根本访问不到。

你的核心误区 #

1. 配置文件未同步到容器：你只把localstack-script.sh复制到了容器内，但cors-config.json还留在宿主机的docker/aws目录下，容器里根本不存在这个文件，自然会报“找不到目录”的错误。
2. 相对路径基准错误：LocalStack执行/etc/localstack/init/ready.d/下的脚本时，工作目录默认是容器的根目录/（而非脚本所在的/etc/localstack/init/ready.d/），所以./cors-config.json会去根目录找文件，而不是脚本所在的目录。
3. 命令工具误用：最后一行你用了aws而非awslocal，虽然可能通过配置Endpoint也能生效，但awslocal是LocalStack官方封装的工具，更适配容器内的模拟环境。

解决方案 #

步骤1：修改Dockerfile，同步配置文件到容器 #

把cors-config.json也复制到脚本所在的容器目录：

FROM --platform=linux/amd64 localstack/localstack:3.0
COPY --chown=localstack ./localstack-script.sh /etc/localstack/init/ready.d/localstack-script.sh
# 新增复制cors-config.json的指令
COPY --chown=localstack ./cors-config.json /etc/localstack/init/ready.d/cors-config.json
RUN chmod u+x /etc/localstack/init/ready.d/localstack-script.sh

步骤2：修正脚本中的路径和命令 #

有两种可靠的路径写法：

方法一：使用绝对路径（最稳妥）

直接指定容器内配置文件的绝对路径：

#!/bin/bash
awslocal s3api \
create-bucket --bucket super-simple-cms \
--create-bucket-configuration LocationConstraint=eu-central-1 \
--region eu-central-1
awslocal s3api put-bucket-acl --bucket super-simple-cms --acl public-read
# 用绝对路径指向容器内的配置文件
awslocal s3api put-bucket-cors --bucket super-simple-cms --cors-configuration file:///etc/localstack/init/ready.d/cors-config.json

方法二：基于脚本目录的相对路径（更灵活）

通过脚本自身路径动态获取配置文件位置，避免硬编码绝对路径：

#!/bin/bash
# 获取当前脚本所在的绝对目录
SCRIPT_DIR=$(cd "$(dirname "${BASH_SOURCE[0]}")" &>/dev/null && pwd)

awslocal s3api \
create-bucket --bucket super-simple-cms \
--create-bucket-configuration LocationConstraint=eu-central-1 \
--region eu-central-1
awslocal s3api put-bucket-acl --bucket super-simple-cms --acl public-read
# 拼接脚本目录与配置文件名
awslocal s3api put-bucket-cors --bucket super-simple-cms --cors-configuration file://${SCRIPT_DIR}/cors-config.json

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