fix(volume): restrict persisting to user data

[SimJoSt]

This enables updating Grav via Docker, as the Grav code is not persisted in a volume anymore.

[SimJoSt]

Before this change using/build a Docker image with a new version of Grav didn't actually updated Grav to this version, as the Grav code was persisted in the previous volume. Updating had to be done via the web interface, which goes against the concept of versioning the application in Docker images.

[dudeitssm]

@SimJoSt The benefits if we use your PR are two fold, if I'm understanding correctly:

1. you isolate the volumes to be more easily manageable (one for logs, one for the userdata/application stuff, and one for backups)
2. you make it so future updates to Grav take effect if you decide to update the image, and subsequently the container

How would I go about testing point number 2 myself, without waiting for Grav to release a new version? Is it possible?

Pointers or details would be appreciated.

---

I was testing your PR out (seems to be working nicely). Installed themes, made a backup, etc. All good.

This is the launch command I used (note: I am using the nginx variant, for which gushmazuko created a PR):

podman run -d -p 8000:80 --restart always \
-v grav-backup:/usr/share/nginx/html/backup \
-v grav-logs:/usr/share/nginx/html/logs \
-v grav-data:/usr/share/nginx/html/user localhost/grav-nginx-volumefix

[SimJoSt]

@dudeitssm it is possible to build a Docker image locally and tag it with a specific number. So you could build a Grav Docker image and tag it with an imaginary future version, and then reference that one in the docker-compose.yml file. Another way would be to start a Grav container/volume, downgrade the files in there to a previous version, and then run docker pull.

As Grav updates are pushed quite regularly, you could probably test it easily with new releases :)