DynoTable
Intermedio7 min di lettura

Come connettersi a DynamoDB Local e LocalStack

Hai un DynamoDB locale in esecuzione e il tuo codice ci parla bene, ma lo vuoi per vedere le tabelle, non scrivere uno script scan ogni volta. Connessione di un client a un endpoint locale prevede due modifiche: punta all'URL corretto e consegnalo usa e getta credenziali. I dettagli di seguito sono i punti in cui le persone rimangono bloccate: spazi dei nomi delle regioni, la regola della chiave alfanumerica e la suddivisione della porta "8000" vs "4566".

DynamoDB Local vs LocalStack: a cosa ti stai connettendo

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

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

La configurazione di endpoint e credenziali fittizie che fa inciampare tutti

Gli AWS SDK e la CLI richiedono una chiave di accesso e una regione anche quando si parla con a endpoint locale, ma tali valori non devono essere reali. Lo dicono i documenti di AWS questi valori "non devono essere valori AWS validi per essere eseguiti localmente" (AWS documenti).

Due trucchi che non sono ovvi:

  • La regione/chiave di accesso assegna silenziosamente gli spazi dei nomi ai tuoi dati. Senza il Il flag -sharedDb, DynamoDB Local scrive un myaccesskeyid_region.db separato file per combinazione ID chiave di accesso + regione: denominazione esatta di AWS. Connettiti con una chiave o una regione diversa da quella utilizzata dalla tua app e le tue tabelle appariranno come se fossero scomparsi; sono solo in un altro file. Esegui con -sharedDb (one shared-local-instance.db per ogni client) o corrispondere alla chiave esatta + regione utilizza la tua app.
  • L'ID della chiave di accesso deve essere alfanumerico su DynamoDB Local — nessun simbolo. AWS documenti lo stato AWS_ACCESS_KEY_ID può contenere solo A–Z, a–z e 0–9; AWS introdotto questo in DynamoDB Local 2.0.0 (e 1.23.0+), quindi una chiave con caratteri speciali che lavorato su un'immagine precedente ora fallisce (AWS re:Post). Vedi l'errore qui sotto.

Per LocalStack il valore predefinito sicuro è test / test: it ignora completamente la chiave segreta e non convalida mai il valore segreto. I tasti "AKIA..."/"ASIA..." dall'aspetto reale lo sono rifiutato come salvaguardia e ricorso all'account fittizio 000000000000 — lo stesso account a cui si risolve una chiave arbitraria come "test". Continua con "test".

Connessione con la AWS CLI (controllo di integrità)

Prima di puntare una GUI su di esso, verificare che l'endpoint sia attivo dalla CLI. La CLI non ha nessun endpoint locale predefinito integrato, quindi passa --endpoint-url per comando o set AWS_ENDPOINT_URL_DYNAMODB=http://localhost:8000 (CLI v2.13+).

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 (anche quelle false in ~/.aws/credentials o tramite AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY), questo restituisce l'elenco delle tabelle. Un elenco vuoto senza errori significa che l'endpoint funziona ma stai visualizzando un file spazio dei nomi chiave/regione diverso: vedere il trucco sopra.

DynamoDB Local GUI: navigazione e interrogazione delle tabelle locali in DynoTable

Una volta che la CLI funziona, una GUI necessita degli stessi tre valori: endpoint, region, e qualsiasi credenziale fittizia. La CLI restituisce DynamoDB-JSON letto a occhio; un La GUI visualizza 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) o http://localhost:4566 (LocalStack)
  • Regione: qualunque cosa utilizzi la tua app, ad es. us-east-1. È un'etichetta qui, non un regione AWS reale, ma deve corrispondere in modo da arrivare nello stesso spazio dei nomi dei dati.
  • Chiave di accesso/segreto: qualsiasi cosa (test / test è convenzionale). Alfanumerico solo per la chiave di accesso su DynamoDB Local.

Da lì puoi sfogliare gli elementi, eseguire Query o Scan e modificare visivamente le righe invece diJSON manualmente sulla CLI. Quando carichi i dispositivi, il file DynamoDB-JSON convertitore trasforma il semplice JSON in il formato del cavo e Query vs Scan copre la lettura raggiungere. Stesso esercizio per a LocalStack DynamoDB visualizzatore — solo la porta cambia in "4566".

DynoTable è un software desktop solo locale, quindi puntarlo su localhost continua i tuoi dispositivi sulla tua macchina. Per uno sguardo più ampio alle opzioni della GUI, vedere il DynamoDB Confronto GUI.

