[
https://issues.apache.org/jira/browse/MESOS-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057714#comment-14057714
]
Benjamin Hindman commented on MESOS-1524:
-----------------------------------------
[~tarnfeld]: yes, being able to run an executor with the DockerContainerizer is
absolutely key to making this releasable.
That being said, what we're trying to evaluate is whether or not we want to be
able to "inject" an executor into a Docker container, or whether if an executor
wants to be run via a Docker image then it will just specify that image up
front. I'm trying to be careful with my words here as this is definitely a
semantic difference. Let me try to elaborate by taking the perspective of
someone trying to run Spark on Mesos. There are the cases I've been considering:
(1) You specify a Docker image for the Spark executor where the image includes
Spark "pre-installed". The DockerContainerizer just runs the container to
launch the executor.
(2) You specify a command line and URI for the Spark executor. The
MesosContainerizer creates a container for the executor, downloads the URI, and
runs the command within the container.
(3) You specify a command line and URI for the Spark executor (same as above).
The DockerContainerizer creates a container for the executor _using the default
image_, downloads the URI, and runs the command within the container.
(4) You specify a command line, URI, and _image_ for the Spark executor. The
DockerContainerizer creates a container for the executor _based on the image_,
downloads the URI, and runs the command within the container.
We definitely want to make (1) and (2) work (and [~tnachen] should have (1)
completed soon). But I'm less convinced that we want/need to do (3) or (4). You
can accomplish (3) by creating a new image based on the default image which
includes Spark and then do (1). Likewise, you can accomplish (4) by creating a
new image based on the required image which includes Spark, and then do (1).
Providing support to do (3) and (4) feels like we're providing a way to do
"late-construction" of Docker images. This is actually pretty cool, but I
wonder if we'd be better off being extremely explicit using something like a
Dockerfile to describe the construction of an image than the sort of
implicitness that we're getting from trying to inject things into a Docker
container.
> Implement Docker support in Mesos
> ---------------------------------
>
> Key: MESOS-1524
> URL: https://issues.apache.org/jira/browse/MESOS-1524
> Project: Mesos
> Issue Type: Epic
> Reporter: Tobi Knaup
> Assignee: Benjamin Hindman
>
> There have been two projects to add Docker support to Mesos, first via an
> executor, and more recently via an external containerizer written in Python -
> Deimos: https://github.com/mesosphere/deimos
> We've got a lot of feedback from folks who use Docker and Mesos, and the main
> wish was to make Docker a first class citizen in Mesos instead of a plugin
> that needs to be installed separately. Mesos has been using Linux containers
> for a long time, first via LXC, then via cgroups, and now also via the
> external containerizer. For a long time it wasn't clear what the winning
> technology would be, but with Docker becoming the de-facto standard for
> handling containers I think Mesos should make it a first class citizen and
> part of core.
> Let's use this JIRA to track wishes/feedback on the implementation.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
