У меня проблема с DynamoDB и Docker, из-за которой у меня возникают проблемы при устранении неполадок. Суть в том, что мы запускаем DynamoDB в памяти (--inMemory) и имеем некоторый код обеспечения, который создает и заполняет некоторые таблицы. Ранее этот код обеспечения выполнялся локально (в операционной системе хоста) в сценарии оболочки.
Я переместил этот код в контейнер Docker. Мы используем Docker Compose для сборки и запуска контейнеров:
dynamodb:
container_name: "dynamodb"
image: amazon/dynamodb-local
ports:
- "18000:18000"
command: -jar DynamoDBLocal.jar -inMemory -port 18000
load-dynamodb:
container_name: "load-dynamodb"
image: myaccountid.dkr.ecr.us-east-1.amazonaws.com/path/aws-cli
volumes:
- ./_scripts/provision-dynamo-db.sh:/usr/local/bin/provision-dynamo-db.sh
- ./_scripts/dynamodb.sh:/usr/local/bin/dynamodb.sh
- ./_scripts/logging.sh:/usr/local/bin/logging.sh
- ./configuration/dynamo_auth_config_ida_sp.json:/etc/conf/dynamo_auth_config_ida_sp.json
- ./configuration/dynamo_auth_config_mock.json:/etc/conf/dynamo_auth_config_mock.json
- ./configuration/dynamo_org_data.json:/etc/conf/dynamo_org_data.json
command: "/usr/local/bin/provision-dynamo-db.sh"
depends_on:
- dynamodb
environment:
- AWS_REGION=${AWS_REGION}
- AWS_DEFAULT_REGION=${AWS_DEFAULT_REGION}
- AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
- AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
Кажется, что он работает нормально:
dynamodb | Initializing DynamoDB Local with the following configuration:
dynamodb | Port: 18000
dynamodb | InMemory: true
dynamodb | DbPath: null
dynamodb | SharedDb: false
dynamodb | shouldDelayTransientStatuses: false
dynamodb | CorsParams: *
dynamodb |
Я вижу таблицы, которые создаются и заполняются в журналах:
Attaching to load-dynamodb
load-dynamodb | 2019-10-21 16:33:59 Loading dev environment auth configuration
load-dynamodb | Connecting to http://dynamodb:18000...
load-dynamodb | {
load-dynamodb | "TableDescription": {
load-dynamodb | "TableArn": "arn:aws:dynamodb:ddblocal:000000000000:table/auth-config",
load-dynamodb | "AttributeDefinitions": [
load-dynamodb | {
load-dynamodb | "AttributeName": "customer_id",
load-dynamodb | "AttributeType": "S"
load-dynamodb | },
load-dynamodb | {
load-dynamodb | "AttributeName": "name",
load-dynamodb | "AttributeType": "S"
load-dynamodb | }
load-dynamodb | ],
load-dynamodb | "ProvisionedThroughput": {
load-dynamodb | "NumberOfDecreasesToday": 0,
load-dynamodb | "WriteCapacityUnits": 10,
load-dynamodb | "LastIncreaseDateTime": 0.0,
load-dynamodb | "ReadCapacityUnits": 10,
load-dynamodb | "LastDecreaseDateTime": 0.0
load-dynamodb | },
load-dynamodb | "TableSizeBytes": 0,
load-dynamodb | "TableName": "auth-config",
load-dynamodb | "TableStatus": "ACTIVE",
load-dynamodb | "StreamSpecification": {
load-dynamodb | "StreamViewType": "NEW_IMAGE",
load-dynamodb | "StreamEnabled": true
load-dynamodb | },
load-dynamodb | "LatestStreamLabel": "2019-10-21T16:34:02.184",
load-dynamodb | "KeySchema": [
load-dynamodb | {
load-dynamodb | "KeyType": "HASH",
load-dynamodb | "AttributeName": "customer_id"
load-dynamodb | },
load-dynamodb | {
load-dynamodb | "KeyType": "RANGE",
load-dynamodb | "AttributeName": "name"
load-dynamodb | }
load-dynamodb | ],
load-dynamodb | "ItemCount": 0,
load-dynamodb | "CreationDateTime": 1571675642.184,
load-dynamodb | "LatestStreamArn": "arn:aws:dynamodb:ddblocal:000000000000:table/auth-config/stream/2019-10-21T16:34:02.184"
load-dynamodb | }
load-dynamodb | }
load-dynamodb | Verifying auth-config...
load-dynamodb | {
load-dynamodb | "Count": 2,
load-dynamodb | "ScannedCount": 2,
load-dynamodb | "ConsumedCapacity": null
load-dynamodb | }
Когда другой контейнер пытается получить данные, данные отсутствуют. DescribeTable говорит, что это «несуществующая» таблица, и она создается снова (без необходимых данных):
auth_service | An error occurred (ResourceNotFoundException) when calling the DescribeTable operation: Cannot do operations on a non-existent table
auth_service | Creating table auth-config
auth_service | {
auth_service | "TableDescription": {
auth_service | "TableArn": "arn:aws:dynamodb:ddblocal:000000000000:table/auth-config",
Одна из моих теорий заключалась в том, что мы подключались как другой пользователь, и поэтому, другое пространство имен. Однако, в соответствии с документацией DynamoDB, это не так:
Для SDK AWS для DynamoDB требуется, чтобы в конфигурации приложения было указано значение ключа доступа и значение региона AWS. Если вы не используете опцию -sharedDb или -inMemory, DynamoDB использует эти значения для именования файла локальной базы данных. Эти значения не обязательно должны быть действительными значениями AWS для локального запуска. Однако вам может быть удобно использовать допустимые значения, чтобы позже можно было запустить свой код в облаке, просто изменив используемую конечную точку.
Кроме того, я исключил, что он подключаетсяв неправильный экземпляр путем вызова оболочки в новом контейнере Docker, подключения к базе данных в конечной точке (http://dynamodb:18000), с перечислением пустого набора таблиц, отключения контейнера DynamoDb и последующей попытки подключения. Как и ожидалосьпосле завершения работы с DynamoDB клиенту aws не удается подключиться.
Итак, исключив, что мы подключаемся к неправильному экземпляру, возможно, что в среде есть что-то, что заставляет клиента динамика Dynamsbподключиться к другой базе данных? Насколько я понимаю, учетные данные AWS и регион игнорируются из-за того, что он работает с -inMemory. Как насчет самой сети? Код обеспечения теперь выполняется в сети Docker, а не в сети хоста.
Я в растерянности, любые предложенияприветствуется.
ОБНОВЛЕНИЕ:
- Похоже, что AWS_DEFAULT_REGION влияет на результаты запроса, даже если указан URL-адрес конечной точки.
Я забрался в контейнер load-dynamicodb и запросил таблицу. Я вижу ожидаемые результаты (auth-config содержит 2 записи).
AWS_DEFAULT_REGION не установлен. Я установил его:
$ export AWS_DEFAULT_REGION=us-east-1
Теперь запрос показывает ноль записей:
bash-4.4# aws dynamodb --endpoint-url http://dynamodb:18000 describe-table --table-name auth-config
..."ItemCount": 0...
Я не уверен, почему это будет иметь значение, так как мы переопределяем URL-адрес конечной точки, но так какэто кажется значительным, я предполагаю, что зависимый контейнер должен указывать другой набор переменных среды или формировать запрос динамодаба по-другому.
Я что-то упустил в документах, которые объясняли бы такое поведение в клиенте awscli