DynoTable
Intermedio7 min di lettura

Come connettersi a DynamoDB Local e LocalStack

Hai un DynamoDB locale in esecuzione e il tuo codice ci dialoga senza problemi — ma vuoi vedere le tabelle, non scrivere uno script scan ogni volta. Connettere un client a un endpoint locale richiede due cambiamenti: puntare all'URL giusto e passargli credenziali usa e getta. I dettagli qui sotto sono i punti in cui la gente si blocca — il namespacing della region, la regola sulle chiavi alfanumeriche e la divisione tra le porte 8000 e 4566.

DynamoDB Local vs LocalStack: a cosa ti stai connettendo

Entrambi ti offrono un'API DynamoDB su localhost senza account AWS, ma sono cose diverse:

Quindi l'unica differenza pratica per connettersi è l'URL dell'endpoint: :8000 per DynamoDB Local standalone, :4566 per DynamoDB-via-LocalStack. Tutto il resto — l'API, il trucco delle credenziali, la configurazione della GUI — è identico.

Il setup endpoint + credenziali fittizie che frega tutti

Gli SDK AWS e la CLI richiedono una chiave di accesso e una region anche quando dialogano con un endpoint locale — ma quei valori non devono essere reali. La documentazione di AWS stessa dice che questi valori "non devono essere valori AWS validi per girare in locale" (documentazione AWS).

Due insidie non ovvie:

  • La region/chiave di accesso fa silenziosamente il namespacing dei tuoi dati. Senza il flag -sharedDb, DynamoDB Local scrive un file myaccesskeyid_region.db separato per ogni combinazione di access-key-ID + region — la denominazione esatta di AWS. Connettiti con una chiave o una region diversa da quella usata dalla tua app e le tue tabelle sembreranno svanite; sono semplicemente in un altro file. Esegui con -sharedDb (un solo shared-local-instance.db per ogni client) oppure usa esattamente la chiave + region usate dalla tua app.
  • L'access key ID deve essere alfanumerico su DynamoDB Local — niente simboli. La documentazione AWS indica che AWS_ACCESS_KEY_ID può contenere solo A–Z, a–z e 0–9; AWS ha introdotto questo in DynamoDB Local 2.0.0 (e 1.23.0+), quindi una chiave con caratteri speciali che funzionava su un'immagine precedente ora fallisce (AWS re:Post). Vedi l'errore più sotto.

Per LocalStack l'impostazione predefinita sicura è test / test: LocalStack ignora del tutto la secret key e non ne convalida mai il valore. Le chiavi dall'aspetto reale AKIA…/ASIA… vengono rifiutate come misura di sicurezza e ricadono sull'account fittizio 000000000000 — lo stesso account a cui una chiave arbitraria come test viene risolta. Resta su test.

Connettersi con la AWS CLI (controllo di integrità)

Prima di puntarci una GUI, conferma che l'endpoint sia attivo dalla CLI. La CLI non può usare per default un endpoint locale, quindi passi --endpoint-url su ogni comando.

DynamoDB Local:

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

LocalStack (stesso comando, porta diversa):

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

Se hai credenziali configurate in qualche modo (anche fittizie in ~/.aws/credentials o via AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY), questo restituisce l'elenco delle tue tabelle. Un elenco vuoto senza errori significa che l'endpoint funziona ma stai guardando un namespace chiave/region diverso — vedi l'insidia sopra.

GUI per DynamoDB Local: sfogliare e interrogare le tabelle locali in DynoTable

Una volta che la CLI funziona, una GUI ha bisogno degli stessi tre valori: endpoint, region e qualsiasi credenziale fittizia. La CLI restituisce DynamoDB-JSON che leggi a occhio; una GUI rende gli stessi dati come una tabella che puoi ordinare, filtrare e modificare.

In DynoTable, aggiungi una connessione e imposta un endpoint personalizzato:

  • Endpoint: http://localhost:8000 (DynamoDB Local) oppure http://localhost:4566 (LocalStack)
  • Region: qualunque cosa usi la tua app — es. us-east-1. Qui è un'etichetta, non una vera region AWS, ma deve corrispondere così da finire nello stesso namespace di dati.
  • Chiave di accesso / secret: qualsiasi cosa (test / test è la convenzione). Solo alfanumerica per la chiave di accesso su DynamoDB Local.

