rancher: Rancher-compose: volumes_from with `:ro` or `:ew` is not supported, but docker 1.9.1 supports it

Trying to compose a stack where the volumes_from option is used. This results in the stack creating hanging, the the service using volumes_from not being defined. This happens when creating a stack from a catalogue template or from explicit YAML.

For example

portus:
  image: sshipway/portus:2.0.3
  tty: true
  stdin_open: true
  volumes:
    - /certs

sslproxy:
  image: nginx:1.9.9
  tty: true
  stdin_open: true
  links:
  - portus:portus
  volumes:
  - /etc/nginx/certs:ro
  volumes_from:
  - portus:ro

This creates a stack stuck in Activating state, with a message

Activating (Bad response statusCode [422]. Status [422 status code 422]. Body: [code=InvalidReference, fieldName=LaunchConfigName] from [https://rancher.container.auckland.ac.nz/v1/projects/1a5/services])

The sslproxy container is not shown in the interface. Removing the volumes_from item from the sslproxy stanza makes the stack start up. The sshipway/portus container exports the /etc/nginx/conf.d volume.

Am I doing something wrong (in which case, Rancher should give a more friendly error message and not get stuck) or has Rancher hit a bug in the parsing of the docker-compose YAML?

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 17

Most upvoted comments

Just for the other people coming by, volumes_from cano not replaced by a setup like this https://github.com/rancher/rancher/issues/3316#issuecomment-284807974 … this would actually make no sense - volumes_from is used when you want to mount all anon-volumes of a container - named volumes could have been mounted directly since the early days.

AFAICs https://docs.docker.com/compose/compose-file/#volumes . docker-compose has removed this functionality entirely, not sure how and why and if there is an alternative. But assume, you have an app container and you have a httpd container. Usually you would define the codebase folder, /var/www, as an anon volume and then mount it in httpd to be to serve static files using the httpd service, while passing all dynamic files like ruby/php/java to an upstream backend on app.

The point in using a anon volume and not a named volume is, that actually you want to be able to redeploy app and change the codebase ( app update ) which would not work, if app would have a named volume. That said, anon volumes are doing exactly that and thats why volumes_from is used here - using named volumes is no option is this case ( as it is very practical in a a lot of other cases ).

For me, that means i cannot use rancher for those stacks - quiet a few - since i cannot see a workaround here.

For the reference the upgrade guides for volumes_from: https://docs.docker.com/compose/compose-file/compose-versioning/#upgrading

Also a big discussion about the missing volumes_from feature https://github.com/docker/compose/issues/4379 and a more down to the bottom thing is https://github.com/docker/compose/issues/4693

That said, v3 is not meant to be the successor to v2, its an alternative. And one of the main reason is the lack of volumes_from - here is even an official statement about that https://github.com/docker/compose/issues/4693#issuecomment-291652194

Bottom line, i would not suggest that rancher should not implement volumes_from do the the deprecation of v3 - since v2 is not deprecated and volumes_from has a unique use cases which you cannot work arround

EugenMayer on Jun 25, 2017

@joshwget @deniseschannon @sshipway our container/service APIs lack support for volume access rights. We are going to add support for it immediately after shipping GA. @deniseschannon we should mention this limitation somewhere in the docs/release notes.

alena1108 on Mar 15, 2016

This is a nice to-have feature, but I don’t think I’m going to get to it for 1.2.0. Can we either reassign or bump out?

cjellick on Oct 4, 2016

Is there any solution or alternative to this problem yet? I’m using a separate app-code sidekick with each php-fpm, nginx, and worker containers(they all need the app code to run). 4 images (appcode, php, nginx, worker), 6 services (3+3). I used to be able to update and push the app image and use rancher to update the sidekicks with their companion to deploy the app. Keeping the code separate from the php, nginx, worker, environments makes docker CI build times and rancher service updates faster. It is a little harder to manage, and i’m considering embedding the code and the environment together, building 3 images with each push to repo and tagging them differently, but i already had a working docker-compose in rancher, and now i have to figure this out again. I’m looking forward to hearing other people solutions to managing app code deployments.

berisberis on Sep 21, 2017