企业官网建设流程全解析

刚接触Docker那会儿，我印象最深的一课不是镜像怎么打包，而是容器网络。当时我把一个前端容器和一个后端容器都跑起来了，前端却始终连不上后端接口，查了半天才知道默认的bridge网络里，容器之间的访问根本不能靠"localhost"，得靠服务名或者容器IP。从那以后我才意识到：Docker的镜像、容器只是冰山一角，真正坑人的往往是网络、数据卷、编排这些看不见的部分。

这篇文章把我自己反复梳理过的Docker知识体系整理成一份偏实战的笔记，覆盖网络名称空间、veth、网桥、Docker的几种网络模式，以及Dockerfile构建镜像和Docker Compose编排服务。适合正在学Docker、被容器网络绕晕、或者想系统把这块补齐的开发者。文章不追求面面俱到，只求把原理讲透、把坑点说清，你读完可以直接拿这套思路去排查实际环境。

1. 先从一张"虚拟拓扑图"开始：命名空间、veth和网桥到底在干什么

1.1 网络命名空间：每个容器都是一间独立房间

网络命名空间（Network Namespace）是Linux内核提供的一种隔离机制，它把网络协议栈的所有资源——网卡、路由表、防火墙规则、socket等——都封装在一个独立空间里。你可以把它想象成一套独立的网络设备：有自己的网口、自己的路由表、自己的iptables规则。不同命名空间之间默认完全隔离，互不可见，就像两个房间里各装了一部电话，但中间没有拉线，谁也拨不通谁。

Docker创建容器时，默认会为每个容器创建一个全新的网络命名空间，容器内的进程看到的网络环境是"干净"的：只有一个回环接口 lo 和系统分配的网卡，没有宿主机那些复杂的物理网卡和路由。这种隔离的价值在于安全性和环境一致性——容器内应用永远不关心宿主机长什么样，也不怕互相抢占端口。

你可以在宿主机上验证这个机制。创建两个独立的网络命名空间，分别观察它们的网络设备列表，结果互不相同。这说明命名空间已经把系统网络"切"成了好几个独立小房间。

1.2 veth对：一根连接两个房间的虚拟网线

命名空间之间默认不通，那Docker怎么让容器和宿主机通信？答案是veth（Virtual Ethernet）设备。veth总是成对出现，像一根虚拟网线的两个水晶头：一端在容器里叫 eth0，另一端在宿主机上通常叫 veth开头的网卡。往其中一端发数据，另一端立刻收到，方向相反则同理。这对虚拟网卡不关心底层物理介质，纯粹是内核里的一根"背靠背"通道。

你不需要手动搭veth，但理解它的存在很有必要。当你在宿主机上执行 ip link 查看网卡时，会看到一堆名字像 veth1a2b3c、vethx9y8z7 的接口。这些就是连接各容器命名空间的"网线头"。每多启动一个容器，宿主机上就多一对veth，这是排查网络问题时最直观的信号——如果veth接口消失了，容器大概率也挂了。

1.3 网桥：房间门口的虚拟交换机

一个个veth把容器和宿主机连起来还不够，容器之间要怎么互通？Docker默认会在宿主机上创建一个名为 docker0 的Linux网桥，相当于一个虚拟的二层交换机。所有容器端的veth都插到这同一个网桥上，于是容器A发出二层广播帧时，网桥会把帧转发给所有连在它上面的其他veth口，容器之间就能通信了。

docker0默认的网段是 172.17.0.0/16，容器启动后通常拿到的IP是 172.17.0.x。这个网段不是随便定的，它是网桥自己的"管理网段"，宿主机通过docker0这个网卡接口访问容器。理解这个模型后，你再去看容器IP、veth接口、网桥转发，就不会觉得是一堆黑魔法——本质上就是一台虚拟交换机，连了几根虚拟网线，每根网线另一头是一个容器。

1.4 手动搭一遍：用 ip netns 模拟容器网络

如果想彻底弄清这套机制，强烈建议在Linux主机上搭个"穷人版"实验环境。不需要装Docker，直接用Linux自带的命名空间工具模拟：

# 创建两个隔离的网络命名空间 ip netns add ns1 ip netns add ns2 # 查看两个命名空间里的网络设备 ip netns exec ns1 ip link list ip netns exec ns2 ip link list # 创建一对veth，并分别塞进两个命名空间 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip link set veth2 netns ns2 # 分配IP并启用 ip netns exec ns1 addr add 10.0.0.1/24 dev veth1 ip netns exec ns1 link set veth1 up ip netns exec ns2 addr add 10.0.0.2/24 dev veth2 ip netns exec ns2 link set veth2 up # 测试互通 ip netns exec ns1 ping 10.0.0.2

