企业官网建设流程全解析

1. 从一次数据丢失事故说起：为什么容器数据卷是必修课

几年前我帮一个团队排查线上问题，他们的服务跑在容器里，某次例行重启之后，数据库里的业务数据全部归零。原因很朴素：容器内的数据写在了可写层，容器一销毁，数据跟着一起没了。这件事之后，他们才真正把数据卷当回事。

容器数据卷、Dockerfile、Docker网络这三块内容，基本构成了容器化落地的“下半场”。上半场是学会跑一个容器，下半场是让容器能持久化数据、能标准化构建、能互相通信。这三件事没搞明白，容器就只能停留在本地玩玩的阶段，上不了正经环境。

这篇内容适合已经会基本的docker run、docker ps、docker images操作，但一到数据持久化、镜像构建、多容器通信就犯迷糊的朋友。我会把这三块拆开讲透，每个部分都配上我实际踩过的坑和可以直接抄的配置。核心关键词就三个：容器数据卷、Dockerfile、Docker网络，全文围绕它们展开，不跑题。

2. 容器数据卷：让数据活得比容器久

2.1 容器文件系统的分层结构决定了数据命运

要理解数据卷，得先理解容器文件系统是怎么组织的。一个容器启动后，它的文件系统是分层的：最底下是只读的镜像层，上面叠加一个可写的容器层。所有运行时的写操作，比如日志、上传的文件、数据库写入，默认都落在可写层里。

问题就出在这个可写层上。它和容器的生命周期是绑定的，容器删除，可写层跟着删除。你可以把镜像层想象成一本书的印刷内容，可写层是贴在书上的便利贴，书还在，便利贴撕了就没了。数据卷的作用，就是把“便利贴”换成一本独立的笔记本，笔记本放在容器外面，容器没了，笔记本还在。

从实现上看，数据卷是宿主机文件系统上的一块目录，被挂载进容器。容器读写这块目录，实际读写的是宿主机的文件。这样一来，数据的生命周期就和容器解耦了。

2.2 三种挂载方式的选择逻辑与实操

Docker 提供了三种把数据带出容器的方式，很多人分不清该用哪个，我按实际使用频率和推荐度排一下。

第一种：具名卷（named volume），用-v 卷名:容器内路径指定。这是官方最推荐的方式，因为卷由 Docker 统一管理，位置在/var/lib/docker/volumes/下，你不用关心宿主机具体路径，跨平台也一致。适合数据库数据、应用上传目录这类“我只想让它持久化，不关心存哪”的场景。

docker volume create appdata docker run -d --name db -v appdata:/var/lib/mysql mysql:8.0

第二种：绑定挂载（bind mount），用-v 宿主机绝对路径:容器内路径指定。它把宿主机上你指定的目录直接挂进容器。好处是路径你完全掌控，改配置文件、看日志特别方便。适合开发环境挂代码、挂配置。缺点是依赖宿主机目录结构，换台机器路径可能不一样，可移植性差。

docker run -d --name web -v /home/deploy/site:/usr/share/nginx/html nginx

第三种：匿名卷，只写容器内路径，不写宿主机部分。Docker 会随机生成一个卷名。这种方式我基本不主动用，因为卷名随机，后续管理麻烦，容易变成“僵尸卷”占空间。它更多是 Dockerfile 里VOLUME指令的默认行为。

选择逻辑可以总结成一句话：要可移植、要 Docker 管，用具名卷；要频繁改文件、要看日志，用绑定挂载；匿名卷尽量别手动用。

2.3 数据卷的备份、恢复与清理实战

数据卷用起来爽，但备份和清理是绕不开的。很多人第一次遇到“磁盘满了”就是因为一堆匿名卷没清。

备份具名卷，我的常用做法是起一个临时容器，把卷和目标备份目录都挂进去，打包：

docker run --rm \ -v appdata:/source:ro \ -v /home/backup:/backup \ alpine tar czf /backup/appdata-$(date +%Y%m%d).tar.gz -C /source .

这里:ro表示只读挂载，避免备份过程中误写源数据。恢复就是反过来解包：

docker run --rm \ -v appdata:/target \ -v /home/backup:/backup \ alpine sh -c "tar xzf /backup/appdata-20240101.tar.gz -C /target"

清理方面，docker volume ls看所有卷，docker volume prune清理没有被任何容器使用的卷。注意prune会删掉所有未使用的卷，执行前一定确认没有“暂时停用但还要保留”的卷。

提示：绑定挂载的目录不受docker volume prune影响，因为它压根不算 Docker 管理的卷。清理磁盘时别只盯着卷，绑定挂载的目录也要单独看。

2.4 数据卷实操中的几个坑

第一个坑是权限问题。容器内进程往往以非 root 用户运行，而挂载进来的宿主机目录属主可能是 root，导致容器写不进去。解决办法是提前把宿主机目录属主改成容器内用户对应的 UID，或者在容器启动脚本里做权限调整。我一般会在部署文档里明确写清楚目录的属主要求。

