Docker 教程

Docker 网络与端口映射

在运行 Docker 容器时，最关键的配置之一就是它如何与外部世界以及其他容器进行通信。

默认情况下，容器运行在一个完全隔离的环境中，就像一台微型电脑。如果容器内部的应用程序需要接收外部请求——例如，Web 服务器需要监听 HTTP 请求，API 需要提供数据，或者数据库需要接受客户端连接——它的端口就必须被显式地“暴露”并映射到宿主机的端口上。

如果没有正确的端口配置，你的容器化应用将处于“失联”状态，用户、其他服务甚至你自己都无法访问它。本章将深入探讨 Docker 管理网络连接的机制，重点讲解在启动容器时如何暴露应用端口以及配置基础的网络行为，确保你的应用能够按照预期被顺利访问。

1. 容器网络基础

要弄懂端口暴露的原理，我们首先需要了解 Docker 使用的基础网络模型。

1.1 为什么需要网络连接？

想象一下，你的 Docker 容器里跑着一个 Web 服务器。这个应用被设计为在 80 或 443 端口上接收 HTTP 请求。如果没有一种方法能将你宿主机（你的电脑或服务器）的网卡与容器的网卡连接起来，那些外部请求就永远找不到这个 Web 服务器。

同样，如果你有两个容器——一个运行 Web 应用，另一个运行数据库——它们也需要一种相互通信的手段才能正常工作。这就是 Docker 网络大显身手的地方。

1.2 默认网络行为：bridge 网络

当你运行一个容器且没有指定任何网络配置时，Docker 会自动将它连接到一个名为 bridge（桥接） 的默认网络。

这个 bridge 是由 Docker 管理的私有内部网络。连接到这个网络的每个容器都会分配到一个自己的内部 IP 地址。处于同一个 bridge 网络上的容器，可以通过这些内部 IP 进行互相通信，或者更方便地通过它们的容器名称来通信（这得益于 Docker 内置的 DNS 解析功能）。

然而，从你的宿主机或外部网络的视角来看，这些内部 IP 地址是无法直接访问的。

1.3 容器隔离与内部 IP 地址

容器的核心原则之一是隔离。每个容器都有自己独立的文件系统、进程树和网络栈。这意味着，一个在 80 端口运行应用的容器，只在它自己的网络命名空间内打开了 80 端口。这个内部的 80 端口，与你宿主机上可能打开的任何 80 端口毫无关系。

为了让容器的内部端口能够被宿主机或外部网络访问，你需要一种机制来打通这种隔离——这种机制就是端口暴露（Port Exposure）。

2. 将容器端口暴露给宿主机

让宿主机或外部客户端访问容器服务的最主要方法，就是发布（或暴露）它的端口。

2.1 使用 -p 参数：映射端口

在 docker run 命令中，--publish 或 -p 参数用于将容器内的一个或多个端口映射到宿主机上。这相当于创建了一条防火墙规则，将宿主机特定端口上的流量转发到容器内的特定端口。

基础语法： -p 宿主机端口:容器内端口

这是最常见也最直观的写法：

  • 宿主机端口 (host_port): 你的 Docker 宿主机上的端口号。外部客户端将通过这个端口发起连接。
  • 容器内端口 (container_port): 容器内部应用程序正在监听的端口号。

示例：暴露一个 Web 服务器

假设你有一个 Nginx 容器，它默认在 80 端口监听 HTTP 请求。你想在宿主机的 8080 端口上访问它：

docker run -d --name my-nginx -p 8080:80 nginx
  • docker run: 运行新容器的命令。
  • -d: 在后台（分离模式）运行容器。
  • --name my-nginx: 给容器命名为 my-nginx。
  • -p 8080:80: 核心配置。将宿主机的 8080 端口映射到容器内的 80 端口。
  • nginx: 使用的 Docker 镜像。

运行后，打开浏览器访问 http://localhost:8080，你就能看到 Nginx 的欢迎页面。所有进入宿主机 8080 端口的流量，都被无缝转发到了 my-nginx 容器的 80 端口。

2.2 指定宿主机 IP 地址映射

在更高级的场景中，你可能希望将端口映射限制在宿主机特定的网卡或 IP 地址上。如果你的宿主机有多个 IP，这可以确保服务只在特定的网络接口上对外暴露。

进阶语法： -p 宿主机IP:宿主机端口:容器内端口

示例：绑定到特定的宿主机 IP

假设你的宿主机有两个 IP：192.168.1.100 和 10.0.0.5。你只希望 Nginx 通过 192.168.1.100 的 8080 端口被访问：

docker run -d --name my-nginx-specific-ip -p 192.168.1.100:8080:80 nginx