Errori comuni (mancata corrispondenza della regione, della porta, delle credenziali)

  • Connessione rifiutata. Porta errata: "8000" è DynamoDB Local, "4566" è LocalStack. Conferma inoltre che il contenitore ha effettivamente pubblicato il porto (docker run -p 8000:8000 amazon/dynamodb-local). Per LocalStack, controlla il il servizio è scaduto http://localhost:4566/_localstack/health.
  • L'ID chiave di accesso o il token di sicurezza non è valido su DynamoDB Local. Da l'immagine 2.0.0 (e 1.23.0+), l'ID della chiave di accesso deve essere Solo alfanumerico. Una chiave con simboli che funzionava su un'immagine precedente ora non funziona: sostituiscila con lettere/numeri (ad esempio test) e aggiorna ogni strumento in modo che corrisponda.
  • Il token di sicurezza incluso nella richiesta non è valido contro LocalStack. Si tratta quasi sempre di un problema di endpoint, non di credenziali: il tuo SDK il client ha eliminato --endpoint-url / endpoint_url e ha premuto il vero AWS endpoint, che rifiuta la chiave fittizia. Conferma che il client sia effettivamente puntato su "http://localhost:4566".
  • Errori di credenziali da SDK/CLI. Anche gli endpoint locali necessitano di alcuni credenziali presenti. Imposta AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (o un profilo falso) in modo che la catena di credenziali dell'SDK venga risolta.
  • http vs https. Gli endpoint locali sono semplici http. Verrà visualizzato un URL "https://". fallire l'handshake TLS.

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

No: locale e cloud sono negozi completamente separati. DynamoDB Local (e LocalStack's DynamoDB) mantiene i dati in un file locale o in memoria; non tocca mai il tuo account AWS e AWS Le regioni/gli account non sono supportati a livello di client localmente. Questo è il punto: lo è per sviluppo e test. Se desideri gli stessi dispositivi nel cloud in un secondo momento, AWS suggerisce Valori chiave/regione valid-looking localmente in modo da scambiare l'endpoint solo quando ti sposti. Per modellare quello schema prima lo spedisci, design a tabella singola e GSI vs LSI copre le decisioni che non cambiano tra locale e prod.

Quale locale ti fa risparmiare (e quale prodotto continua a fatturare)

DynamoDB Local metri niente — no RCU, no WCU, nessun trasferimento. Lo stesso GetItem contro DynamoDB gestito nelle fatture su richiesta us-east-1 0,5 RCU eventualmente coerente o 1 RCU fortemente coerente per un elemento ≤ 4 KB. Quando scambi --endpoint-url con l'endpoint reale, ogni navigazione e query ricomincia a fatturare. Modella il salto con il calcolatore dei prezzi e rappresentante delle dimensioni elementi con il calcolatore delle dimensioni degli elementi.

FAQ

Ho bisogno di credenziali AWS reali? No. Sia DynamoDB Local che LocalStack accettano valori fittizi. Devono solo essere present, alfanumerico (per DynamoDB Local), e coerente tra i tuoi strumenti.

Perché le mie tabelle scompaiono quando cambio strumento? Senza -sharedDb, DynamoDB Dati delle partizioni locali per chiave di accesso + regione in myaccesskeyid_region.db separato file. Utilizza -sharedDb o mantieni questi valori identici ovunque.

Qual è la differenza tra la porta 8000 e 4566? "8000" è autonomo Il valore predefinito di DynamoDB Local; "4566" è la porta a bordo singolo di LocalStack che fronteggia tutto i suoi servizi emulati, DynamoDB incluso.

Una GUI può connettersi a entrambe? Sì, parlano lo stesso DynamoDB API. Solo il Modifiche all'URL dell'endpoint (:8000 anziché :4566).

DynamoDB Local è gratuito? Sì. AWS distribuisce DynamoDB Local gratuitamente come a JAR e un'immagine Docker — lì non sono previsti costi di throughput, archiviazione o trasferimento dati"; lo è destinato solo allo sviluppo e ai test, non la produzione.

Posso eseguire SQL contro i miei tabelle locali? Local DynamoDB parla lo stesso di API nel cloud, quindi si applicano le stesse regole del modello di accesso e gli stessi limiti: DynamoDB PartiQL Grammatica SELECT è solo "SELECT... FROM... WHERE... ORDER BY" — niente "JOIN", niente "GROUP BY" e nessun raggruppamento di funzioni aggregate come COUNT/SUM/AVG (vedi PartiQL vs SQL). DynoTableli gestisce query analitiche su qualsiasi connessione, locale inclusa.

Prova DynoTable per connetterti direttamente a localhost:8000 o localhost:4566 e sfoglia, interroga e modifica le tue tabelle locali con una GUI.

Aggiornato