第二个坑是绑定挂载覆盖容器内原有内容。比如你把一个空目录挂到/usr/share/nginx/html，容器里原本的欢迎页就被空目录盖住了。这不是 bug，是挂载的本质：挂载点以宿主机内容为准。要保留原内容，得先把镜像里的文件复制出来再挂。

第三个坑是跨主机共享。单机的数据卷只在当前宿主机有效，多台机器要共享数据，得用网络存储方案，这就超出单机数据卷的范畴了。别指望-v能跨机器。

3. Dockerfile：把构建过程写成可复现的代码

3.1 为什么需要 Dockerfile 而不是手动装

手动进容器装软件、改配置，然后docker commit生成镜像，这种方式我早期也用过，但很快就放弃了。原因有三个：一是不可复现，同样的操作换个人做结果可能不一样；二是不可追溯，镜像里到底改了什么没人说得清；三是体积失控，commit 出来的镜像往往带着一堆临时文件和缓存。

Dockerfile 的价值在于把“怎么构建这个镜像”变成一份声明式的文本。它可读、可版本管理、可重复执行，构建结果稳定。团队协作里，Dockerfile 就是镜像的“源码”。

3.2 核心指令逐个拆解与常见误用

Dockerfile 指令不多，但每个都有讲究，我挑最关键的几个说。

FROM指定基础镜像，必须是第一条有效指令。选基础镜像的原则是够用就好，能用alpine就别用ubuntu，体积差好几倍。但要注意 alpine 用的是 musl libc，某些依赖 glibc 的二进制跑不起来，这时候得换debian-slim之类。

RUN执行构建时的命令。这里最大的优化点是合并命令、清理缓存。反面教材是这样写的：

