[
https://issues.apache.org/jira/browse/MESOS-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039899#comment-14039899
]
Tom Arnfeld commented on MESOS-1524:
------------------------------------
I agree a first step of using the docker CLI would be great, and as
you/[~tknaup] pointed out a lot of the thinking and work has been done to get
that up and running; If anyone is interested, these are probably the most
prominent that I ran into (and i'm sure [~solidsnack] did too).
- Mounting the sandbox directory can be problematic if the path contains a
colon, due to docker's CLI parser.
- The container has to share the hosts network, even though port forwarding
exists. This is because (not sure if libprocess would do the same) the executor
will pick up the IP of the host->container bridge which isn't accessible
externally.
- Docker itself doesn't support reading any metrics from their API (so you have
to go behind docker straight to the cgroup fs)
- Docker itself doesn't support any way to modify the limits or ports of a
running (or stopped) container. The former can be done via the cgroup fs (much
the same as the existing cgroup containerizer) and i'm not familiar with a
method for the latter.
- Docker doesn't actually pull an image if it exists in it's local cache. This
is problematic because if you update a tag on a docker registry (e.g a private
one) a slave that has previously launched an executor with that image won't
download the new one... so you can get various inconsistencies. The only way
around this currently is to {{pull}} first.
(Hopefully that might come in handy for whoever implements the C++
containerizer).
The docker guys seem to be pretty good at keeping the docker CLI API consistent
and backwards compatible, and i'm sure that'll be even better now they've hit
1.0. Though users will just be installing the latest version, so it'd be great
to try and keep the latest version of mesos in working order with the latest
version of docker.
[~benjaminhindman] – I'm a little concerned about that approach, a couple of
reasons off the top of my head...
- I've always been a huge fan of how the External Containerizer was implemented
and I feel like we'd be going backwards to try and squeeze in some kind of "run
in docker" option
- A first iteration that only supported a concept that's parallel to the
executor wouldn't work too well
- First of all, the "task"/"executor" split is something everyone i've
spoken to about Mesos has been impressed with, and it opens up some very
intriguing patterns for distribution
- Most frameworks seem to use a custom executor, even if it wouldn't be
*strictly* required because they're not launching Mesos Tasks. Namely _Hadoop
on Mesos_, _Jenkins on Mesos_ and _Spark on Mesos_ (in coarse mode).
I'm assuming by your comment that since this is something that sits parallel to
the executor, meaning you can't run executors?
Thanks for creating a new issues, [~jaybuff]!
> 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)
