Use "docker start" rather than "docker run"?

[Paul Bell <ar...@gmail.com>]

Hi All,

I first posted this to the Marathon list, but someone suggested I try it
here.

I'm still not sure what component (mesos-master, mesos-slave, marathon)
generates the "docker run" command that launches containers on a slave
node. I suppose that it's the framework executor (Marathon) on the slave
that actually executes the "docker run", but I'm not sure.

What I'm really after is whether or not we can cause the use of "docker
start" rather than "docker run".

At issue here is some persistent data inside
/var/lib/docker/aufs/mnt/<CTR_ID>. "docker run" will by design (re)launch
my application with a different CTR_ID effectively rendering that data
inaccessible. But "docker start" will restart the container and its "old"
data will still be there.

Thanks.

-Paul

Re: Use "docker start" rather than "docker run"?

[Alex Rukletsov <al...@mesosphere.com>]

Heh, that's a tricky one : ). A framework indeed consists of a scheduler
and an executor, both are mandatory. But Mesos provides a default
general-purpose executor, which can be used by frameworks. This executor
has many names, two most common are "MesosExecutor" and "CommandExecutor".
Marathon doesn't have its own executor (in contrast to, say, Aurora) yet,
it uses CommandExecutor for all of its tasks.

CommandExecutor is implicitly created by Mesos if a task specification do
not include executor. This executor can have just a single task and is
garbage collected after the task finishes. A task is any command, which
will be executed via '/bin/sh -c <command>'.


On Fri, Aug 28, 2015 at 8:50 PM, Tim Chen <ti...@mesosphere.io> wrote:

> We have primitives for persistent volumes in next release (0.25.0) but
> DockerContainerizer integration will happen most likely the version after.
>
> Tim
>
> On Fri, Aug 28, 2015 at 11:50 AM, Tim Chen <ti...@mesosphere.io> wrote:
>
>> Hi Paul,
>>
>> Alternatively you can try to launch your task on the same host by
>> specifying a constraint with marathon and mount a directory on the host in
>> your container everytime to work-around as well.
>>
>> Tim
>>
>> On Fri, Aug 28, 2015 at 11:44 AM, Paul Bell <ar...@gmail.com> wrote:
>>
>>> Alex & Tim,
>>>
>>> Thank you both; most helpful.
>>>
>>> Alex, can you dispel my confusion on this point: I keep reading that a
>>> "framework" in Mesos (e.g., Marathon) consists of a scheduler and an
>>> executor. This reference to "executor" made me think that Marathon must
>>> have *some* kind of presence on the slave node. But the more familiar I
>>> become with Mesos the less likely this seems to me. So, what does it mean
>>> to talk about the Marathon framework "executor"?
>>>
>>> Tim, I did come up with a simple work-around that involves re-copying
>>> the needed file into the container each time the application is started.
>>> For reasons unknown, this file is not kept in a location that would readily
>>> lend itself to my use of persistent storage (Docker -v). That said, I am
>>> keenly interested in learning how to write both custom executors &
>>> schedulers. Any sense for what release of Mesos will see "persistent
>>> volumes"?
>>>
>>> Thanks again, gents.
>>>
>>> -Paul
>>>
>>>
>>>
>>> On Fri, Aug 28, 2015 at 2:26 PM, Tim Chen <ti...@mesosphere.io> wrote:
>>>
>>>> Hi Paul,
>>>>
>>>> We don't [re]start a container since we assume once the task terminated
>>>> the container is no longer reused. In Mesos to allow tasks to reuse the
>>>> same executor and handle task logic accordingly people will opt to choose
>>>> the custom executor route.
>>>>
>>>> We're working on a way to keep your sandbox data beyond a container
>>>> lifecycle, which is called persistent volumes. We haven't integrated that
>>>> with Docker containerizer yet, so you'll have to wait to use that feature.
>>>>
>>>> You could also choose to implement a custom executor for now if you
>>>> like.
>>>>
>>>> Tim
>>>>
>>>> On Fri, Aug 28, 2015 at 10:43 AM, Alex Rukletsov <al...@mesosphere.com>
>>>> wrote:
>>>>
>>>>> Paul,
>>>>>
>>>>> that component is called DockerContainerizer and it's part of Mesos
>>>>> Agent (check
>>>>> "/Users/alex/Projects/mesos/src/slave/containerizer/docker.hpp"). @Tim,
>>>>> could you answer the "docker start" vs. "docker run" question?
>>>>>
>>>>> On Fri, Aug 28, 2015 at 1:26 PM, Paul Bell <ar...@gmail.com> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I first posted this to the Marathon list, but someone suggested I try
>>>>>> it here.
>>>>>>
>>>>>> I'm still not sure what component (mesos-master, mesos-slave,
>>>>>> marathon) generates the "docker run" command that launches containers on a
>>>>>> slave node. I suppose that it's the framework executor (Marathon) on the
>>>>>> slave that actually executes the "docker run", but I'm not sure.
>>>>>>
>>>>>> What I'm really after is whether or not we can cause the use of
>>>>>> "docker start" rather than "docker run".
>>>>>>
>>>>>> At issue here is some persistent data inside
>>>>>> /var/lib/docker/aufs/mnt/<CTR_ID>. "docker run" will by design (re)launch
>>>>>> my application with a different CTR_ID effectively rendering that data
>>>>>> inaccessible. But "docker start" will restart the container and its "old"
>>>>>> data will still be there.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> -Paul
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Use "docker start" rather than "docker run"?

