Error during Deploy: volumes.user_uploads Additional property source is not allowed

Wappler General Need Help
1

I want to change the default location of my host's storage path for my Docker container. I've mounted a Digital Ocean block storage volume to my droplet at /mnt/myblockstoragevolume and I want my project's 'user_uploads' volume to use /mnt/myblockstoragevolume instead of the Docker volume Wappler creates under Docker's installation path.

My staging target's docker-compose.yml file uses the docker installation path to create its storage volumes with this entry:

volumes:
   user_uploads: ~

This places the user_uploads volume under /var/lib/docker/volumes/ (this is not preferred for my staging environment)
I want the user_uploads volume to not be located here and instead to have a Mountpoint at

/mnt/myblockstoragevolume

So I changed my yml file to:

volumes:
  db-volume: ~
  user_uploads:
    source: /mnt/myblockstoragevolume
    target: /opt/node_app/public/videos

When I try to deploy to staging, I get the error message

volumes.user_uploads Additional property source is not allowed

ChatGPT doesn't see anything wrong with this syntax so I'm mostly confident Wappler doesn't like it. Are we not allowed to override Wappler's default Mointpoint path for volumes?

How can I successfully have my staging target set up to use /mnt/myblockstoragevolume for user_uploads?

2

If you deviate from anything Wappler standard, chances are you'll end up fighting Wappler. This is why I moved away from Wappler Docker deployment.

Anyway, answering your question, see the template below:

services:
  <service_name>:
    image: <image_name>
    volumes:
      - <host_directory>:<container_directory>

If you use bind-mount, don't give your volume a name, as exampled above

3

Thanks for the reply @Apple. I would just like to get this working with bind-mount first before exploring Docker-managed volumes.

I have a clarifying question for ya. How do I specify this volume is specifically for 'user_uploads' used in my app? In my current .yml file, in the volumes: section (outside services), it is named, but allowed to be created and mounted under Docker's install path. If I understand your example correctly, I don't see how to tell Docker this is the 'user_uploads' volume.

Also, since the existing 'user_uploads" volume exists/defined, will Wappler or Docker remove that volume before creating a new 'user_uploads' with my desired host_directory under /mnt? I'm comfortable with manually removing docker volumes if needed before a "deploy" from Wappler.

4

The web application you're going to deploy is not aware of volume names, all it cares is a location.

You just bind-mount and hope for the best :stuck_out_tongue:

If you're willing to remove the user_uploads, that would be best to avoid possible conflicts, I could see a problem mounting a volume at a path and then bind-mount to the same path... No idea on what the behaviour would be

5

Your solution appears to have worked. :+1: I provisioned a new server, created and attached block storage to it at /mnt/myprojectstoragename, created a new target in Wappler, edited the resulting .yml file as recommended, and deployed (all greatly simplified, but documented now). I confirmed the file upload API not only still wrote to the DB, but also that the uploaded file existed within /mnt/myprojectstoragename. Thank you.

I didn't have to remove the user_uploads volume since I deployed to a fresh target. Now I will go back to my staging server, remove the user_uploads volume, wipe it clean and redeploy. I want staging to mimic production as close as possible.