Hoping for some help with a novice please.

My aim here is just to have somewhere I can easily reference where i’m storing the data as I add more and more stacks.

in Portainer (BE 2.19.1) I’ve created a volume called ‘my_data’. When I look at Portainer volumes it has in the mount point ‘/var/lib/docker/volumes/my_data/_data’. So thats where I’ve put some of the config files and other persistent data I want to use.

I want to use the ‘my_data’ Volume in multiple stacks (using docker compose) as the persistent data storage. I thought I’d be able to say in my compose:

volumes:

`- my_data/changedetection/datastore:/datastore`

However this gives the error:

failed to deploy a stack: service "changedetection" refers to undefined volume my_data/changedetection/datastore: invalid compose project

​

  1. Do I need to have one Volume for every stack so I would just say my_data:/datastore?
  2. Am I better off just ignoring Volumes and putting my persistent files somewhere like /data/my_data/ ?
  3. Am I asking the wrong questions :)

​

  • james-portainer@alien.topBEnglish
    1·
    1 year ago

    Docker doesn’t allow you to mount a subpath of a named volume - you can only mount the named volume itself:

    volumes:
  - my_data:/path/in/container

    When mounting an existing volume in a stack file, you will also need to flag that volume as external otherwise it will try to create it for you. This is done in a separate volumes section outside of the services section:

    volumes:
  my_data:
    external: true

    Do I need to have one Volume for every stack so I would just say my_data:/datastore?

    You can share volumes between containers, however I would generally advise a volume for each. This makes the container configurations more independent of each other, whereas shared volumes are less so.

    Am I better off just ignoring Volumes and putting my persistent files somewhere like /data/my_data/ ?

    It depends. If you only intend to deploy your stack on the one environment and you don’t need the ability to redeploy the stack on another environment, then bind mounts (mounting to a path on the host) are fine. When portability is a concern, named volumes are generally better.

    Am I asking the wrong questions :)

    No such thing :)