现在，Nginx 只能通过 http://192.168.1.100:8080 访问，其他 IP 地址的 8080 端口将无法访问该容器。

2.3 映射多个端口

一个容器可能会运行多个服务，每个服务监听不同的端口。你可以多次使用 -p 参数来映射不同的端口对。

示例：带有 SSH 访问的 Web 服务器（假设场景）

虽然在生产环境中不建议这么做，但在开发时，你可能需要同时访问 Web 服务（80 端口）和 SSH 调试服务（22 端口）：

docker run -d --name dev-server -p 8080:80 -p 2222:22 my/dev-image

在这里，宿主机的 8080 映射到了容器的 80，宿主机的 2222 映射到了容器的 22。

2.4 选择可用的宿主机端口

在选择宿主机端口时，你必须确保该端口没有被宿主机上的其他程序占用。如果发生冲突，Docker 会报错。通常，开发或自定义应用习惯使用高端口号（如 3000, 8080, 5000），以避免与系统知名端口（如 80, 22, 443）发生冲突。

3. 自动端口发布与 EXPOSE 指令

除了显式地一对一映射端口，Docker 还提供了一种自动分配端口的机制。

3.1 使用 -P (大写) 参数：自动发布

你可以使用 --publish-all 或大写的 -P 参数。这个参数会自动将 Dockerfile 中通过 EXPOSE 显式声明的所有端口，随机映射到宿主机上的高可用端口。

示例：使用 -P 参数

假设 nginx 的 Dockerfile 中包含了 EXPOSE 80。

docker run -d --name my-nginx-auto -P nginx

运行后，Docker 会随机分配一个宿主机端口（例如 32768）并将其映射到容器的 80 端口。你可以使用 docker ps 命令来查看具体分配了哪个端口：

docker ps

输出可能如下：

CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                     NAMES
a1b2c3d4e5f6   nginx     "/docker-entrypoint.…"   2 minutes ago   Up 2 minutes   0.0.0.0:32768->80/tcp     my-nginx-auto

这里的 0.0.0.0:32768->80/tcp 表示宿主机的 32768 端口成功映射到了容器的 80 端口。

3.2 Dockerfile 中的 EXPOSE 指令

EXPOSE 指令在 Dockerfile 中主要起到声明和文档的作用。它告诉 Docker 和用户，这个容器内的应用“打算”监听哪些端口。

注意： EXPOSE 本身并不会在宿主机上实际打开或映射这些端口。它只是一种声明，并配合 -P 参数发挥作用。
# Dockerfile 内部示例
FROM ubuntu
RUN apt-get update && apt-get install -y nginx
EXPOSE 80 443 # 声明此镜像中的服务将监听 80 和 443 端口
CMD ["nginx", "-g", "daemon off;"]

在这个例子中，如果用户运行 docker run -P my-nginx-image，80 和 443 端口都会被自动映射。如果用户运行 docker run -p 8080:80 my-nginx-image，则只有 80 端口被映射，443 端口将保持内部私有。

3.3 什么时候用 -p，什么时候用 -P？

  • 使用 -p 进行精准控制： 生产环境中首选。它让你精确控制使用哪些宿主机端口，确保访问地址固定且可预测。
  • 使用 -P 快速测试： 当你在开发环境中快速启动容器，且不在乎具体使用哪个宿主机端口时，-P 非常方便。

4. 探索其他网络模式：Host 模式

虽然默认的 bridge 网络和显式端口映射最常用，但 Docker 也为特定场景提供了其他网络模式，最著名的就是 host 网络模式。

4.1 Host 网络模式 (--network host)

当你使用 --network host 运行容器时，容器将直接共享宿主机的网络栈。

在 host 模式下，容器不再拥有自己隔离的网络命名空间、IP 地址或端口空间。相反，它直接使用宿主机的网卡和 IP 地址。如果容器内的应用监听了 80 端口，它实际上是在直接监听宿主机的 80 端口。

核心影响：

  • 无需端口映射： 因为网络是共享的，所以不需要使用 -p 或 -P。容器的端口直接暴露在宿主机上。
  • 失去网络隔离： 容器与宿主机之间的网络隔离被打破。如果不谨慎管理，容器将拥有宿主机网络的最高权限，存在一定安全隐患。
  • 潜在的端口冲突： 如果容器尝试绑定的端口已经被宿主机上的其他程序占用，容器将无法启动或应用会崩溃。

4.2 Host 模式的应用场景

host 模式通常用于网络性能要求极高的场景，或者容器需要绕过 NAT（网络地址转换）层直接访问宿主机网络服务的情况。

  • 高性能反向代理 / 网络监控： 需要嗅探宿主机所有网络流量的监控工具（如入侵检测系统 NIDS），使用 host 模式可以避免 bridge 带来的性能损耗。
  • 运行自定义 DNS 服务器： DNS 必须在标准的 53 端口上直接响应。使用 host 模式可以简化配置，尽管这牺牲了隔离性。
