Support --volumes-from option for docker run

[harto]

Unless I'm mistaken, there doesn't appear to be a way to define --volumes-from via fig.yml.

[aanand]

volumes_from should work:

foo:
  volumes_from: ID_OR_NAME_OF_CONTAINER
  ...

[zbyte64]

Isn't it suppose to be volumes? How are the two different?

http://orchardup.github.io/fig/yml.html
https://github.com/orchardup/fig/blob/master/fig/service.py#L203

[harto]

@zbyte64 from docker help run:

-v, --volume=[]: Bind mount a volume (e.g. from the host: -v /host:/container, from docker: -v /container)
--volumes-from=[]: Mount volumes from the specified container(s)

[harto]

@aanand hmm, you're right, it does seem to work. Perhaps the documentation needs updating.

[zbyte64]

In my experience the docs are correct. The following works:

web:
  build: .
  command: python manage.py runserver 0.0.0.0:8000
  volumes:
    - ./:/opt/app/
  ports:
    - "8000:8000"
  links:
    - db
    - redis
  environment:
    DJANGO_SETTINGS_MODULE: "montage.settings.fig"

What does not work is doing this in OSX as fig doesn't configure shared folders in vagrant.

[harto]

@zbyte64 not sure what you're talking about. I'm referring to volumes_from, not volumes. I don't see any reference to volumes_from in the snippet you posted.

[zbyte64]

@harto You are correct, I confused the two options. The code mentions it:
https://github.com/orchardup/fig/blob/master/fig/service.py#L165

So you're right again when you said the docs need to be updated.

[harto]

@aanand In fact the implementation isn't quite correct. It appears that volumes_from takes a single container name/ID, but docker run --volumes-from allows for multiple containers. So the format should perhaps be something like:

volumes_from:
  - container-1
  - container-2

[pda]

I'm also concerned that recreate_container() seems to overwrite the volumes_from value.

[aanand]

Hmm, yes. Complicated. Will have to think about how the two interact - perhaps if volumes_from is specified in fig.yml, the "intermediate container" step should be skipped.

I'd be interested to know how you're using volumes_from with Fig, @harto / @pda - what problem is it addressing for you?

[pda]

I'd be interested to know how you're using volumes_from with Fig

We use --volumes-from to implement data-only containers, for persisting e.g. MySQL data. This makes the volume docker-managed (lives somewhere in /var/lib/docker), but decoupled from the running container.

For example we'd create a stopped mysql-data container with docker run --name=mysql-data --volume=/var/lib/mysql ubuntu true, and then we'd run actual MySQL server containers with docker run --name=mysql --volumes-from=mysql-data us/our_mysql_image.

We also use this for various cache directories when we want to persist/share them between container runs, but don't want to manage static volume points for each one on the Docker host.

Here's some links that describe the “Data Volume Container” / “Data-Only Containers” pattern:

• Creating and mounting a Data Volume Container (from the official docs)
• Tiny Docker Pieces, Loosely Joined (blog post that got me onto them initially)

[KyleAMathews]

+1 to data-only containers.

Couldn't the code in services.py just overwrite volumes_from if it exists in the fig.yml file?

[pda]

Overwrite? Or temporarily add the previous container to the list? I'm not sure.

[KyleAMathews]

Oh good point... it'd be easy to add the previous container still. Yeah, no reason not to do that. It's a handy feature of Fig during development that you don't have to be too careful where you put data as they'll all come back up the next time you start the container.

[caolan]

Any news on this? I'd also like to make use of fig with data-only containers