docker-compose volumes about appwrite

[eldadfux]

Hey @mostafahussein, so I took your advice and moved all our docker-compose files to use volumes instead of mounts. This seems to really help solve some of the problems we faced related to read and write permissions errors in the DB or storage services.

Thanks!!

[mostafahussein]

Glad to hear that!

[eldadfux]

These are the volumes we need for development only mode. Up until our latest version, we only mapped the ./storage directory, but that caused some permission issues for some developers (storage also contains DB directories).

The production public docker-compose is here: https://appwrite.io/docker-compose.yml

This is the docker-compose.yml we give non-maintainers to setup.

Named volumes sound like a good idea, but I am not familiar with them. What are their advantages compared to plain volumes?

[mostafahussein]

Named volumes are completely managed by Docker, not by your side. But as you use it for developers I would suggest having the following structure:
1- docker-compose.yml
2- docker-compose.development.yml
2- docker-compose.public.yml
And we you run it you would need to use the following command:

# In case of development usage
docker-compose up -d -f docker-compose.yml -f docker-compose.development.yml

Next, we can have both the path based volumes inside the development file and the needed named volumes inside the public file because the public/development file will override the already existing keys. so for example, if you have an environment called X=hello inside docker-compose.yml you can override it by defining it inside one of these additional files.