RUN apt-get update RUN apt-get install -y curl RUN rm -rf /var/lib/apt/lists/*

每条 RUN 生成一层，三层叠加，而且rm删的是当前层，前面层里的缓存还在镜像里。正确写法是合并成一条：

RUN apt-get update && \ apt-get install -y --no-install-recommends curl && \ rm -rf /var/lib/apt/lists/*

COPY 和 ADD都能复制文件。区别是 ADD 会自动解压 tar 包、支持 URL 下载。我建议除非确实需要自动解压，否则一律用 COPY，行为更可预测。ADD 的隐式解压经常让人意外。

CMD 和 ENTRYPOINT是新手最容易混的一对。简单说，ENTRYPOINT 是容器的“主命令”，CMD 是“默认参数”。docker run后面跟的参数会覆盖 CMD，但不会覆盖 ENTRYPOINT（除非用--entrypoint）。想让容器像个可执行程序一样用，用 ENTRYPOINT；想让用户方便覆盖默认行为，用 CMD。

WORKDIR设置后续指令的工作目录，比用RUN cd靠谱，因为RUN cd只影响当前那条命令。养成显式设置 WORKDIR 的习惯。

ENV 和 ARG都是变量，ENV 在构建和运行时都生效，ARG 只在构建时生效。敏感信息别用 ARG 传，因为docker history能看到构建参数。

3.3 多阶段构建：把镜像体积砍下来

多阶段构建是我认为 Dockerfile 里最值得掌握的技巧。它的思路是：用一个“构建阶段”镜像装编译工具链、编译代码，再用一个干净的“运行阶段”镜像只拷贝编译产物。最终镜像里没有编译器、没有源码、没有缓存，体积能小一个数量级。

以 Go 项目为例：

# 构建阶段 FROM golang:1.21 AS builder WORKDIR /src COPY . . RUN CGO_ENABLED=0 go build -o /out/app . # 运行阶段 FROM alpine:3.19 WORKDIR /app COPY --from=builder /out/app . EXPOSE 8080 ENTRYPOINT ["/app"]

COPY --from=builder是关键，它从构建阶段拿产物。最终镜像基于 alpine，可能只有十几 MB，而构建阶段那个 golang 镜像有一 GB 多，但它不进最终镜像。

3.4 构建缓存机制与加速技巧

Docker 构建是分层缓存的，某条指令没变，它和它之前的层都能复用缓存。所以指令顺序很关键：变化频率低的放前面，变化频率高的放后面。

典型错误是先COPY . .再RUN npm install。这样每次改一行代码，COPY 层变了，后面的 npm install 缓存全失效，重新装依赖。正确顺序是先 COPY 依赖清单文件，装依赖，再 COPY 源码：

COPY package.json package-lock.json ./ RUN npm ci COPY . .

这样只要依赖清单没变，装依赖那层就一直命中缓存。

另外可以用.dockerignore排除不需要进构建上下文的文件，比如node_modules、.git、日志。构建上下文越小，传给 Docker daemon 越快，构建越省时间。

提示：docker build时加--no-cache可以强制不用缓存，排查“缓存导致构建结果不对”的问题时很有用，但别日常都加，会拖慢构建。

3.5 镜像瘦身与安全加固的实操清单

瘦身方面，除了多阶段构建，还有几个动作：选小基础镜像、合并 RUN 并清理缓存、用.dockerignore、避免装不必要的包（--no-install-recommends）。

安全方面，我坚持两条：一是不用 root 跑应用，在 Dockerfile 里创建普通用户并USER切换：

RUN adduser -D -u 10001 appuser USER appuser

二是固定基础镜像版本，别用latest。latest会随时间漂移，今天构建和明天构建可能拿到不同基础镜像，出问题难排查。用具体版本号，比如nginx:1.25.3-alpine。

4. Docker网络：容器之间怎么互相找到对方

4.1 默认网络模型的局限

Docker 装好后自带三种网络：bridge、host、none。默认情况下容器连的是bridge，也就是那个叫docker0的虚拟网桥。

默认 bridge 有个大问题：容器之间只能用 IP 互相访问，不能用名字。而容器 IP 是启动时分配的，重启可能变。你写死 IP，下次重启就失效。这就是为什么单靠默认 bridge 做多容器通信很痛苦。

host模式让容器直接用宿主机网络，没有隔离，端口直接占用宿主机的。性能好但隔离性差，端口冲突风险高。none模式就是不给网络，适合完全不需要网络的批处理任务。

4.2 自定义 bridge 网络：服务发现的关键

真正好用的方案是自定义 bridge 网络。它和默认 bridge 的最大区别是：连到同一个自定义网络的容器，可以用容器名互相解析。Docker 内置了一个 DNS 服务，专门给自定义网络里的容器做名字解析。

创建和使用：

docker network create app-net docker run -d --name db --network app-net mysql:8.0 docker run -d --name web --network app-net myapp:latest

这样 web 容器里直接连db:3306就能找到数据库，不用管 IP。容器重启 IP 变了也没关系，名字解析始终有效。这是多容器应用的标准做法。

4.3 端口映射、容器互联与网络隔离

容器要对外提供服务，得做端口映射，-p 宿主机端口:容器端口。比如-p 8080:80把宿主机 8080 映射到容器 80。注意-p默认绑所有网卡，如果只想本机访问，写-p 127.0.0.1:8080:80。

网络隔离方面，不同自定义网络之间默认是不通的。这可以用来做分层：把前端和后端放一个网络，后端和数据库放另一个网络，前端就碰不到数据库。这种“网络分段”是容器安全的一个实用手段。

docker network create frontend-net docker network create backend-net docker run -d --name web --network frontend-net myweb docker run -d --name api --network frontend-net --network backend-net myapi docker run -d --name db --network backend-net mysql:8.0

web 只能访问 api，api 能访问 db，web 访问不到 db。一个容器可以连多个网络，用多次--network指定。

4.4 网络排查：容器连不上时怎么查

容器网络出问题，排查顺序我一般是这样：

先docker network inspect 网络名，看目标容器在不在这个网络里，IP 是多少。经常发现是容器压根没连对网络。

再进容器ping 对方容器名，看名字解析通不通。解析不通，多半是不在同一个自定义网络。

然后docker exec -it 容器名 sh进去，用nc -zv 目标 端口或curl测端口通不通。端口不通，检查目标服务有没有监听、防火墙有没有拦。

最后看宿主机iptables规则和docker port 容器名，确认端口映射对不对。

常见问题速查：

提示：服务在容器里监听127.0.0.1是个高频坑。容器内的127.0.0.1只指容器自己，外部和别的容器都连不进来。要让服务对外可用，得监听0.0.0.0。

5. 三块内容怎么串起来用

单独看数据卷、Dockerfile、网络是三块知识，实际项目里它们是配合的。我拿一个典型的三层应用举例：前端、后端 API、数据库。

数据库用具名卷持久化数据，连到 backend 网络；后端 API 用多阶段构建的 Dockerfile 打出小镜像，同时连 frontend 和 backend 两个网络；前端连 frontend 网络，对外映射端口。整个编排可以用docker run手动起，也可以用 compose 文件描述。

手动起的顺序和命令大致是：

docker network create frontend-net docker network create backend-net docker volume create dbdata docker run -d --name db --network backend-net \ -v dbdata:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=secret mysql:8.0 docker run -d --name api --network frontend-net --network backend-net \ myapi:1.0 docker run -d --name web --network frontend-net \ -p 8080:80 myweb:1.0

这套下来，数据持久化、镜像可复现、容器可互相发现，三个目标都达到了。实际生产里还会加上健康检查、重启策略、资源限制，但骨架就是这些。

我个人在实际操作中的体会是，这三块内容里最容易轻视的是网络。数据卷和 Dockerfile 出问题往往报错明显，网络问题却经常表现为“时好时坏”或者“重启后就不行”，排查起来最费时间。我的建议是，从一开始就用自定义网络加容器名通信，别图省事用默认 bridge 加 IP，后面能省掉大量麻烦。另外 Dockerfile 里固定基础镜像版本、用非 root 用户这两条，越早养成习惯越好，等镜像多起来再回头改，成本高得多。