search

MatchbookLab / local-persist

Create named local volumes that persist in the location(s) you want
MIT License
852 stars 123 forks source link

Some thoughts #30

Closed sanderploegsma closed 8 years ago

sanderploegsma commented 8 years ago

First off, great work! I'm facing the exact same issue with named volumes and persistence (I want to create an HTPC stack in which the services need to share persisting volumes for media and downloads), but I am currently forced to use DOCs. This introduces the issue you so aptly state in the Benefits section of the Readme: every container maps the volumes to the same path.

I desperately want to use this plugin but some things do concern me:

I was thinking that it might be possible to run your containerized plugin in my Compose cluster. This way, I still have one place where I define the local mount points for the volumes used by every service. My only concern is that, apart from the extreme overhead, the volume creation takes place before the services are created, rendering the entire setup impossible. I haven't tried this yet, would such a thing even be possible?

Long story short: this should definitely be core functionality. Having to install third-party plugin software as a separate service not only introduces unnecessary complications but also goes against the Docker principle, IMHO.

CWSpear commented 8 years ago

So that's how all plugins works (i.e. all (well, I haven't vetted every one) of the ones here: https://docs.docker.com/engine/extend/plugins/). They either run as a service on the host (recommended) or can be run from another Docker container, which does indeed need you to share the directories you want to mount in this case.

A common technique for this is to use a pattern like /data/<project-name>/folder/ and then you just have to share /data/. That may not be an option in all cases, but if you have control over that stuff, may be the way to go.

Another thing you're overlooking: Docker only runs on linux OS with amd64 architecture1. This plugin runs on linux/amd64. My plugin isn't limiting your host OS, Docker is.

On to your last point... I'm not actually sure what you mean by running it in your "Compose cluster," so I kind of got lost there. But your other points aren't really valid in the sense that they're just "the way it is," so I don't think a change is necessary. I'm still willing to discuss, but gonna go ahead and close the ticket.

[1] I think they may also support freeBSD, but it's quite uncommon right now. arm has unofficial support. I could create binaries for these two platforms if people were interested, but it hasn't come up yet. Also note that they advertise that the "Docker for Mac Beta" runs right on OS X (soon to be macOS), but that isn't true: it still needs a VM, and it doesn't currently support plugins, but it's coming. ↩

sanderploegsma commented 8 years ago

Hey, thanks for your thoughts!

A common technique for this is to use a pattern like /data/<project-name>/folder/ and then you just have to share /data/.

That's a good one, I did not think of that!

My plugin isn't limiting your host OS, Docker is.

Fair enough, although I liked how you just can just docker-compose up something and it works, remembering to install plugin X and Y kind of takes away the fun 😉 .

I'm not actually sure what you mean by running it in your "Compose cluster"

Yeah, sorry, that's kind of a weird way to put it. My thought was that I could run the plugin container you provided as a service through my docker-compose.yaml. The problem though is that the volumes in the compose file are probably created before the services are, defeating the purpose. Do you see where I'm getting at.

Finally, I never meant to open this issue to tell you that you should change the plugin. I just had some concerns on the best way to achieve what I was trying to build. It's just a shame that the docker team doesn't see this as a valid core functionality, is all...