I started playing with Flocker for my persistent storage needs and I really like it. I have not had the greatest experience with Convoy NFS, and for what it’s worth, I really don’t want to use NFS for my production stack.
Anyway: Flocker allows me to use volumes on central persistent storage, and volumes move with a container. If a container moves from node1 to node2, the (persistent data) volume moves with it - slick.
Now my question:
I have a specific application where each instance of a service needs its own persistent data volume. However, when I scale up a service, they all get the exact same volume configuration. I’d love for the volume name to be dynamic - maybe even simply the container name. That way, when I scale up a service, the new containers would get their own volume using the same volume driver as the original service.
Basically, if I have a stack “frontend” with a service “nginx”, I’d like for each instance of this service to get its own named volume “frontend_nginx_1”, “frontend_nginx_2”, etc…
I know docker-compose supports variable interpolation in the .yml file. I wonder how this would behave within rancher? Can something be hacked together with what exists today, or is this a feature request?
We do something similar to what you are looking for with rancher-compose.yml files and custom catalog entries.
Here you can use questions in the rancher-compose files as variables, that can then be used in your docker-compose files.
So when we define volume sin docker-compose, we do this with something like this:
volumes:
- ${INSTANCE_NAME}-mongo-data:/data/db
volume_driver: ${VOLUME_DRIVER}
Where INSTANCE_NAME and VOLUME_DRIVER are questions from the rancher-compose file.
You can also use things like the stack name and the service name within a stack using built in rancher variables.
Beautiful! I tried finding a list of available existing variables, but failed - do you have a link to a list?
Also, using rancher-compose questions wouldn’t give me what I need, because the answer would still be the same for each instance of the service. I assume $INSTANCE_NAME is a magic variable that would be set to “frontend_nginx_2” in my example?
I’ll play around with this a bit with simple env vars.
Hrm. I see rancher only interpolates environment variables in docker-compose.yml. It doesn’t appear to have a built-in list of “magic” variables for each instance. Unless I haven’t found them yet.
In your example, if you scale up that mongo service, each instance will still have the same volume, correct?
Yes, you are correct that each instance would have the same volume - which will be a problem. So we may need to adjust the naming a bit.
$INSTANCE_NAME is a variable we have defined as a standard question in most of our catalog templates - and one we use in a number of places. So you won’t find that anywhere 
you should be able to find references to $${stack_name} and $${service_name}. I cannot remember if they give you what you are looking for.
Yeah - just looking through the community catalog. It appears these kinds of variables are only valid for scheduler rules and not anywhere else. Bummer.
I’ll log a feature request. Thank you for your help @Thomas_Hansen!
You’re welcome.
I am keen to hear what you come up with when you solve it.
Also very interested in knowing more about your Flocker experiences with Rancher. The whole topic of persistent and distributed storage is a key one for us - and I expect for many others as well.
1 Like
Yes - I find docker and persistent volumes to still be a huge stumbling block. I have hit some troubles with Convoy NFS. But all that aside, no one wants to use NFS for production setups anyway anymore. It has caused me and my team enough sleepless nights.
If I had the resources, I’d rewrite every piece of code we have which expects some POSIX file system to store data to use a REST based object store instead (Ceph, or anything, really).
In absence of that, Flocker seems a nice solution to bridge this gap. A volume moves with the container. If a container has a flocker volume, you can stop it on hostA, and do a docker run on hostB, and it automagically mounts the same volume using whatever back end driver you specified (using vSphere for now, as this is all I have conveniently available in my lab setup).
I just still don’t know whether I can trust Flocker with my (paying) customer’s emails
Feature request logged here for dynamic volumes:
https://github.com/rancher/rancher/issues/6303
1 Like
Thanks for the info.
Have you looked at Quobyte? Not quite Flocker - but also interesting with regard to storage for containers.