Bind Host Volume to Container on .run() about dockerode HOT 8 CLOSED

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']
}

from dockerode.

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?

from dockerode.

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.

from dockerode.

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

from dockerode.

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? :)

from dockerode.

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)

from dockerode.

Works like a charm guys!

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

from dockerode.

Ahah, No :-P

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

from dockerode.