Skip to content

dev-image.md

Latest commit

 

History

History
98 lines (77 loc) · 3.96 KB

dev-image.md

File metadata and controls

98 lines (77 loc) · 3.96 KB
Raw

The extenddb-dev Image

extenddb/extenddb-dev is a single-container, DynamoDB-compatible endpoint over SQLite, built for local development and CI. There is no external database, no init step, and no certificate to trust:

docker run -d -p 127.0.0.1:18080:18080 -v extenddb:/var/lib/extenddb \
  extenddb/extenddb-dev
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE \
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
aws dynamodb list-tables \
  --region us-east-1 --endpoint-url http://127.0.0.1:18080

It is not the production image. For a durable, TLS-terminated deployment use extenddb/extenddb-postgres.

What "dev-mode" means

The image is compiled with the dev-mode feature, which trades hardening for zero-friction local use:

  • Plain HTTP. No TLS, so SDKs need no custom trust store.
  • A seeded, well-known credential. The server seeds AWS's documented example key pair (AKIAIOSFODNN7EXAMPLE / wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY) on every startup and prints it in the logs; sign requests with it. It is recognised by secret scanners as an example credential, so committing it in test fixtures is safe. To seed one additional key pair, pass EXTENDDB_DEV_ACCESS_KEY_ID and EXTENDDB_DEV_SECRET_ACCESS_KEY to the container (the key id must start with AKIA; its secret is never printed). The example pair keeps working alongside it, so tools that hardcode it (NoSQL Workbench, the launchers) are unaffected by the override. The standard AWS_* variables are ignored by the server, so real or SSO credentials in the environment are never copied into the dev catalog; a startup notice calls out an AWS_ACCESS_KEY_ID that would not verify. Authorization is open: whoever holds a seeded credential can do everything.

Because of that, the server must not be reachable from other machines. The image binds 0.0.0.0 inside the container (required for port publishing to work at all; this is what EXTENDDB_DEV_ALLOW_ANY_BIND=1 in the image enables), and containment moves to the publish flag: always bind the host side to loopback, -p 127.0.0.1:18080:18080, as every example here does. Do not publish this port on a shared or routable interface.

Storage modes

One image serves both modes; the mode is chosen at run time.

File-backed (default). The database lives at /var/lib/extenddb/extenddb.sqlite. Mount a volume there and data survives container restarts and upgrades:

docker run -d -p 127.0.0.1:18080:18080 -v extenddb:/var/lib/extenddb \
  extenddb/extenddb-dev

In-memory. Everything lives in process memory and vanishes when the container stops — useful for test suites that want a pristine database per run:

docker run -d -p 127.0.0.1:18080:18080 \
  -e EXTENDDB__STORAGE__SQLITE__PATH=:memory: \
  extenddb/extenddb-dev

docker-compose.dev.yml at the repository root defines both as services (extenddb-dev, and extenddb-dev-memory under the memory profile).

Health

The image carries a Docker HEALTHCHECK (the binary's own healthcheck subcommand over plain HTTP), so docker ps and compose depends_on: condition: service_healthy work with no extra wiring.

Image properties

  • Runtime base is distroless (gcr.io/distroless/cc-debian12:nonroot): no shell, no package manager, runs as uid 65532. docker exec into it is not possible by design.
  • The binary is built with the release-slim profile (stripped, LTO).
  • Licence notices for this image's exact dependency set ship at /usr/share/doc/extenddb/SOFTWARE-LICENSE-NOTICES.html (generated by devtools/generate-dev-license-notices).
  • Signed with Sigstore cosign; verify as described on the image's Docker Hub overview.

Limitations

  • Single node, single process. Throughput settings are accepted and tracked but not enforced as capacity.
  • No TLS and no access control (see dev-mode above): never expose it beyond the local machine, and never store real data in it.