I m running into an issue with testing
# spicedb
k
I'm running into an issue with testing locally.
Copy code
version: '3.9'
services:
  db:
    image: postgres:15
    restart: always
    container_name: platform-db
    ports:
      - '5432:5432'
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: platform
    healthcheck:
      test: pg_isready -U postgres -p 5432 -d platform
      interval: 1s
      timeout: 3s
      retries: 5
  spicedb:
    image: authzed/spicedb:latest
    container_name: platform-spicedb
    restart: always
    command: 'serve-testing --load-configs /app/spicedb/schema.yaml'
    ports:
      - '50051:50051'
    environment:
      - SPICEDB_GRPC_PRESHARED_KEY=local
      - SPICEDB_DATASTORE_ENGINE=postgres
      - SPICEDB_DATASTORE_CONN_URI=postgres://postgres:postgres@db:5432/platform
      - SPICEDB_GRPC_ADDR=:${SPICEDB_PORT:-50051}
      - SPICEDB_METRICS_ENABLED=false
      - SPICEDB_TELEMETRY_ENDPOINT=
    volumes:
      - ./data/spicedb/:/app/spicedb/
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test:
        [
          "CMD",
          "/usr/local/bin/grpc_health_probe",
          "-addr",
          "spicedb:50051",
        ]
      interval: 3s
      timeout: 3s
      retries: 5
it runs fine initially but then i start hitting
Error: 2 UNKNOWN: failed to load config files: open /app/spicedb/schema.yaml: no such file or directory
after awhile and the only way to fix it is to restart the container. Have I missed something in the compose file?
v
why are you running
serve-testing
with a datastore?
k
followed another example ¯\_(ツ)_/¯
v
If you want a development SpiceDB with Postgres, I'd suggest following the instructions in https://github.com/authzed/examples/blob/main/datastores/postgres.yml if you want to load that SpiceDB with a specific schema, you can use the
--datastore-bootstrap-files
command of
spicedb serve
(or its equivalent env variable
SPICEDB_DATASTORE_BOOTSTRAP_FILES
we have examples for all the datastores there
k
so i should just use serve instead?
v
I haven't tried but I don't think
serve-testing
is meant to be used with a datastore. It's just an in-memory datastore that you typically use in test suites
k
the one thing i liked about serve-testing is the emphermal instance which i use for "integration" tests
v
yeah, so that's its use.
k
that's why i'm surprised it stops working after a bit
each "token" is supposed to be a new instance
v
but you don't need a datastore for that, and if you are using GitHub Actions, you can use the SpiceDB GitHub Action, which does exactly
serve-testing
k
gotcha, so does the ephermal instance die when all connections are stale or closed?
v
with
serve-testing
yes
k
that's why i'm seeing this
v
let's take a step back, can you describe what you are trying to achieve?
k
a few scenarios. 1. is testing during CI/CD. got that working well already. 2. unit tests locally (same as #1 really) 3. local testing of the backend. This would be nicer to have a non-ephermal instance
j
open /app/spicedb/schema.yaml: no such file or directory
v
serve-testing
is the right tool for the job when running unit tests in your CI pipeline, and also when running unit-testing locally
j
sounds like the volume mount is going bad
v
w.r.t local testing of backend, if you want to have a persistent SpiceDB instance across restarts, you need to use a database, and use
serve
instead of
serve-testing
.
k
yeah i was hoping to keep away from multiple compose/dockerfiles
v
to be more specific:
serve-testing
=
serve
with
memdb
datastore, and one new
memdb
instance per preshared key
k
however if the volume doesn't go away then serve-testing works for all cases
j
so the question is: why is the volume going away?
v
I don't expect spicedb would delete that file in
serve-testing
mode. Maybe you
docker run -ti
into the container and see what's up. I recommend using the
authzed/spicedb:latest-debug
container image so you get a busybox in the container
k
well i can't reproduce with the
uthzed/spicedb:latest-debug
image
v
Have you tried installing spicedb locally from a package and see if you can reproduce the problem? That would allow you to discard SpiceDB as the source of the problem and focus on the docker bits
k
not yet, however latest-debug is still working so my spidey sense thinks it's something in the non-debug image
v
interesting 🤔
3 Views