DynoTable
Intermediário7 min de leitura

Como conectar-se a DynamoDB Local e LocalStack

Você tem um DynamoDB local em execução e seu código se comunica bem com ele - mas você quer para ver as tabelas, não escreva um script scan todas as vezes. Conectando um cliente a um endpoint local envolve duas alterações: apontar para o URL correto e entregá-lo descartável credenciais. Os detalhes abaixo são onde as pessoas ficam presas – namespace de região, a regra da chave alfanumérica e a divisão da porta 8000 vs 4566.

DynamoDB Local vs LocalStack: ao que você está se conectando

Ambos fornecem um DynamoDB API em localhost sem conta AWS, mas são coisas diferentes:

Portanto, a única diferença prática para conexão é o URL do endpoint: :8000 para autônomo DynamoDB Local, :4566 para DynamoDB-via-LocalStack. Todo o resto - o API, o truque de credenciais, a configuração da GUI — é idêntico.

A configuração de endpoint + credenciais fictícias que confunde todo mundo

Os SDKs e CLI AWS requerem uma chave de acesso e uma região mesmo quando se comunicam com um endpoint local — mas esses valores não precisam ser reais. Os próprios documentos de AWS dizem esses valores "não precisam ser valores AWS válidos para serem executados localmente" (AWS documentos).

Duas dicas que não são óbvias:

  • A região/chave de acesso cria namespaces silenciosos para seus dados. Sem o Sinalizador -sharedDb, DynamoDB Local grava um myaccesskeyid_region.db separado arquivo por combinação de ID de chave de acesso + região — nomeação exata de AWS. Conecte-se com uma chave ou região diferente daquela usada pelo seu aplicativo e suas tabelas parecerão como se eles tivessem desaparecido; eles estão apenas em outro arquivo. Execute com -sharedDb (um shared-local-instance.db para cada cliente) ou corresponda à chave exata + região seu aplicativo usa.
  • O ID da chave de acesso deve ser alfanumérico em DynamoDB Local — sem símbolos. documentos AWS o estado AWS_ACCESS_KEY_ID pode conter apenas A–Z, a–z e 0–9; AWS introduzido isso em DynamoDB Local 2.0.0 (e 1.23.0+), então uma chave com caracteres especiais que trabalhado em uma imagem anterior agora falha (AWS re:Post). Veja o erro abaixo.

Para LocalStack o padrão seguro é test / test: ignora totalmente a chave secreta e nunca valida o valor secreto. Chaves AKIA…/ASIA… de aparência real são rejeitado como medida de segurança e retornado à conta fictícia 000000000000 — a mesma conta para a qual uma chave arbitrária como test resolve. Fique com teste.

Conectando-se com a CLI AWS (verificação de integridade)

Antes de apontar uma GUI para ele, confirme se o endpoint está ativo na CLI. A CLI não tem nenhum endpoint local padrão integrado, então passe --endpoint-url por comando ou defina AWS_ENDPOINT_URL_DYNAMODB=http://localhost:8000 (CLI v2.13+).

DynamoDB Local:

aws dynamodb list-tables --endpoint-url http://localhost:8000

LocalStack (mesmo comando, porta diferente):

aws dynamodb list-tables --endpoint-url http://localhost:4566

Se você tiver credenciais configuradas (mesmo as falsas em ~/.aws/credentials ou via AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY), isso retorna sua lista de tabelas. Uma lista vazia sem erros significa que o endpoint funciona, mas você está vendo um namespace de chave/região diferente - veja a pegadinha acima.

DynamoDB Local GUI: navegando e consultando tabelas locais em DynoTable

Depois que a CLI funciona, uma GUI precisa dos mesmos três valores: endpoint, region, e quaisquer credenciais fictícias. A CLI retorna DynamoDB-JSON que você lê a olho nu; um A GUI renderiza os mesmos dados que uma tabela que você pode classificar, filtrar e editar.

Em DynoTable, adicione uma conexão e defina um endpoint personalizado:

  • Endpoint: http://localhost:8000 (DynamoDB Local) ou http://localhost:4566 (LocalStack)
  • Região: qualquer que seja o uso do seu aplicativo — por exemplo, nós-leste-1. É um rótulo aqui, não um região AWS real, mas deve corresponder para que você chegue ao mesmo namespace de dados.
  • Chave/segredo de acesso: qualquer coisa (test / test é convencional). Alfanumérico apenas para a chave de acesso em DynamoDB Local.

A partir daí você navega pelos itens, executa um Query ou Scan e edita as linhas visualmente em vez deJSON manualmente na CLI. Quando você carrega fixtures, o Conversor DynamoDB-JSON transforma JSON simples em o formato de ligação e Query vs Scan capas que leem para alcançar. A mesma broca para um LocalStack DynamoDB visualizador — apenas a porta muda para 4566.