这个实验做完，Docker网络的地基你就踩实了。Docker只是把这套操作自动化了：创建命名空间、创建veth对、一头进容器、一头接网桥，再顺手配置IP和路由。很多教程直接讲Docker网络模式，但如果不理解这三件套，后面无论哪种模式都会觉得像背书。

2. 网络模式不是选择题，是取舍题：五种模式的原理与适用场景

Docker网络看似模式众多，本质上是围绕"让容器怎么连出去、怎么接进来"做的一组取舍。我帮你把五种模式一次性理清。

2.1 bridge模式：最常用的"默认项"

bridge模式是Docker默认的选择。容器创建时，Docker为它创建网络命名空间、创建veth对、把一端接入网桥、给容器设置IP——就是我们第1章手搭的全套流程。容器访问外网时，数据包经由网桥到达宿主机内核，再走一次NAT（MASQUERADE）把源地址改写为宿主机IP；外部访问容器则通过端口映射的DNAT规则，把宿主机端口上的流量转发给容器IP和端口。

实际使用bridge模式时，我会额外做两件事。第一，自定义网桥而不是用docker0，因为docker0的网段和宿主机现有网段冲突的概率更高，而且自定义网桥支持容器间通过名称直接解析IP，省去查IP的麻烦。第二，容器端口映射要显式声明，例如把宿主机的 8080 映射到容器内的 80，否则外部根本访问不到，因为DNAT规则只针对显式映射的端口。

2.2 host模式：牺牲隔离换性能

host模式下，容器不创建网络命名空间，直接复用宿主机的网络栈。容器里看到的网卡、路由、IP就是宿主机的。好处很明显：没有NAT转发，网络性能几乎无损；容器服务监听的端口直接暴露在宿主机上，不需要做端口映射。坏处同样明显：任何容器里起的服务端口和宿主机进程冲突就麻烦了，比如容器里跑nginx占80，宿主机也有nginx占80，直接报错。

我一般只在两种场景用host模式：一是对延迟特别敏感的网络中间件，比如消息队列、实时流处理服务；二是在容器里调试宿主机网络相关的问题。如果是普通的Web服务、业务接口，不建议图省事用host，隔离性太差，一锅端的风险太大。

2.3 none模式：完全隔离的"离线模式"

none模式会为容器创建网络命名空间，但里面不放任何网卡、不配置任何IP，只有一个回环接口。容器内进程可以跑，但没有网络出口，既不能访问外网，也不能被外部访问。

这种模式听上去很"自闭"，但实际很有用：离线批处理任务、密码学计算、需要严格数据隔离的场景，还有某些安全合规要求极高的数据加工容器，都可以用none。Docker启动时加 --network none 就能用。老实说，大多数人日常用不到，但真遇到"必须确保容器完全没有网络能力"的需求时，它是唯一的默认选项。

2.4 container模式：和伴生容器共享网络栈

container模式让新容器和指定容器共享同一个网络命名空间。两个容器IP地址一样、端口空间一样，看起来就像一台机器上的两个进程。这个模式最典型的应用是Sidecar模式：主容器提供业务服务，辅助容器（日志收集、流量代理、监控采集）不需要自己暴露端口，直接通过localhost访问主容器即可。

用container模式要注意生命周期依赖。因为共享网络命名空间，辅助容器的生存期和主容器强绑定，主容器停了，辅助容器就算没崩溃也无法对外通信。所以编排的时候要想清楚谁是"主"，谁是"伴生"。

2.5 overlay模式：跨主机的"大二层"幻觉

overlay模式解决的是跨主机通信。单机bridge能搞定一个机器上的容器互通，但生产环境通常是多台机器组成集群，容器分散在不同节点上。overlay网络通过VXLAN隧道，把宿主机之间的网络封装成一个大二层网段，容器看到的是一个统一的IP网段，彼此直达，感觉不到物理边界。

在Docker Swarm或Kubernetes里，overlay是标配。理解它的核心要点是：容器数据包先走veth进入宿主机，再被VXLAN封装成UDP包送到另一台宿主机的网桥，再解封装后进入目标容器。配置复杂、封装有开销的同时，换来了调度灵活性和跨主机透明寻址。如果你只在单机玩Docker，overlay可以先了解，不用急着上手。

