Add a database volume to docker-compose file

[oDeano]

When adding drizzle, the adder creates a compose file for the db but doesn't add a volume to persist the data, is it worthwhile to add it to the template?

services:
  db:
    image: postgres
    restart: always
    ports:
      - 5432:5432
    environment:
      POSTGRES_USER: root
      POSTGRES_PASSWORD: mysecretpassword
      POSTGRES_DB: local
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

[manuel3108]

This sounds like a reasonable idea, though I'm not sure if there is a proper cross-platform way? At least for windows it seems that we need to use the windows path syntax

My docker experience is limited, but is there a way to use a local path? Because otherwise in windows we would need to be aware of the partition the user installed windows, as it does not need to be C:\\

Or are you aware of any cross-platform way of doing this?

[Conduitry]

The proposal in the issue uses a named volume, which exists in a place on the filesystem completely managed by Docker. It's a slightly different sort of thing than mounting a specific path.

Docker itself doesn't let you use relative paths for filesystem volume mounts, but Docker Compose does. The question, then, is whether it seems like a good idea to put the Postgres data in a subdirectory of the user's source code. I don't know. It's fairly likely that users are going to want to change this or do something completely different in production.

Should we prioritize making this Just Work in local development, or do we want to make users start to think about things like where their database will live before they start thinking about deploying to production?

[manuel3108]

In that case, making it work for local development should be just fine and work well enough for everyone. At least, better than it is right now,

[Conduitry]

I think I'd lean toward a named volume, like the OP suggests. That avoids issues where some files get created in the project's directory that are owned by another user and are annoying to delete. Named volumes also get prefixed with the project name by Docker Compose (which defaults to the directory name containing the docker-compose.yaml), so while there's still more risk of collisions than with using local files, the risk still isn't huge.