I tend to run my programs on one bigger database server instead of giving every docker container their own. I'd recommend adding environment variables for database type, host, user, password and database.
Already exists, see https://github.com/photoprism/photoprism/wiki/Configuration
| Parameter Name | Environment Variable |
|:------------------|:---------------------------|
| database-driver | PHOTOPRISM_DATABASE_DRIVER |
| database-dsn | PHOTOPRISM_DATABASE_DSN |
So for everyone not wanting to mess with docker compose, here's a simple example on how to get it up and running:
docker run --name=photoprism -p 80:80 \
-v prism-data:/srv/photoprism/photos \
-v prism-cache:/srv/photoprism/cache \
-e PHOTOPRISM_DATABASE_DRIVER=mysql \
-e PHOTOPRISM_DATABASE_DSN="user:password@tcp(database-host)/database" \
-d photoprism/photoprism:latest
I used named volumes so you can use any driver like local or local-persistent to adding your collection
Thank you! We can add that to our docs, for developers / testers that don't use docker-compose.
May I ask why you think it is a mess? I'm really curious.
If you have many env variables, volumes and dependencies like MySQL, YAML seems much easier to maintain and share. The final release will be a single binary, so no more Docker required (just for building unless developers prefer to work like 10 years ago because manually taking care of all dependencies was more fun).
I wasn't saying "it is a mess" - but I don't like docker-compose for the reason it's an additional binary I would have to add to my stack instead of keeping it to the bare minimum.
Most helpful comment
So for everyone not wanting to mess with docker compose, here's a simple example on how to get it up and running:
I used named volumes so you can use any driver like local or local-persistent to adding your collection