3. 镜像不是"打好包"就完了：Dockerfile的正确书写姿势与构建加速

3.1 镜像分层：每一条指令都是一层"可复用快照"

Docker镜像由只读层（layer）叠加组成，每一条指令都会生成一个新层。底层的基础镜像层（比如操作系统发行版的rootfs）不变，往上每执行一条 RUN、COPY 等指令就加一层。容器运行时，Docker会在这些只读层之上挂载一个可写层，容器内文件改动都发生在可写层里，底下的只读层不被动。

这个分层机制带来的直接收益是存储和传输效率：多个镜像共用底层基础层时，宿主机只存一份，节省磁盘；拉取镜像时，如果本地已经有对应层，就只拉差异部分。但同时也带来一个构建原则——把不变的东西放在Dockerfile前面，把易变的放在后面，这样能最大化利用层缓存。

3.2 Dockerfile指令：一张表+三个易错点

大部分Dockerfile用到的基础指令就那些，我把每个指令的核心作用整理成下面对照表：

易错点一：RUN, CMD, ENTRYPOINT 一字之差，行为差很远。RUN是构建时执行的，CMD是容器启动时执行的，ENTRYPOINT定义了不可被覆盖的主程序。实际做服务镜像时，我习惯用固定ENTRYPOINT接收参数，CMD只放默认参数，这样docker run后面追加的参数就能灵活传进去。

易错点二：EXPOSE只起文档作用，不产生任何真正暴露。很多人以为写了EXPOSE 80外部就能访问，其实必须配套-p映射或host网络模式才行。不写EXPOSE也不影响映射，写它更多是给使用者和镜像构建者传递信息。

易错点三：COPY和ADD尽量选COPY。ADD的自动解压和URL下载看着方便，但行为隐式、不易调试，文件来源也不够明确。业界主流建议是用COPY处理本地文件，解压需求在RUN里用tar处理，URL用curl+wget处理，一切显式可控。

3.3 构建缓存：为什么改了依赖文件，构建还是走缓存？

Docker构建有层缓存机制，如果某层对应的指令和上下文文件都没有变化，Docker会直接复用已有的层，跳过执行。这个机制用好了能大幅加快构建，用坏了会出现"改了代码却构建了旧依赖"的诡异问题。

一个经典坏示例：

FROM node:20-slim COPY . /app RUN npm install

只要项目里任何文件变了，COPY . /app 这一层就变了，后面 npm install 的缓存也全部失效，每次改一行代码都要重新下载整包依赖，慢到怀疑人生。

好示例是把依赖安装和源码复制分离：

FROM node:20-slim WORKDIR /app COPY package.json package-lock.json ./ RUN npm install COPY . . CMD ["node", "server.js"]

只要package.json没变，npm install这层缓存就一直有效，改了业务代码也只重跑最后COPY和后续构建。缓存失效还有一个隐蔽坑：所有RUN指令里的操作，Docker只能根据命令字符串判断是否变化。如果我执行了 RUN apt-get update && apt-get install -y curl，即使镜像库里某个包更新了，只要命令没变，这层也不会重建。所以关键依赖升级时，得主动采用 --no-cache 或者调整命令来刷新缓存。

3.4 多阶段构建：控制镜像体积的最佳手段

多阶段构建能把编译环境用的所有工具留在中间阶段，最终镜像只保留运行所需内容。比如有一个Go项目，完整链路是先装Go编译器、拉依赖、编译成二进制，最终镜像其实只需要一个可执行文件加运行环境。用传统单阶段构建会导致镜像里有编译器、源码、构建缓存，体积轻轻松松好几百MB。

多阶段构建的写法：

# 第一阶段：编译环境 FROM golang:1.22 AS builder WORKDIR /src COPY . . RUN go build -o myapp . # 第二阶段：运行环境 FROM alpine:3.20 COPY --from=builder /src/myapp /usr/local/bin/myapp ENTRYPOINT ["myapp"]

从builder阶段复制制品到alpine镜像，最终镜像可能只有几十MB。我还遇到过不少"慢且胖"的镜像，绝大多数都是没实践多阶段构建。建一个带 "--target builder" 的调试阶段跑测试、加调试工具，发布时切回正常运行阶段，一套Dockerfile吃两个环境需求，非常划算。

