Using A Digital Ocean Block Storage Volume for a Docker Volume

[GraybeardCoder]

Before I go editing any docker files, I wanted to put my thought process out there to the community. I've seen/read quite a few posts today on DO storage and Docker, some quite old at this point. I think I have an understanding of how the preferred (by Docker) method is executed.

Steps:

1. I've created a volume in the DO control panel, gave it a name and let the control panel format and mount it to my droplet.
2. DO had a nifty "Config instructions" with a bash command to add a mount point in /etc/fstab so the mount would persist upon host restarts.
3. I rebooted the host and did a 'findmnt /mnt/mynewvolume', it was mounted successfully on restart.

I want /mnt/mynewvolume to be the location where /public/videos (User Uploads Folder) are saved. I've already configured this (/public/videos) in Wappler's Project Options and have been using /public/videos successfully with my API's in dev and staging environments.

4. I created the public/videos folders at this new mount point (as root): /mnt/mynewvolume/public/videos

I've located the docker-compose.yml file for my remote ('DO Staging') server within the .wappler folder structure. Currently for the web service, the yml file says:

volumes:
      - 'user_uploads:/opt/node_app/public/videos:rw'

On my remote server, a 'docker volume inspect' command reveals that the "user_uploads" is mounted on the host at: /var/lib/docker/volumes/myproject_user_uploads/_data. Is it just a matter of updating my staging target's docker-compose.yml file to:

volumes:
  user_uploads:/mnt/ffuser_fcc/public/videos:rw

Is this all that's necessary?

and congrats Wappler team on another fine update

[Cheese]

I'm not sure if you will run in to the issue of the uploads directory being outside of the Project root...? This can cause issues. You could however overcome this using a symlink (Digital Ocean provide a useful guide) to the new directory/mount point. All you can do is to try and see what happens but take a Snapshot on Digital Ocean, and backup locally, at least that way you can revert if need be.

[GraybeardCoder]

Thanks @Cheese. Symlink was an option but not as performant according to Docker as using their volume management. Fortunately, nothing critical on the staging server so trial and errors are ok.

I made the change to my staging server's docker-compose.yml file (on my local Wappler laptop) and redeployed. The previous Docker volume was still defined and uploading a new file still landed in the /var/lib/docker/volumes.../_data folder. So I'm not quite there yet.

[Cheese]

@GraybeardCoder

Symlink was an option but not as performant according to Docker as using their volume management.

I'd run a test and see how the performance is hit if at all... It is all on the same network so should be negligible?

An alternative to get around the Project root issue would be to set up the second container as a new Project with only upload Actions, and then like with a mobile Project have a two Project approach. You can then use the Actions of the second (lets call it storage container) within your Primary Project. That way theoretically you won't have a Project root issue as it will be uploading to its own environment and no path issues should arise,,, If any arise in your current approach.