如何在容器内修改DNS服务器地址？

在现代软件开发和运维实践中,容器化技术已经成为不可或缺的一部分，Docker作为最流行的容器引擎，为我们提供了轻量、隔离且可移植的运行环境，网络的复杂性并不会因为容器的出现而消失，DNS（域名系统）的配置就是一个常见且关键的问题，正确地为容器配置DNS，是确保容器能够顺利访问外部服务、内部微服务以及特定网络资源的基础，本文将深入探讨在Docker环境中修改DNS设置的多种方法、其背后的原理以及最佳实践。

为什么需要修改容器的DNS？

默认情况下,Docker容器会继承宿主机的DNS配置，但这在很多场景下并不能满足需求，以下是一些典型的需要手动修改容器DNS的场景：

• 访问内部服务：在企业内网环境中，许多服务通过内部域名（如 service.internal.company）进行访问，这些域名由内部的DNS服务器解析，公共DNS（如8.8.8.8）无法解析。
• 绕过DNS污染或限制：在某些网络环境下，公共DNS可能被污染或存在访问限制，导致特定域名无法正确解析，使用可靠的第三方DNS服务器（如 1.1.1 或 8.8.8）可以解决这个问题。
• 提高解析速度与安全性：一些DNS服务（如Cloudflare的 1.1.1）承诺更快的解析速度和更好的隐私保护，适合对性能和安全有要求的应用。
• 开发与测试：在开发环境中，可能需要将域名指向特定的测试服务器IP，通过修改容器DNS可以方便地实现流量切换，而无需修改代码或hosts文件。

修改容器DNS的几种方法

Docker提供了灵活的DNS配置选项,可以从不同维度进行设置，以满足从单个临时容器到整个集群的多样化需求。

在容器运行时指定（docker run）

这是最直接、最常用的方法，适用于为单个容器指定DNS服务器，通过 --dns 标志，可以在启动容器时传入一个或多个DNS服务器的IP地址。

基本语法：

docker run --dns=<DNS_SERVER_IP> [其他选项] <镜像名>

示例：
假设我们希望一个Nginx容器使用谷歌的公共DNS（8.8.8.8）和国内的一个公共DNS（114.114.114.114）：

docker run -d --name my-nginx --dns=8.8.8.8 --dns=114.114.114.114 -p 80:80 nginx

执行后,进入容器内部查看 /etc/resolv.conf 文件，其内容将如下所示：

nameserver 8.8.8.8
nameserver 114.114.114.114
search localdomain

还可以使用 --dns-search 设置DNS的搜索域，以及 --dns-opt 设置DNS解析选项，如超时时间等。

配置Docker守护进程（daemon.json）

如果希望宿主机上启动的所有容器都默认使用特定的DNS配置,而不是继承宿主机的设置，那么修改Docker守护进程的配置文件是最佳选择。

这个配置文件通常位于 /etc/docker/daemon.json（Linux）或 %programdata%dockerconfigdaemon.json（Windows），如果文件不存在，可以手动创建。

配置示例：

{
  "dns": ["8.8.8.8", "1.1.1.1"],
  "dns-search": ["mycorp.com"],
  "dns-opts": ["timeout:3", "attempts:2"]
}

应用步骤：

1. 编辑或创建 daemon.json 文件，添加上述配置。
2. 保存文件。
3. 重启Docker服务以使配置生效。

   sudo systemctl restart docker

配置完成后,所有新创建的容器将默认使用这里指定的DNS服务器，需要注意的是，通过 docker run 命令的 --dns 标志指定的DNS会覆盖此全局配置。

使用Docker Compose

在使用Docker Compose进行多容器应用编排时，可以在 docker-compose.yml 文件中为每个服务单独定义DNS设置，这对于需要不同网络策略的微服务架构尤其有用。

docker-compose.yml 示例：

version: '3.8'
services:
  web_app:
    image: my-web-app:latest
    ports:
      - "8080:80"
    dns:
      - 8.8.8.8
      - 192.168.1.100  # 内部DNS服务器
  database:
    image: postgres:13
    environment:
      - POSTGRES_PASSWORD=mysecretpassword
    dns:
      - 192.168.1.100 # 数据库服务只使用内部DNS

在这个例子中,web_app 服务可以同时访问公共和内部网络，而 database 服务则被限制只能通过内部DNS进行解析，增强了安全性。

手动进入容器修改（不推荐）

这是一种临时的、用于调试的方法，强烈不推荐在生产环境中使用，因为容器的设计理念是“不可变”，直接修改其内部文件会破坏这种原则，且容器一旦重启，所有修改都会丢失。

操作步骤：

1. 获取容器的ID或名称。
2. 进入容器的shell环境：

   docker exec -it <container_id_or_name> /bin/bash

3. 使用 vi 或 nano 等编辑器修改 /etc/resolv.conf 文件。

这种方法仅适用于快速验证某个DNS配置是否生效,验证完毕后应立即通过正确的方式重新创建容器。

方法对比与最佳实践

为了更清晰地选择合适的方法,下表对上述四种方式进行了对比：

最佳实践小编总结：

• 优先使用声明式配置：尽可能通过 docker-compose.yml 或 daemon.json 来管理DNS，这样配置是可重复、可追溯的。
• 明确配置层级：遵循 docker run > docker-compose.yml > daemon.json 的优先级，即，运行时指定的参数会覆盖编排文件和守护进程的配置。
• 避免手动修改：将手动修改视为最后的调试手段，而非常规操作方案。
• 安全性考虑：对于处理敏感数据的服务，限制其DNS解析能力，仅允许其访问必要的内部DNS服务器，可以降低信息泄露的风险。

相关问答FAQs

问题1：我修改了容器的DNS配置，但容器内部的应用仍然解析到旧的IP地址，这是为什么？

解答： 这种情况通常是由DNS缓存导致的，DNS解析结果可能在多个层面被缓存：

1. 应用层缓存：您容器中运行的应用程序（如Java应用、浏览器）自身可能实现了DNS缓存机制。
2. 操作系统层缓存：部分Linux发行版的glibc库或nscd（Name Service Cache Daemon）服务会缓存DNS查询结果。
3. 网络设备缓存：您网络中的路由器或防火墙也可能存在DNS缓存。

解决方法：

• 重启容器：这是最简单粗暴且最有效的方法，可以清空容器内部所有层级的缓存。
• 重启应用服务：如果重启容器成本较高，可以尝试只重启容器内的应用进程。
• 清空特定缓存：如果知道是哪种缓存导致的，可以尝试清空它，在容器内执行 systemctl restart nscd（如果安装了nscd）。
• 等待TTL过期：DNS记录都有一个TTL（Time To Live）值，缓存会在该时间后自动失效。

问题2：Docker容器和宿主机是完全共享DNS设置的吗？

解答： 不是完全共享，但默认情况下相关联，默认情况下，Docker守护进程在创建容器时，会读取宿主机的 /etc/resolv.conf 文件，并将其内容“复制”一份，稍作修改（例如移除localhost相关的配置）后，用作容器的 /etc/resolv.conf 文件。

这意味着,容器启动时的DNS配置是继承自宿主机，但并非实时共享，在容器运行期间，如果您修改了宿主机的DNS设置，已运行的容器的DNS配置不会自动更新，只有当您通过 daemon.json 进行全局配置或使用 --dns 标志时，Docker才会完全忽略宿主机的配置，转而使用您明确指定的DNS服务器，它们的关系是“启动时继承，运行时隔离”。