DynoTable é um software de desktop somente local, então apontá-lo para localhost mantém seus acessórios em sua máquina. Para uma visão mais ampla das opções da GUI, consulte o DynamoDB Comparação de GUI.

Erros comuns (incompatibilidade de região, porta, credenciais)

  • Conexão recusada. Porta errada — 8000 é DynamoDB Local, 4566 é LocalStack. Confirme também se o contêiner realmente publicou a porta (docker run -p 8000:8000 amazon/dynamodb-local). Para LocalStack, verifique o o serviço está ativo às http://localhost:4566/_localstack/health.
  • O ID da chave de acesso ou token de segurança é inválido em DynamoDB Local. Desde imagem 2.0.0 (e 1.23.0+), o ID da chave de acesso deve ser somente alfanumérico. Uma chave com símbolos que funcionava em uma imagem anterior agora falha — substitua-a por letras/números (por exemplo, test) e atualize todas as ferramentas para corresponder.
  • O token de segurança incluído na solicitação é inválido em relação a LocalStack. Isso quase sempre é um problema de endpoint, não de credenciais — seu SDK cliente abandonou --endpoint-url / endpoint_url e acertou o AWS real endpoint, que rejeita sua chave fictícia. Confirme se o cliente está realmente apontado em http://localhost:4566.
  • Erros de credenciais do SDK/CLI. Até os endpoints locais precisam de algum credenciais presentes. Defina AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (ou um perfil falso) para que a cadeia de credenciais do SDK seja resolvida.
  • http vs https. Os endpoints locais são http simples. Um URL https:// irá falha no handshake TLS.

DynamoDB Local são os mesmos dados das minhas tabelas AWS reais?

Não – local e nuvem são lojas completamente separadas. DynamoDB Local (e LocalStack's DynamoDB) mantém os dados em um arquivo local ou na memória; nunca toca sua conta AWS, e AWS Regiões/contas não são suportadas no nível do cliente localmente. Esse é o ponto: é para desenvolvimento e teste. Se você quiser os mesmos fixtures na nuvem mais tarde, AWS sugere Valores de chave/região de aparência válida localmente para que você troque apenas o endpoint ao mover. Para modelar esse esquema antes você envia, design de tabela única e GSI vs LSI cobrem as decisões que não mudam entre local e produção.

Qual local economiza para você (e qual produto ainda fatura)

DynamoDB Local não mede nada — não RCU, não WCU, sem transferência. O mesmo GetItem contra DynamoDB gerenciado em contas sob demanda us-east-1 0,5 RCU eventualmente consistente ou 1 RCU fortemente consistente para um item ≤ 4 KB. Quando você troca --endpoint-url pelo endpoint real, cada navegação e consulta começa a faturar novamente. Modele o salto com o calculadora de preços e representante de tamanho itens com a calculadora de tamanho de item.

FAQ

Preciso de credenciais AWS reais? Não. Tanto DynamoDB Local quanto LocalStack aceitam valores fictícios. Eles só precisam estar presentes, alfanuméricos (para DynamoDB Local), e consistente em todas as suas ferramentas.

Por que minhas tabelas desaparecem quando troco de ferramenta? Sem -sharedDb, DynamoDB Dados de partições locais por chave de acesso + região em myaccesskeyid_region.db separado arquivos. Use -sharedDb ou mantenha esses valores idênticos em todos os lugares.

Qual é a diferença entre a porta 8000 e 4566? 8000 é independente Padrão de DynamoDB Local; 4566 é a porta de borda única do LocalStack que fica na frente de todos seus serviços emulados, incluindo DynamoDB.

Uma GUI pode se conectar a ambos? Sim — eles falam a mesma coisa DynamoDB API. Apenas o alterações no URL do endpoint (:8000 vs :4566).

O DynamoDB Local é gratuito? Sim. AWS distribui DynamoDB Local sem nenhum custo como um JAR e uma imagem Docker — lá “não há custos provisionados de taxa de transferência, armazenamento de dados ou transferência de dados”; é destinado apenas para desenvolvimento e teste, não produção.

Posso executar SQL em minhas tabelas locais? O DynamoDB local fala o mesmo API que a nuvem, portanto, as mesmas regras de padrão de acesso se aplicam - e os mesmos limites: DynamoDB's Gramática PartiQL SELECT é apenas SELECT … FROM … WHERE … ORDER BY - sem JOIN, sem GROUP BY e sem agrupamento de funções agregadas como COUNT/SUM/AVG (veja PartiQL vs SQL). DynoTableexecuta aqueles consultas analíticas em qualquer conexão, inclusive local.

Tente DynoTable para conectar-se diretamente ao localhost:8000 ou localhost:4566 e navegue, consulte e edite suas tabelas locais com uma GUI.

Atualizado