Docker Compose内创建DynamoDB Local表后本地无法查看的问题
我用Docker Compose模拟基于CloudFormation搭建的AWS基础设施,需要创建CloudFormation模板里的FooBars DynamoDB表,于是添加了DynamoDB Local服务:
foobar-service-db: image: amazon/dynamodb-local:latest command: "-jar DynamoDBLocal.jar -inMemory" ports: [8090:8000] restart: always
启动Docker Compose后,我能通过本地命令行执行aws dynamodb create-table --endpoint-url http://localhost:8090 --region dummy-region创建表,且能正常查看。
为了把表创建整合进Docker Compose,我添加了初始化服务:
foobar-service-db-init: depends_on: - foobar-service-db image: amazon/aws-cli environment: AWS_ACCESS_KEY_ID: dummy-key-id AWS_SECRET_ACCESS_KEY: dummy-key command: >- dynamodb create-table --table-name FooBars --attribute-definitions AttributeName=id,AttributeType=S --key-schema AttributeName=id,KeyType=HASH --billing-mode PAY_PER_REQUEST --endpoint-url http://foobar-service-db:8000 --region dummy-region
(注:Docker Compose网络内请求需指定容器端口而非主机端口)
启动时输出显示已创建ARN为arn:aws:dynamodb:ddblocal:000000000000:table/FooBars的表,但本地执行aws dynamodb list-tables --endpoint-url http://localhost:8090 --region dummy-region却看不到这张表。
明明只有一个DynamoDB Local服务foobar-service-db,且DynamoDB Local不应基于用户身份区分命名空间,我也指定了相同的dummy-region,为什么Docker Compose内初始化服务创建的表无法被本地查看?
核心原因
DynamoDB Local的-inMemory模式下,数据隔离是基于Access Key ID + 区域的组合,而非仅依赖区域。你本地命令行使用真实AWS凭证,Docker内的初始化服务用的是dummy-key-id假凭证,两者凭证不同,导致DynamoDB Local为这两个请求创建了独立的数据集命名空间,所以两边的表互相不可见。
解决办法
方案1:统一凭证
让本地命令行和Docker内的初始化服务使用相同的假凭证。可以:
- 提前配置一个本地AWS profile(比如
dummy-profile),设置AWS_ACCESS_KEY_ID=dummy-key-id和AWS_SECRET_ACCESS_KEY=dummy-key,然后执行:
aws dynamodb list-tables --endpoint-url http://localhost:8090 --region dummy-region --profile dummy-profile
- 或者直接在命令行临时指定环境变量:
AWS_ACCESS_KEY_ID=dummy-key-id AWS_SECRET_ACCESS_KEY=dummy-key aws dynamodb list-tables --endpoint-url http://localhost:8090 --region dummy-region
方案2:禁用凭证隔离
启动DynamoDB Local时添加-sharedDb参数,强制所有请求共享同一个数据集,忽略凭证和区域的差异。修改foobar-service-db的command配置:
command: "-jar DynamoDBLocal.jar -inMemory -sharedDb"
这样不管使用什么凭证或区域,操作的都是同一个数据集,初始化服务创建的表就能被本地正常查看。
内容的提问来源于stack exchange,提问作者Garret Wilson