[Tim Chen <ti...@mesosphere.io>]

We have primitives for persistent volumes in next release (0.25.0) but
DockerContainerizer integration will happen most likely the version after.

Tim

On Fri, Aug 28, 2015 at 11:50 AM, Tim Chen <ti...@mesosphere.io> wrote:

> Hi Paul,
>
> Alternatively you can try to launch your task on the same host by
> specifying a constraint with marathon and mount a directory on the host in
> your container everytime to work-around as well.
>
> Tim
>
> On Fri, Aug 28, 2015 at 11:44 AM, Paul Bell <ar...@gmail.com> wrote:
>
>> Alex & Tim,
>>
>> Thank you both; most helpful.
>>
>> Alex, can you dispel my confusion on this point: I keep reading that a
>> "framework" in Mesos (e.g., Marathon) consists of a scheduler and an
>> executor. This reference to "executor" made me think that Marathon must
>> have *some* kind of presence on the slave node. But the more familiar I
>> become with Mesos the less likely this seems to me. So, what does it mean
>> to talk about the Marathon framework "executor"?
>>
>> Tim, I did come up with a simple work-around that involves re-copying the
>> needed file into the container each time the application is started. For
>> reasons unknown, this file is not kept in a location that would readily
>> lend itself to my use of persistent storage (Docker -v). That said, I am
>> keenly interested in learning how to write both custom executors &
>> schedulers. Any sense for what release of Mesos will see "persistent
>> volumes"?
>>
>> Thanks again, gents.
>>
>> -Paul
>>
>>
>>
>> On Fri, Aug 28, 2015 at 2:26 PM, Tim Chen <ti...@mesosphere.io> wrote:
>>
>>> Hi Paul,
>>>
>>> We don't [re]start a container since we assume once the task terminated
>>> the container is no longer reused. In Mesos to allow tasks to reuse the
>>> same executor and handle task logic accordingly people will opt to choose
>>> the custom executor route.
>>>
>>> We're working on a way to keep your sandbox data beyond a container
>>> lifecycle, which is called persistent volumes. We haven't integrated that
>>> with Docker containerizer yet, so you'll have to wait to use that feature.
>>>
>>> You could also choose to implement a custom executor for now if you like.
>>>
>>> Tim
>>>
>>> On Fri, Aug 28, 2015 at 10:43 AM, Alex Rukletsov <al...@mesosphere.com>
>>> wrote:
>>>
>>>> Paul,
>>>>
>>>> that component is called DockerContainerizer and it's part of Mesos
>>>> Agent (check
>>>> "/Users/alex/Projects/mesos/src/slave/containerizer/docker.hpp"). @Tim,
>>>> could you answer the "docker start" vs. "docker run" question?
>>>>
>>>> On Fri, Aug 28, 2015 at 1:26 PM, Paul Bell <ar...@gmail.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I first posted this to the Marathon list, but someone suggested I try
>>>>> it here.
>>>>>
>>>>> I'm still not sure what component (mesos-master, mesos-slave,
>>>>> marathon) generates the "docker run" command that launches containers on a
>>>>> slave node. I suppose that it's the framework executor (Marathon) on the
>>>>> slave that actually executes the "docker run", but I'm not sure.
>>>>>
>>>>> What I'm really after is whether or not we can cause the use of
>>>>> "docker start" rather than "docker run".
>>>>>
>>>>> At issue here is some persistent data inside
>>>>> /var/lib/docker/aufs/mnt/<CTR_ID>. "docker run" will by design (re)launch
>>>>> my application with a different CTR_ID effectively rendering that data
>>>>> inaccessible. But "docker start" will restart the container and its "old"
>>>>> data will still be there.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -Paul
>>>>>
>>>>
>>>>
>>>
>>
>