4. 单容器是玩具，多容器才是生产：Docker Compose 的服务编排实战

4.1 为什么Compose是刚需，而不只是"方便"

docker run 能启动单个容器没问题，但一个稍微完整的项目经常需要好几个服务：应用服务、数据库、缓存、消息队列、反向代理。手敲docker run命令至少好几行，还要记端口、记网络别名、记环境变量、记顺序，维护成本陡增。Docker Compose的价值就是把"一组容器当成一个项目"来管理：一份yml文件描述所有服务，一条 docker compose up 全部拉起来，一条 docker compose down 全部停掉，还能自动创建项目专属网络。

我第一次真正敬畏Compose，是在一次环境重构中需要一口气起八个服务：三个后端、两个前端、一个数据库、一个消息队列、一个日志采集器。用Compose文件写清楚后，换机器、换环境都只是复制一份文件的事。这种"描述式运维"思路，比记住一串命令要可靠得多。

4.2 一份compose文件的核心结构

Compose文件的核心是 services 段，每个服务就是一个容器或一组扩缩容的同类容器。我举一个常见的后端+数据库+缓存例子：

version: "3.9" services: app: build: context: ./app dockerfile: Dockerfile ports: - "8080:8080" environment: DB_HOST: db REDIS_HOST: redis depends_on: - db - redis db: image: postgres:16 environment: POSTGRES_USER: myuser POSTGRES_PASSWORD: mypass volumes: - db-data:/var/lib/postgresql/data redis: image: redis:7-alpine volumes: db-data:

值得注意的细节：app服务里 DB_HOST 填的是 db，也就是服务名，这不是随便起的。Compose会自动为项目创建默认网络，每个服务都注册到该网络里，服务间可以通过服务名做DNS解析直接通信。从这个角度看，Compose基于Docker自定义网桥的别名机制，把"查容器IP再配置IP"这件事干掉了。

depends_on 控制的是启动顺序，不是"健康后才启动"。它只保证db和redis容器先被创建，不代表数据库已经就绪。实际开发里经常遇到应用容器先起来连接数据库失败的情况，解决办法是加健康检查配合条件依赖：

services: app: depends_on: db: condition: service_healthy db: image: postgres:16 healthcheck: test: ["CMD-SHELL", "pg_isready -U myuser -d mydb"] interval: 5s timeout: 3s retries: 10

4.3 常用命令：真正用得上的就这么几个

Compose命令集合有点大，但日常高频的其实有限，我按使用频次排一下：

# 构建并启动所有服务（最常用） docker compose up -d --build # 查看服务状态 docker compose ps # 查看所有服务日志并跟踪最新输出 docker compose logs -f # 进入某个服务的容器 docker compose exec app sh # 停止并移除所有服务（包含默认网络，但不删数据卷除非加 -v） docker compose down # 单独重建某个服务 docker compose up -d --build app

有个容易混淆的点：docker-compose 是老版命令，新版用 docker compose（中间没有横线）作为子命令。如果你在服务器上两者并存，建议写作环境统一用 docker compose，如果遇到老项目还在用 docker-compose.yml，也能兼容，只是命令格式不同。

4.4 从docker run迁移到Compose的对照思路

还有一种常见场景：你以前用过 docker run 启动容器，现在要整理成Compose。核心思路是"一个run一个服务"。把所有run里的关键参数按语义归位——-p端口映射对应ports，-e环境变量对应environment，-v挂载对应volumes，--network对应网络配置，--restart对应restart策略，--name对应container_name。这样一边看旧的shell脚本一边写yml，基本不会有遗漏。

如果项目里有多个互相独立的模块，也可以拆成多个Compose文件，用 -f 指定文件组合启动。不过个人建议项目不大时尽量一个Compose文件管全套，维护成本最低。到规模真正变大，单机Compose已经撑不住的时候，再考虑Swarm或K8s不迟。

5. 网络连不上、构建卡住、编排起不来：三个高频问题的排查链路

5.1 容器之间ping不通，先查这三件事

遇到容器间网络不通，我的排查顺序基本固定。第一步，确认两个容器在同一个自定义bridge网络下，可以用 docker inspect 查看NetworkMode和Networks段。如果都在默认docker0而没在自定义网络，检查它们是否通过容器名互通，默认docker0不支持名称解析，只有自定义网桥才有内置DNS。这是新手最常踩的坑。

