[
https://issues.apache.org/jira/browse/MESOS-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062590#comment-16062590
]
Qian Zhang edited comment on MESOS-7709 at 6/27/17 2:09 AM:
------------------------------------------------------------
[~avinash.mesos], in the JSON schema that you mentioned in the description of
this ticket, I see we only plan to support {{nameservers}} for CNI network and
Docker network. However [CNI
spec|https://github.com/containernetworking/cni/blob/master/SPEC.md#dns]
supports {{nameservers}}, {{domain}}, {{search}} and {{options}}, and
[Docker|https://docs.docker.com/engine/userguide/networking/default_network/configure-dns/]
supports {{nameservers}}, {{search}} and {{options}} via 3 {{docker run}}'s
options {{\--dns}}, {{\--dns-search}} and {{\--dns-opt}}, e.g.:
{code}
$ docker run --dns=8.8.8.8 --dns=8.8.4.4 --dns-search=xxx.com
--dns-search=yyy.com --dns-opt=timeout:3 --dns-opt=attempts:2 busybox cat
/etc/resolv.conf
search xxx.com yyy.com
nameserver 8.8.8.8
nameserver 8.8.4.4
options timeout:3 attempts:2
{code}
So I think for the JSON scheme of our {{\--dns}} agent flag, we should make it
aligned with CNI spec and Docker, i.e., {{\--dns}} can be used to configure
{{nameservers}}, {{domain}}, {{search}} and {{options}} for a CNI network, and
can be used to configure {{nameservers}}, {{search}} and {{options}} for a
Docker network. So I think we can define {{\--dns}} agent flag in the type of
[DNS|https://github.com/apache/mesos/blob/1.3.0/src/slave/containerizer/mesos/isolators/network/cni/spec.proto#L27:L32]
protobuf message.
And for CNI network, I think the priority of {{\--dns}} should be lower than
DNS info returned by CNI plugin but higher than DNS info in agent host's
{{/etc/resolv.conf}}, i.e., if the CNI plugin returns DNS info, we should use
it for the container, otherwise, use the DNS info specified by {{\--dns}},
otherwise, use agent host's {{/etc/resolv.conf}}.
For Docker CNM network, it seems a bit tricky, I am not sure how we can figure
out whether a CNM plugin sets DNS for the container or not (I even doubt if CNM
plugin will take care of DNS setting for container at all), so my proposal is,
if {{\--dns}} is specified for a Docker network, we should always use it for
the Docker container via {{docker run}}'s options {{\--dns}}, {{\--dns-search}}
and {{\--dns-opt}}, otherwise, do not set any of those 3 {{docker run}}'s
options.
was (Author: qianzhang):
[~avinash.mesos], in the JSON schema that you mentioned in the description of
this ticket, I see we only plan to support {{nameservers}} for CNI network and
Docker network. However [CNI
spec|https://github.com/containernetworking/cni/blob/master/SPEC.md#dns]
supports {{nameservers}}, {{domain}}, {{search}} and {{options}}, and
[Docker|https://docs.docker.com/engine/userguide/networking/default_network/configure-dns/]
supports {{nameservers}}, {{search}} and {{options}} via 3 {{docker run}}'s
options {{\--dns}}, {{\--dns-search}} and {{\--dns-opt}}, e.g.:
{code}
$ docker run --dns=8.8.8.8 --dns=8.8.4.4 --dns-search=xxx.com
--dns-search=yyy.com --dns-opt=timeout:3 --dns-opt=attempts:2 busybox cat
/etc/resolv.conf
search xxx.com yyy.com
nameserver 8.8.8.8
nameserver 8.8.4.4
options timeout:3 attempts:2
{code}
So I think for the JSON scheme of our {{\--dns}} agent flag, we should make it
aligned with CNI spec and Docker, i.e., {{\--dns}} can be used to configure
{{nameservers}}, {{domain}}, {{search}} and {{options}} for a CNI network, and
can be used to configure {{nameservers}}, {{search}} and {{options}} for a
Docker network. So I think we can define {{\--dns}} agent flag in the type of
[DNS|https://github.com/apache/mesos/blob/1.3.0/src/slave/containerizer/mesos/isolators/network/cni/spec.proto#L27:L32]
protobuf message.
And for CNI network, I think the priority of {{\--dns}} should be lower than
DNS info returned by CNI plugin but higher than DNS info in agent host's
{{/etc/resolv.conf}}, i.e., if the CNI plugin returns DNS info, we should use
it for the container, otherwise, use the DNS info specified by {{--dns}},
otherwise, use agent host's {{/etc/resolv.conf}}.
For Docker CNM network, it seems a bit tricky, I am not sure how we can figure
out whether a CNM plugin sets DNS for the container or not (I even doubt if CNM
plugin will take care of DNS setting for container at all), so my proposal is,
if {{\--dns}} is specified for a Docker network, we should always use it for
the Docker container via {{docker run}}'s options {{\--dns}}, {{\--dns-search}}
and {{\--dns-opt}}, otherwise, do not set any of those 3 {{docker run}}'s
options.
> Add --dns flag to the agent.
> ----------------------------
>
> Key: MESOS-7709
> URL: https://issues.apache.org/jira/browse/MESOS-7709
> Project: Mesos
> Issue Type: Task
> Components: containerization
> Reporter: Avinash Sridharan
> Assignee: Avinash Sridharan
>
> Mesos support both CNI (through `network/cni` isolator) and CNM (through
> docker) specification. Both these specifications allow for DNS entries for
> containers to be set on a per-container, and per-network basis.
> Currently, the behavior of the agent is to use the DNS nameservers set in
> /etc/resolv.conf when the CNI or CNM plugin that is used to attached the
> container to the CNI/CNM network doesnt' explicitly set the DNS for the
> container. This is a bit inflexible especially when we have a mix of v4 and
> v6 networks.
> The operator should be able to specify DNS nameservers for the networks he
> installs either the override the ones provided by the plugin or as defaults
> when the plugins are not going to specify DNS name servers.
> In order to achieve the above goal we need to introduce a `\--dns` flag to
> the agent. The `\--dns` flag should support a JSON (or a JSON file) with the
> following schema:
> {code}
> {
> "mesos": {
> [
> {
> "network" : <name of the network>,
> "nameservers": [<list of name servers (upto 3)>]
> }
> ]
> },
> "docker": {
> [
> {
> "network" : <name of the network>,
> "nameservers": [<list of name servers (upto 3)>]
> }
> ]
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