Re: Use "docker start" rather than "docker run"?

[Tim Chen <ti...@mesosphere.io>]

Hi Paul,

Alternatively you can try to launch your task on the same host by
specifying a constraint with marathon and mount a directory on the host in
your container everytime to work-around as well.

Tim

On Fri, Aug 28, 2015 at 11:44 AM, Paul Bell <ar...@gmail.com> wrote:

> Alex & Tim,
>
> Thank you both; most helpful.
>
> Alex, can you dispel my confusion on this point: I keep reading that a
> "framework" in Mesos (e.g., Marathon) consists of a scheduler and an
> executor. This reference to "executor" made me think that Marathon must
> have *some* kind of presence on the slave node. But the more familiar I
> become with Mesos the less likely this seems to me. So, what does it mean
> to talk about the Marathon framework "executor"?
>
> Tim, I did come up with a simple work-around that involves re-copying the
> needed file into the container each time the application is started. For
> reasons unknown, this file is not kept in a location that would readily
> lend itself to my use of persistent storage (Docker -v). That said, I am
> keenly interested in learning how to write both custom executors &
> schedulers. Any sense for what release of Mesos will see "persistent
> volumes"?
>
> Thanks again, gents.
>
> -Paul
>
>
>
> On Fri, Aug 28, 2015 at 2:26 PM, Tim Chen <ti...@mesosphere.io> wrote:
>
>> Hi Paul,
>>
>> We don't [re]start a container since we assume once the task terminated
>> the container is no longer reused. In Mesos to allow tasks to reuse the
>> same executor and handle task logic accordingly people will opt to choose
>> the custom executor route.
>>
>> We're working on a way to keep your sandbox data beyond a container
>> lifecycle, which is called persistent volumes. We haven't integrated that
>> with Docker containerizer yet, so you'll have to wait to use that feature.
>>
>> You could also choose to implement a custom executor for now if you like.
>>
>> Tim
>>
>> On Fri, Aug 28, 2015 at 10:43 AM, Alex Rukletsov <al...@mesosphere.com>
>> wrote:
>>
>>> Paul,
>>>
>>> that component is called DockerContainerizer and it's part of Mesos
>>> Agent (check
>>> "/Users/alex/Projects/mesos/src/slave/containerizer/docker.hpp"). @Tim,
>>> could you answer the "docker start" vs. "docker run" question?
>>>
>>> On Fri, Aug 28, 2015 at 1:26 PM, Paul Bell <ar...@gmail.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I first posted this to the Marathon list, but someone suggested I try
>>>> it here.
>>>>
>>>> I'm still not sure what component (mesos-master, mesos-slave, marathon)
>>>> generates the "docker run" command that launches containers on a slave
>>>> node. I suppose that it's the framework executor (Marathon) on the slave
>>>> that actually executes the "docker run", but I'm not sure.
>>>>
>>>> What I'm really after is whether or not we can cause the use of "docker
>>>> start" rather than "docker run".
>>>>
>>>> At issue here is some persistent data inside
>>>> /var/lib/docker/aufs/mnt/<CTR_ID>. "docker run" will by design (re)launch
>>>> my application with a different CTR_ID effectively rendering that data
>>>> inaccessible. But "docker start" will restart the container and its "old"
>>>> data will still be there.
>>>>
>>>> Thanks.
>>>>
>>>> -Paul
>>>>
>>>
>>>
>>
>

Re: Use "docker start" rather than "docker run"?

[Paul Bell <ar...@gmail.com>]

Alex and Marco,

Thanks very much for your really helpful explanations.

For better or worse, neither cpp nor Python are my things; Java's the go-to
language for me.

Cordially,

Paul

On Sat, Aug 29, 2015 at 5:23 AM, Marco Massenzio <ma...@mesosphere.io>
wrote:

