[
https://issues.apache.org/jira/browse/MESOS-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039893#comment-14039893
]
Benjamin Hindman commented on MESOS-1524:
-----------------------------------------
So great to see everyone's comments!
IMHO what has been tough about implementing a Docker containerizer in the past
has been making it "general purpose" enough to support the primitives that
Mesos provides (namely running executors, lots of details here I'm just
skipping over). In fact, I think the desire to use a Docker containerizer as a
general purpose containerizer just conflates the solution.
So here's what I'd like to propose:
(1) Make Docker be an alternative "execution option" for running a task (and
eventually an executor). What does this mean? Well, today, when you tell Mesos
to run a task you either (a) tell it to run the task via an executor (by
specifying the ExecutorInfo in the TaskInfo) or (b) tell it to run a task via a
shell (by specifying the CommandInfo in the TaskInfo). So let's add: (c) tell
it to run a task via Docker (by specifying a DockerInfo in the TaskInfo).
This model, IMHO, is much easier to reason about, much simpler to implement,
and captures what Docker users really want (i.e., run this Docker container).
For the standard shell command execution option we don't need to bother to use
Docker but can continue to use the built in MesosContainerization. Why continue
to use that stuff? The biggest reason is that it has a pluggable architecture
that some companies use to perform organization specific isolation (for
particular resources).
(2) For the short-term, I think we should build a C++ DockerContainerizer that
does "1. shelling out to docker cli". I think this will be easiest to
accomplish (since it shares the most "code" with Deimos and [~tarnfeld]'s
solution). There is nothing that will preclude us from iterating on this in the
future to do "2. using the docker REST api" instead. In fact, longer-term as we
start to use libcontainer we can also do an iteration that provides direct
support for Docker images in the MesosContainerizer too (but let's not go there
now, let's keep the interface as "Docker is an execution option for tasks" and
let the implementation evolve as necessary).
As [~tarnfeld] and [~jaybuff] already pointed out this strategy will need a way
to compose multiple containerizers and multiplex between them. Great to see
MESOS-1527 opened up, we'll talk about that in more detail there.
[~tarnfeld] also aptly pointed out that another reason for doing the external
containerizer was "ease of use for developers and users to get involved" and
I'm proposing here that we build a C++ DockerContainerizer. I'd like to
separate that concern from making Docker support be first-class for now. We're
still moving forward with our module system where I hope to see embeddable
Python, Go, and Lua implementations of components. As that evolves we can
consider an iteration/rewrite of the DockerContainerizer (in another language),
but IMHO right now I think we should focus on shipping a default implementation
for the Docker execution option within Mesos without requiring much (any?)
user/operator involvement.
One more thing: what about ContainerInfo in CommandInfo? Let's revisit that
later as more of the containerization landscape comes into view (especially
w.r.t. libcontainer). Yes, it would be awesome to expose even more "general
purpose" containerization primitives but I don't think we need to focus on that
right now.
Thoughts? Concerns? Suggestions?
> 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)