Da lì sfogli gli item, esegui una Query o uno Scan e modifichi le righe visivamente invece di marshalling il JSON a mano sulla CLI. Quando carichi delle fixture, il convertitore DynamoDB-JSON trasforma il JSON semplice nel formato wire, e Query vs Scan copre quale lettura scegliere. Stessa procedura per un viewer DynamoDB di LocalStack — cambia solo la porta a 4566.

DynoTable è software desktop solo-locale, quindi puntarlo a localhost mantiene le tue fixture sulla tua macchina. Per uno sguardo più ampio sul panorama delle GUI, vedi il confronto delle GUI per DynamoDB.

Errori comuni (region non corrispondente, porta, credenziali)

  • Connection refused. Porta sbagliata — 8000 è DynamoDB Local, 4566 è LocalStack. Conferma anche che il container abbia effettivamente pubblicato la porta (docker run -p 8000:8000 amazon/dynamodb-local). Per LocalStack, controlla che il servizio sia attivo su http://localhost:4566/_localstack/health.
  • The Access Key ID or Security Token is Invalid su DynamoDB Local. Dall'immagine 2.0.0 (e 1.23.0+), l'access key ID deve essere solo alfanumerico. Una chiave con simboli che funzionava su un'immagine precedente ora fallisce — sostituiscila con lettere/numeri (es. test) e aggiorna ogni strumento perché corrisponda.
  • The security token included in the request is invalid contro LocalStack. È quasi sempre un problema di endpoint, non di credenziali — il tuo client SDK ha perso il --endpoint-url / endpoint_url e ha colpito il vero endpoint AWS, che rifiuta la tua chiave fittizia. Conferma che il client punti effettivamente a http://localhost:4566.
  • Errori di credenziali dall'SDK/CLI. Anche gli endpoint locali hanno bisogno di qualche credenziale presente. Imposta AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (o un profilo fittizio) così che la catena di credenziali dell'SDK si risolva.
  • http vs https. Gli endpoint locali sono http semplice. Un URL https:// fallirà l'handshake TLS.

DynamoDB Local sono gli stessi dati delle mie vere tabelle AWS?

No — locale e cloud sono store completamente separati. DynamoDB Local (e il DynamoDB di LocalStack) tiene i dati in un file locale o in memoria; non tocca mai il tuo account AWS, e a livello di client le Region/gli account AWS non sono supportati in locale. È proprio questo il punto: è per sviluppo e test. Se in seguito vuoi le stesse fixture nel cloud, AWS suggerisce valori chiave/region dall'aspetto valido in locale, così da dover cambiare solo l'endpoint quando ti sposti. Per modellare quello schema prima di rilasciarlo, single-table design e GSI vs LSI coprono le decisioni che non cambiano tra locale e prod.

FAQ

Mi servono vere credenziali AWS? No. Sia DynamoDB Local sia LocalStack accettano valori fittizi. Devono soltanto essere presenti, alfanumerici (per DynamoDB Local) e coerenti tra i tuoi strumenti.

Perché le mie tabelle spariscono quando cambio strumento? Senza -sharedDb, DynamoDB Local partiziona i dati per chiave di accesso + region in file myaccesskeyid_region.db separati. Usa -sharedDb o mantieni quei valori identici ovunque.

Qual è la differenza tra la porta 8000 e la 4566? 8000 è la predefinita di DynamoDB Local standalone; 4566 è l'unica edge port di LocalStack che fa da fronte a tutti i suoi servizi emulati, DynamoDB incluso.

Una sola GUI può connettersi a entrambi? Sì — parlano la stessa API DynamoDB. Cambia solo l'URL dell'endpoint (:8000 vs :4566).

DynamoDB Local è gratuito? Sì. AWS distribuisce DynamoDB Local senza costi come JAR e come immagine Docker — non ci sono "costi di throughput provisioned, storage dati o trasferimento dati"; è pensato solo per sviluppo e test, non per la produzione.

Posso eseguire SQL sulle mie tabelle locali? Il DynamoDB locale parla la stessa API del cloud, quindi valgono gli stessi pattern di accesso — e gli stessi limiti: la grammatica SELECT di PartiQL di DynamoDB è solo SELECT … FROM … WHERE … ORDER BY — niente JOIN, niente GROUP BY e nessuna funzione di aggregazione come COUNT/SUM/AVG (vedi PartiQL vs SQL). Il SQL Workbench di DynoTable esegue quelle query analitiche su qualsiasi connessione, locale inclusa.

Prova DynoTable per connetterti direttamente a localhost:8000 o localhost:4566 e sfogliare, interrogare e modificare le tue tabelle locali con una GUI.

Aggiornato