Scaling Docker containers in Rancher with different but persistent volumes

Question

I'm currently trying to bridge the gap between persistent, but unique volumes while scaling containers with Rancher (alternatively Docker Compose, since this is more of an abstract question).

Take as an example a Minecraft server, I have a Service defined in Rancher/Compose which uses a named volume as its data/world directory (e.g. -v minecraft_data:/data where the Minecraft image loads its world files from this /data directory). The reason I'm using such a named volume, is that I want it to persist between service upgrades (e.g. I'm changing the image version, or want to change some environment variables), which would not be possible with an anonymous volume.

Now when trying to scale up my service, I'm either getting multiple containers accessing the same data (not good for many use cases), or losing the service upgradeability when using anonymous volumes.

Are there any tools, best practices or patterns that might help with this issue?

Answer 1

In current versions of rancher (v1.4 at this time) storage drivers can be plugged in at the environment infrastructure level. This allows you to create volumes that are scoped at the environment, stack, or container.

For your use case, it sounds like per-container scope is what you need. Using rancher-compose you do something like:

version: '2'
services:
  foo:
    image: busybox
    volumes:
    - bar:/var/lib/storage
    command: /bin/sh -c 'while true; do sleep 500; done'
volumes:
  bar:
    per_container: true

Then, rancher-compose up -d will create the stack and service with one container and a unique volume. rancher scale foo=2 will create another container with its own volume, etc. You can also specify volume storage drivers for each volume like rancher-ebs or rancher-nfs with their respective options.

Answer 2

I think what you want is to have difference instances of the entire project. scale implies identical clones, but if they have different data, they are not identical.

Instead of using scale, I would start different instances with different project names: https://docs.docker.com/compose/overview/#multiple-isolated-environments-on-a-single-host