mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabriel Monroy (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MESOS-1593) Add DockerInfo Configuration
Date Sun, 20 Jul 2014 17:32:38 GMT

    [ https://issues.apache.org/jira/browse/MESOS-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14067989#comment-14067989
] 

Gabriel Monroy commented on MESOS-1593:
---------------------------------------

Thanks [~tnachen] for writing this up!

>From my perspective, the minimal set of DockerInfo options may prove problematic for many
intermediate-to-advanced Docker users.  In our case, we require the ability to provide container
names (—-name) and exposed ports (-p/-P).  We also require container auto-removal (—-rm)
which is a common pattern with foreground execution.

bq. One alternative to support all optional fields is to allow a repeated generic key value
pair to be passed as part of DockerInfo. However, it becomes harder to limit options and as
Docker feature set grows Mesos will also likely to require work to support these options.
Therefore, we’re proposing to have more explicitness in the options we support to make sure
the options we support are working in Mesos.

I understand the desire to be explicit as to supported fields.  That said, I think exposing
an optional list of Docker args will prove more flexible in the near-term as we hone the implementation.
 As these optional Docker args are tested and deemed important enough, they could be moved
into the DockerInfo message.

bq. I’d love to get some feedback from folks about how we might capture multiple Docker
containers for the same task or executor. For example, we could easily make a task or executor
be represented by a 'repeated DockerInfo' field, with the contract being that each of the
Docker containers represented by each DockerInfo will be started, killed, and cleaned up as
a single "atomic" unit for that task/executor! (We should also consider the semantics if just
one of those Docker containers exits, i.e., restart it? kill everything? etc.)

This concept of co-located containers (aka “pods”) is a critical feature for us.  We use
it to perform health checks, publish containers to service discovery, provide out-of-band
log aggregation and install ambassador/proxy containers.

Two additional things to consider:

# Many of use-cases for co-located containers require access to the host’s Docker engine
via a bind-mounted docker socket (-v /var/run/docker.sock:/var/run/docker.sock) and/or privileged
host access (—-privileged).
# Some Docker applications require `-e` values that include host information that can only
be gathered at runtime.  For example, Raft-based applications like etcd require the slave’s
hostname/IP for peering.  I’m curious how we get around these late-binding problems.  In
the past I’ve used shell interpolation, though that’s an ugly hack.

bq. For example, we could easily make a task or executor be represented by a 'repeated DockerInfo'
field, with the contract being that each of the Docker containers represented by each DockerInfo
will be started, killed, and cleaned up as a single "atomic" unit for that task/executor!

+1 for this.

Question: Would the repeated DockerInfo field imply ordering?  While our co-located containers
do not have ordering requirements, I could envision cases where that is important.

bq. Does Docker Linking work as-is with Mesos?

If containers are co-located on the same host, Docker links should work out of the box.

bq. Might want to consider launching Ambassador Docker automatically for linking dockers cross
hosts.

I’d recommend against tackling this yet as a) ambassador patterns are still evolving rapidly
and b) there is a good chance this will be addressed in Docker core.

> Add DockerInfo Configuration
> ----------------------------
>
>                 Key: MESOS-1593
>                 URL: https://issues.apache.org/jira/browse/MESOS-1593
>             Project: Mesos
>          Issue Type: Task
>            Reporter: Timothy Chen
>            Assignee: Timothy Chen
>
> We want to add a new proto message to encapsulate all Docker related configurations into
DockerInfo.
> Here is the document that describes the design for DockerInfo:
> https://github.com/tnachen/mesos/wiki/DockerInfo-design



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message