docker run -d --name my-dns-server --network host my/dns-image

5. 默认 Bridge 网络上的容器互联

端口映射解决了“外部如何访问内部”的问题，但在实际开发中，容器们往往还需要相互通信。当容器都在默认的 bridge 网络上时，Docker 为它们提供了互联机制。

5.1 通过容器名称通信

Docker 默认的 bridge 网络内置了 DNS 服务。同一网络上的容器可以通过容器名称互相解析 IP 地址。这意味着你不需要在代码里写死那些随时会变的内部 IP。

实战场景：Web 应用连接数据库

1. 首先，运行一个 PostgreSQL 数据库容器：

docker run -d --name my-postgres -e POSTGRES_PASSWORD=mysecretpassword postgres

注意：我们没有用 -p，所以它的默认端口 5432 没有对宿主机暴露。

2. 然后，运行一个需要连接数据库的 Web 应用容器：

docker run -d --name my-webapp --link my-postgres:db -p 8000:80 my/webapp-image
注意：--link 是一个用于容器互联的传统参数。在现代 Docker 部署中，我们更推荐使用自定义网络（模块 4 讲解）或 Docker Compose（模块 5 讲解）。但在这里，它很好地演示了“通过名称连接另一个容器”的概念。

在这个例子中，Web 应用可以使用别名 db 或原名 my-postgres 作为主机名来连接数据库。例如，连接字符串可以写成 db:5432。数据库端口无需对外暴露，Web 应用依然可以顺畅访问它。

5.2 内部服务不需要端口映射

最佳实践：只暴露那些真正需要外部访问的端口。

如果一个服务只被环境内的其他容器使用（如 Redis 缓存），就绝对不要把它映射到宿主机上。这能大幅减少被攻击的风险。

docker run -d --name my-redis redis

上面的 Redis 容器只允许同一 bridge 上的 Web 容器访问，对宿主机及外部网络完全隐身，安全性拉满。

6. 端口暴露与网络实战演示

让我们通过几个实战 Demo 来巩固刚刚学到的知识。

Demo 1：部署基础的 Nginx Web 服务器

将 Nginx 容器运行起来，并让宿主机可以访问它。

1. 运行并映射端口：

docker run -d --name my-webserver -p 8080:80 nginx

2. 验证端口映射：

docker ps

在 PORTS 一列中，你会看到 0.0.0.0:8080->80/tcp。

3. 访问服务： 打开浏览器访问 http://localhost:8080，查看 Nginx 页面。

4. 清理环境：

docker stop my-webserver
docker rm my-webserver

Demo 2：运行一个简单的 Python Flask API

这个演示将使用自定义代码来展示如何暴露非标准端口。

1. 创建 Flask 应用代码 (app.py)：

# app.py
from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello from Dockerized Flask API!'

if __name__ == '__main__':
    # Flask 默认运行在 5000 端口
    # host='0.0.0.0' 在容器内部至关重要。它告诉 Flask 监听所有可用的网络接口，
    # 从而让应用可以从容器外部被访问到。
    app.run(host='0.0.0.0', port=5000)

2. 创建对应的 Dockerfile：

# Dockerfile
FROM python:3.9-slim-buster
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .
EXPOSE 5000 # 声明该应用使用 5000 端口
CMD ["python", "app.py"]

3. 创建依赖文件 (requirements.txt)：

Flask

3. 构建并运行：

docker build -t my-flask-app .
docker run -d --name flask-api -p 5000:5000 my-flask-app

4. 验证访问： 访问 http://localhost:5000 或使用 curl http://localhost:5000，你应该能看到 "Hello from Dockerized Flask API!"。

5. 清理环境：docker stop flask-api 及 docker rm flask-api。

Demo 3：内部数据库连接（不暴露外部端口）

展示如何在不暴露端口的情况下，让一个容器连接到数据库容器。

1. 运行纯内部的 PostgreSQL：

docker run -d --name my-internal-db -e POSTGRES_PASSWORD=dbpassword postgres

(注意：没有使用 -p 参数）

2. 运行客户端容器去连接它：

docker run --rm --link my-internal-db:db-alias postgres psql -h db-alias -U postgres -c "SELECT 1;"
  • --rm: 运行完毕后自动删除客户端容器。
  • --link: 将目标数据库链接过来，并赋予别名 db-alias。
  • psql -h db-alias ...: 在客户端内部执行连接命令，主机名直接使用别名 db-alias。

如果连接成功，终端将打印出一个查询结果 1。如果你尝试直接在宿主机上通过 5432 端口连接，将会提示连接被拒绝。