You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Qian Zhang (JIRA)" <ji...@apache.org> on 2017/06/27 00:58:01 UTC
[jira] [Comment Edited] (MESOS-7709) Add --dns flag to the agent.
[ 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 12:57 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.
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)