第二步，测试veth和网桥的状态。在宿主机上 ip link 看veth接口是否存在、状态是否为UP；再用 brctl show 或 bridge link 查看网桥上挂载的接口。如果veth口处于DOWN状态，网络肯定不通。

第三步，检查容器内路由和防火墙。宿主机上 iptables -t nat -L -n 查看是否有Docker生成的POSTROUTING规则，容器内 ip route 看默认路由是否指向网桥网关。通常到这一步，90%的网络问题都能定位到是网络归属错误、网卡状态异常或防火墙规则被第三方工具清掉。

5.2 构建一直"卡"住，其实是缓存和上下文在作怪

Docker构建慢或卡住，最常见的原因有三个。一是构建上下文太大，docker build 默认会把当前目录整个打包发给Docker守护进程，如果有 node_modules、.git、大压缩包在目录里，传输就要花很久。解决办法是写 .dockerignore，原理类似 .gitignore：

node_modules .git *.log dist .venv

第二个原因是网络拉取依赖太慢，尤其是基础镜像、npm/pip包。建议配置镜像加速器，或者在Dockerfile里给包管理器设置国内镜像源。第三个原因是层缓存失效导致每次全量重跑，按3.3节说的把依赖安装和源码分离就能解决。

排查时可以用 docker build --progress=plain 看完整输出，也可以用 docker builder history 查看每个层的耗时，定位最慢的指令再针对性优化。

5.3 Compose起的服务一直重启，大概率是健康检查没配对

Compose里服务容器反复重启，常见原因有几类：启动命令崩溃、端口被占用、健康检查永远不通过。如果只看 docker compose ps 会发现状态是 Restarting，这时第一步 docker compose logs 看应用日志，确认是应用本身报错还是网络连接失败。

如果是健康检查不通过，先确认容器内实际健康检查命令能跑通。比如PostgreSQL的 pg_isready 需要指定用户和库，命令写错就会一直不健康。另外注意，健康检查里的interval和retries尽量别设太极端，否则刚启动时服务还没就绪就被连续判死，进程被反复重启，反而永远起不来。我一般间隔5秒、重试10次起步。

还有个小坑：端口映射冲突。比如redis和另一个服务用了同一宿主端口，第二个容器起不来。通过 docker compose ps 看Port列一目了然，或者在宿主机上执行 ss -lntp 查端口占用。

5.4 多容器项目排错，我用这套组合拳

实际运维中我总结了一套组合拳：先 docker compose ps 看整体状态，再 docker compose logs -f 跟踪最新错误，然后 docker compose exec 进容器手动验证服务监听和网络连通性，最后 docker inspect 查详细网络和挂载信息。这几步走完，绝大多数问题都能定位到具体层级——是应用问题、镜像问题还是Docker网络问题，而不是瞎猜。

6. 实战中沉淀下来的六个习惯

把Docker用好，工具命令只是表面，真正拉开差距的是习惯。

第一，容器里尽量不写业务数据和状态。数据靠volume挂载、数据库靠独立数据卷，容器本身只当"进程包装盒"，丢了随时可以再起一个一模一样的，这才是用容器的安全感来源。

第二，基础镜像固定标签而非latest。latest会随时间漂移，谁也无法保证两次构建环境完全一致。生产构建一般锁定具体版本甚至摘要，开发环境可以宽松一点，但至少要知道漂移带来的风险。

第三，日志全部走stdout。Docker天然收集标准输出，docker logs能看、日志采集器能接。如果应用强制写本地日志文件，容器一删日志就没了，排错全靠重新复现，非常痛苦。

第四，别把所有配置都硬编码进Dockerfile。环境相关的配置用环境变量注入，镜像本身保持环境无关。这样同一个镜像丢到测试、预发、生产，只需要改环境变量，不用重新构建。

第五，每个容器只跑一个主进程。容器内用supervisor硬塞多个进程不是不能用，但会让日志采集、健康检查、资源伸缩全都变得复杂。能用多容器解决的问题就别塞进一个容器。

第六，把端口映射当"出口"而非"标配"。同一网络里的容器通过服务名或IP互通，根本不走宿主机端口；只有需要对外暴露或跨网络访问的才需要映射。端口映射越少，安全隐患越小。

这些习惯不是一次形成的，是我踩了不少坑才沉淀下来的。把Docker网络和编排原理搞明白，再配上这些习惯，日常的开发部署效率会有肉眼可见的提升。