Bind Host Volume to Container on .run()

[sreuter]

I can't figure out how to bind a host volume into a container. According to the Remote API documentation this can be specified by setting 'Binds' like this...

docker.run('image', ['ls', '-al', '/tmp/'], null, {Binds: ["/tmp:/tmp:rw"]}, cb)

Unfortunately, this doesn't seem to work. (shows contents of original container /tmp)

Can somebody point me into the right direction here? I wonder if this is a bug in the Remote API...

Btw, it works perfectly fine using the docker cli tool!

[sreuter]

I just digged a little bit deeper here. Turns out the problem is originates at the .run() implementation of dockerode, as the optional options object is passed to the container creation, but not to the actual container start call.

@apocas: Any proposal on how to allow users setting options for both calls? As .run() is some kind of helper function (and not a direct endpoint in docker's REST API), why don't map given options accordingly like:

.run() with...

options = {
  'Binds': ['/hostdir:/containerdir:rw']
}

results in

create_options = {
  'Volumes': {
    '/containerdir': {}
  }
}

start_options = {
  'Binds': ['/hostdir:/containerdir:rw']
}

[apocas]

Interesting how "run" functionality keeps growing :)

Hummm, I see two options:

• Expose another argument for the start options. (not pretty, verbose)
• Automagically map options like you said. (possibly high maintenance)

Exposing another argument is indeed a bit ugly and verbose, but it gives a lot of freedom.
What do you think?

[sreuter]

How about something in between...

options = {
  'Binds': ['/hostdir:/containerdir:rw'], // will be translated into necessary start & creation options
  'start_options': {
    .. // extends start options object
  },
  'create_options': {
    .. // extends create options object
  },
}

This gives us the possibility to implement high-level (helper) functions, while providing freedom on setting create & start options "manually".

I know this may result in a breaking change though, but think it may be worth it.

[sreuter]

@apocas Any further thoughts on this one? :-)

[apocas]

Yeah, I like that one :)

But we should throw an error if there's an option that can't be translated.
Basically I want to avoid people using some new option in a Remote API future version and it being silently ignored. If we throw an error saying something like: "I don't know what to do with XPTO option, try using start_options or create_options instead." should avoid this and give an alternate route.

Want to throw a PR for this? :)

[apocas]

Let's go @srijs way for now, I think is solves this use case pretty well.

Will deprecate the current "options" parameter, since it doesn't give complete functionality. (it's needed for container creation)

[sreuter]

Works like a charm guys!

Btw, did I mention @srijs is sitting right next to me? ;-)

[apocas]

Ahah, No :-P

And I was worried about hurting your feelings for choosing one of the solutions lol