> Hi Paul,
>
> +1 to what Alex/Tim say.
>
> Maybe a (simple) example will help: a very basic "framework" I created
> recently, does away with the "Executor" and only uses the "Scheduler",
> sending a CommandInfo structure to Mesos' Agent node to execute.
>
> See:
> https://github.com/massenz/mongo_fw/blob/develop/src/mongo_scheduler.cpp#L124
>
> If Python is more your thing, there are examples in the Mesos repository,
> or you can take a look at something I started recently to use the new
> (0.24) HTTP API (NOTE - this is still very much still WIP):
> https://github.com/massenz/zk-mesos/blob/develop/notebooks/HTTP%20API%20Tests.ipynb
>
> *Marco Massenzio*
>
> *Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*
>
> On Fri, Aug 28, 2015 at 8:44 AM, Paul Bell <ar...@gmail.com> wrote:
>
>> Alex & Tim,
>>
>> Thank you both; most helpful.
>>
>> Alex, can you dispel my confusion on this point: I keep reading that a
>> "framework" in Mesos (e.g., Marathon) consists of a scheduler and an
>> executor. This reference to "executor" made me think that Marathon must
>> have *some* kind of presence on the slave node. But the more familiar I
>> become with Mesos the less likely this seems to me. So, what does it mean
>> to talk about the Marathon framework "executor"?
>>
>> Tim, I did come up with a simple work-around that involves re-copying the
>> needed file into the container each time the application is started. For
>> reasons unknown, this file is not kept in a location that would readily
>> lend itself to my use of persistent storage (Docker -v). That said, I am
>> keenly interested in learning how to write both custom executors &
>> schedulers. Any sense for what release of Mesos will see "persistent
>> volumes"?
>>
>> Thanks again, gents.
>>
>> -Paul
>>
>>
>>
>> On Fri, Aug 28, 2015 at 2:26 PM, Tim Chen <ti...@mesosphere.io> wrote:
>>
>>> Hi Paul,
>>>
>>> We don't [re]start a container since we assume once the task terminated
>>> the container is no longer reused. In Mesos to allow tasks to reuse the
>>> same executor and handle task logic accordingly people will opt to choose
>>> the custom executor route.
>>>
>>> We're working on a way to keep your sandbox data beyond a container
>>> lifecycle, which is called persistent volumes. We haven't integrated that
>>> with Docker containerizer yet, so you'll have to wait to use that feature.
>>>
>>> You could also choose to implement a custom executor for now if you like.
>>>
>>> Tim
>>>
>>> On Fri, Aug 28, 2015 at 10:43 AM, Alex Rukletsov <al...@mesosphere.com>
>>> wrote:
>>>
>>>> Paul,
>>>>
>>>> that component is called DockerContainerizer and it's part of Mesos
>>>> Agent (check
>>>> "/Users/alex/Projects/mesos/src/slave/containerizer/docker.hpp"). @Tim,
>>>> could you answer the "docker start" vs. "docker run" question?
>>>>
>>>> On Fri, Aug 28, 2015 at 1:26 PM, Paul Bell <ar...@gmail.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I first posted this to the Marathon list, but someone suggested I try
>>>>> it here.
>>>>>
>>>>> I'm still not sure what component (mesos-master, mesos-slave,
>>>>> marathon) generates the "docker run" command that launches containers on a
>>>>> slave node. I suppose that it's the framework executor (Marathon) on the
>>>>> slave that actually executes the "docker run", but I'm not sure.
>>>>>
>>>>> What I'm really after is whether or not we can cause the use of
>>>>> "docker start" rather than "docker run".
>>>>>
>>>>> At issue here is some persistent data inside
>>>>> /var/lib/docker/aufs/mnt/<CTR_ID>. "docker run" will by design (re)launch
>>>>> my application with a different CTR_ID effectively rendering that data
>>>>> inaccessible. But "docker start" will restart the container and its "old"
>>>>> data will still be there.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -Paul
>>>>>
>>>>
>>>>
>>>
>>
>

Re: Use "docker start" rather than "docker run"?

[Marco Massenzio <ma...@mesosphere.io>]

Hi Paul,

+1 to what Alex/Tim say.

Maybe a (simple) example will help: a very basic "framework" I created
recently, does away with the "Executor" and only uses the "Scheduler",
sending a CommandInfo structure to Mesos' Agent node to execute.

See:
https://github.com/massenz/mongo_fw/blob/develop/src/mongo_scheduler.cpp#L124

If Python is more your thing, there are examples in the Mesos repository,
or you can take a look at something I started recently to use the new
(0.24) HTTP API (NOTE - this is still very much still WIP):
https://github.com/massenz/zk-mesos/blob/develop/notebooks/HTTP%20API%20Tests.ipynb

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*

On Fri, Aug 28, 2015 at 8:44 AM, Paul Bell <ar...@gmail.com> wrote:

