[
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)
