Hei there. I’ve read that it’s best practice to use docker volumes to store persistent container data (such as config, files) instead of using bindmount. So far, I’ve only used the latter and would like to change this.

From what I’ve read, all volumes are stored in var/lib/docker/volumes. I also understood, that a volume is basically a subdirectory in that path.

I’d like to keep things organized and would like the volumes of my containers to be stored in subdirectories for each stack in docker compose, e.g.

volumes/arr/qbit /arr/gluetun /nextcloud/nextcloud /nextcloud/database

Is this possible using compose?

Another noob question: is there any disadvantage to using the default network docker creates for each stack/container?

  • krolden@lemmy.ml
    link
    fedilink
    English
    arrow-up
    8
    ·
    1 year ago

    Just do bind mounts unless you really need docker volumes for something

  • Matt The Horwood@lemmy.horwood.cloud
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 year ago

    If you have data else where on your server, you can use the options to volume to direct the mount there

    driver: local driver_opts: type: none o: bind device: ‘/your/current/data’

    Also reading the compose spec will help

    • Pete90@feddit.deOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Thanks, this looks like it’ll do the job. I have not a lot of knowledge, so the specs are often a bit technical for me. I’ll give it a go, thanks!

      • ErwinLottemann@feddit.de
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 year ago

        that is using bin mounts again. and i don’t get why this is discouraged, i actualy do like to know where my data is stored and don’t want to spin up a container that backs up using the volumes managed by docker. at that point you are using bind mounts again anyway.

        regarding your original question, i don’t think it is possible (or even useful) to tell docker where to store the volumes for each compose stack because you are not supposed to access the from the filesystem directly anyway.

        just continue using bind mounts

  • TheHolm@aussie.zone
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 year ago

    Do not access volumes directly on filesystem. path may change. If you need access data on a volume just spawn temporary container an mount that volume.

  • ShortN0te@lemmy.ml
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    Never heard that bindmounts are bad practice. Never had problems with it. What did you read?

    If it ain’t broken …

    • Pete90@feddit.deOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Yeah, that seems to be the gist of it. I’ve seen several people say that they prefer volumes as they are managed by docker and therefore easier to migrate / backup. Since I plan on moving to different hardware in the near future, I figured why not.

      Also something about permissions, though I never had any problems with it. So as you said, I’m sticking with bind mounts for now.

      Also I don’t have a clue what I’m doing at least 50 percent of the time and just follow guides. That’s why I wanted some clarification on that :)

  • Mike@fikaverse.club
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    @Pete90 There is plugins you can use to tell docker where your volumes are. Something like this works for local directories:

    Docker will create a _data directory as usual.

    volumes:
    web_data:
    db_data:
    driver: local # Define the driver and options under the volume name
    driver_opts:
    type: none
    device: /data/myservice/db_data
    o: bind

    • ErwinLottemann@feddit.de
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      this is a bind mount, defining them like this in a compose file is for when multiple containers share volumes, you just need to write the name of the volume instead of the path, but…

       - database:/var/lib/mysql
      

      is not that much less than

       - ./database:/var/lib/mysql
      

      🤷

    • Pete90@feddit.deOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Ah, so I basically specify with driver and it’s option(s) where to save the volume. I’ll play around with it for a bit and see where it goes. Thanks!

  • adONis@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    tbh…I hate volumes. I prefer having my docker data in my home folder, which I do regularly back up