> Alex & Tim,
>
> Thank you both; most helpful.
>
> Alex, can you dispel my confusion on this point: I keep reading that a
> "framework" in Mesos (e.g., Marathon) consists of a scheduler and an
> executor. This reference to "executor" made me think that Marathon must
> have *some* kind of presence on the slave node. But the more familiar I
> become with Mesos the less likely this seems to me. So, what does it mean
> to talk about the Marathon framework "executor"?
>
> Tim, I did come up with a simple work-around that involves re-copying the
> needed file into the container each time the application is started. For
> reasons unknown, this file is not kept in a location that would readily
> lend itself to my use of persistent storage (Docker -v). That said, I am
> keenly interested in learning how to write both custom executors &
> schedulers. Any sense for what release of Mesos will see "persistent
> volumes"?
>
> Thanks again, gents.
>
> -Paul
>
>
>
> On Fri, Aug 28, 2015 at 2:26 PM, Tim Chen <ti...@mesosphere.io> wrote:
>
>> Hi Paul,
>>
>> We don't [re]start a container since we assume once the task terminated
>> the container is no longer reused. In Mesos to allow tasks to reuse the
>> same executor and handle task logic accordingly people will opt to choose
>> the custom executor route.
>>
>> We're working on a way to keep your sandbox data beyond a container
>> lifecycle, which is called persistent volumes. We haven't integrated that
>> with Docker containerizer yet, so you'll have to wait to use that feature.
>>
>> You could also choose to implement a custom executor for now if you like.
>>
>> Tim
>>
>> On Fri, Aug 28, 2015 at 10:43 AM, Alex Rukletsov <al...@mesosphere.com>
>> wrote:
>>
>>> Paul,
>>>
>>> that component is called DockerContainerizer and it's part of Mesos
>>> Agent (check
>>> "/Users/alex/Projects/mesos/src/slave/containerizer/docker.hpp"). @Tim,
>>> could you answer the "docker start" vs. "docker run" question?
>>>
>>> On Fri, Aug 28, 2015 at 1:26 PM, Paul Bell <ar...@gmail.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I first posted this to the Marathon list, but someone suggested I try
>>>> it here.
>>>>
>>>> I'm still not sure what component (mesos-master, mesos-slave, marathon)
>>>> generates the "docker run" command that launches containers on a slave
>>>> node. I suppose that it's the framework executor (Marathon) on the slave
>>>> that actually executes the "docker run", but I'm not sure.
>>>>
>>>> What I'm really after is whether or not we can cause the use of "docker
>>>> start" rather than "docker run".
>>>>
>>>> At issue here is some persistent data inside
>>>> /var/lib/docker/aufs/mnt/<CTR_ID>. "docker run" will by design (re)launch
>>>> my application with a different CTR_ID effectively rendering that data
>>>> inaccessible. But "docker start" will restart the container and its "old"
>>>> data will still be there.
>>>>
>>>> Thanks.
>>>>
>>>> -Paul
>>>>
>>>
>>>
>>
>

Re: Use "docker start" rather than "docker run"?

[Paul Bell <ar...@gmail.com>]

Alex & Tim,

Thank you both; most helpful.

Alex, can you dispel my confusion on this point: I keep reading that a
"framework" in Mesos (e.g., Marathon) consists of a scheduler and an
executor. This reference to "executor" made me think that Marathon must
have *some* kind of presence on the slave node. But the more familiar I
become with Mesos the less likely this seems to me. So, what does it mean
to talk about the Marathon framework "executor"?

Tim, I did come up with a simple work-around that involves re-copying the
needed file into the container each time the application is started. For
reasons unknown, this file is not kept in a location that would readily
lend itself to my use of persistent storage (Docker -v). That said, I am
keenly interested in learning how to write both custom executors &
schedulers. Any sense for what release of Mesos will see "persistent
volumes"?

Thanks again, gents.

-Paul



On Fri, Aug 28, 2015 at 2:26 PM, Tim Chen <ti...@mesosphere.io> wrote:

> Hi Paul,
>
> We don't [re]start a container since we assume once the task terminated
> the container is no longer reused. In Mesos to allow tasks to reuse the
> same executor and handle task logic accordingly people will opt to choose
> the custom executor route.
>
> We're working on a way to keep your sandbox data beyond a container
> lifecycle, which is called persistent volumes. We haven't integrated that
> with Docker containerizer yet, so you'll have to wait to use that feature.
>
> You could also choose to implement a custom executor for now if you like.
>
> Tim
>
> On Fri, Aug 28, 2015 at 10:43 AM, Alex Rukletsov <al...@mesosphere.com>
> wrote:
>
>> Paul,
>>
>> that component is called DockerContainerizer and it's part of Mesos Agent
>> (check "/Users/alex/Projects/mesos/src/slave/containerizer/docker.hpp").
>> @Tim, could you answer the "docker start" vs. "docker run" question?
>>
>> On Fri, Aug 28, 2015 at 1:26 PM, Paul Bell <ar...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I first posted this to the Marathon list, but someone suggested I try it
>>> here.
>>>
>>> I'm still not sure what component (mesos-master, mesos-slave, marathon)
>>> generates the "docker run" command that launches containers on a slave
>>> node. I suppose that it's the framework executor (Marathon) on the slave
>>> that actually executes the "docker run", but I'm not sure.
>>>
>>> What I'm really after is whether or not we can cause the use of "docker
>>> start" rather than "docker run".
>>>
>>> At issue here is some persistent data inside
>>> /var/lib/docker/aufs/mnt/<CTR_ID>. "docker run" will by design (re)launch
>>> my application with a different CTR_ID effectively rendering that data
>>> inaccessible. But "docker start" will restart the container and its "old"
>>> data will still be there.
>>>
>>> Thanks.
>>>
>>> -Paul
>>>
>>
>>
>

Re: Use "docker start" rather than "docker run"?

[Tim Chen <ti...@mesosphere.io>]

Hi Paul,

We don't [re]start a container since we assume once the task terminated the
container is no longer reused. In Mesos to allow tasks to reuse the same
executor and handle task logic accordingly people will opt to choose the
custom executor route.

We're working on a way to keep your sandbox data beyond a container
lifecycle, which is called persistent volumes. We haven't integrated that
with Docker containerizer yet, so you'll have to wait to use that feature.

You could also choose to implement a custom executor for now if you like.

Tim

On Fri, Aug 28, 2015 at 10:43 AM, Alex Rukletsov <al...@mesosphere.com>
wrote:

> Paul,
>
> that component is called DockerContainerizer and it's part of Mesos Agent
> (check "/Users/alex/Projects/mesos/src/slave/containerizer/docker.hpp").
> @Tim, could you answer the "docker start" vs. "docker run" question?
>
> On Fri, Aug 28, 2015 at 1:26 PM, Paul Bell <ar...@gmail.com> wrote:
>
>> Hi All,
>>
>> I first posted this to the Marathon list, but someone suggested I try it
>> here.
>>
>> I'm still not sure what component (mesos-master, mesos-slave, marathon)
>> generates the "docker run" command that launches containers on a slave
>> node. I suppose that it's the framework executor (Marathon) on the slave
>> that actually executes the "docker run", but I'm not sure.
>>
>> What I'm really after is whether or not we can cause the use of "docker
>> start" rather than "docker run".
>>
>> At issue here is some persistent data inside
>> /var/lib/docker/aufs/mnt/<CTR_ID>. "docker run" will by design (re)launch
>> my application with a different CTR_ID effectively rendering that data
>> inaccessible. But "docker start" will restart the container and its "old"
>> data will still be there.
>>
>> Thanks.
>>
>> -Paul
>>
>
>

Re: Use "docker start" rather than "docker run"?

[Alex Rukletsov <al...@mesosphere.com>]

Paul,

that component is called DockerContainerizer and it's part of Mesos Agent
(check "/Users/alex/Projects/mesos/src/slave/containerizer/docker.hpp").
@Tim, could you answer the "docker start" vs. "docker run" question?

On Fri, Aug 28, 2015 at 1:26 PM, Paul Bell <ar...@gmail.com> wrote:

> Hi All,
>
> I first posted this to the Marathon list, but someone suggested I try it
> here.
>
> I'm still not sure what component (mesos-master, mesos-slave, marathon)
> generates the "docker run" command that launches containers on a slave
> node. I suppose that it's the framework executor (Marathon) on the slave
> that actually executes the "docker run", but I'm not sure.
>
> What I'm really after is whether or not we can cause the use of "docker
> start" rather than "docker run".
>
> At issue here is some persistent data inside
> /var/lib/docker/aufs/mnt/<CTR_ID>. "docker run" will by design (re)launch
> my application with a different CTR_ID effectively rendering that data
> inaccessible. But "docker start" will restart the container and its "old"
> data will still be there.
>
> Thanks.
>
> -Paul
>