企业官网建设流程全解析

这段时间陆陆续续处理了不少同事发来的Docker使用问题，从容器起不来、连不上，到数据莫名其妙消失，再到镜像拉取慢。有些问题看起来完全不同，但排查到最后往往都能归到几个相同的根因上。写这篇总结，就是想把这段时间踩过的、帮别人排查过的常见问题按场景整理出来，给同样在用Docker做本地开发或部署的朋友一条能直接照着走的排查路径。

需要提前说明的是，Docker本身迭代快，不同版本的报错措辞和默认行为有差异，但底层的机制基本稳定。我会把每次问题发生的现象、根因、定位顺序和解决方式都写清楚，部分内容基于常见实践的补充，覆盖到对应版本的行为。

1. 容器“起不来”和“连不上”：最常被问到的两类问题

1.1 一次典型的部署失败现场

有个同事跟我说：镜像跑起来了，但浏览器打不开页面。我让他把docker ps的输出发过来，看到这样一段：

CONTAINER ID IMAGE COMMAND PORTS 9c2e4f1a3b77 nginx:alpine "/docker-entrypoint.…" 0.0.0.0:8080->80/tcp

这其实已经能说明问题了：容器里Nginx监听的是80端口，映射只写了8080->80，没有IP限定。他访问的却是服务器IP的8080端口，理论上应该通。进一步问了才知道，他用的云服务器安全组没放行8080端口，所以外部流量根本到不了宿主机。这不是Docker的问题，是宿主机的网络访问控制没跟上。

Docker的端口映射只是把容器端口暴露到宿主机上，宿主机到外部还有防火墙、安全组这一层。任何一层没放行，容器连不上都跟Docker本身没关系。排查这类问题，我的习惯是先把访问拆成两段看：容器内到宿主机端口通不通，宿主机端口到外部网络通不通。前者看端口映射和容器内进程，后者看防火墙、安全组、端口是否被占用。

1.2 端口写反与监听地址的两个误区

端口映射的格式是宿主机端口:容器端口，这个方向很多人会写反。写反了通常表现为：容器能启动，docker ps里也能看到映射，但访问时要么连接被拒绝，要么请求到了完全不对的服务上。

举个例子，如果MySQL容器的默认端口是3306，你想用宿主机13306端口访问它，正确写法是：

docker run -d -p 13306:3306 mysql:8.0

写成-p 3306:13306，含义就完全反了：宿主机暴露3306，映射容器里不存在的13306端口。容器启动时不会因为容器内端口不存在而报错，它只是把宿主机3306监听起来，转发到容器的13306，但进程根本没在13306监听，所以连接失败。

另一个容易忽略的点是-p 127.0.0.1:8080:80和-p 8080:80的区别。前者只绑定localhost回环地址，只能在宿主机本机访问，局域网内其他机器都访问不到；后者绑定所有网卡，外部才能访问。很多人在本机调试没问题，拿到服务器上部署就访问不了，查了半天发现是绑定地址写成了127.0.0.1。这个不算坑，是明确行为，但值得记住。

1.3 防火墙和端口占用的排查顺序

容器起不来或者连不上，我建议按这个顺序查：

1. 先看docker ps -a，确认容器是运行中还是已经退出。Exited状态先看docker logs，多半是启动命令出错。
2. 确认容器内部进程监听地址。用docker exec 容器名 netstat -tlnp看，确认监听端口和端口映射的容器端口一致。
3. 确认宿主机端口是否被占用。ss -tlnp | grep 端口号，如果已经有其他进程占用，Docker会把映射挂起，端口实际没生效。
4. 再查宿主机防火墙。常见Linux发行版的自带防火墙或云安全组都要确认放行。

有一次排查一个容器连不上的问题，前三步全都没问题，最后发现是云厂商安全组里只放行了80端口，8080没放行。改成放行之后立刻通了。这类问题反复出现，值得养成先看安全组/防火墙的习惯。

2. 数据“消失”的惊魂时刻：写进容器层的代价

2.1 删掉容器后数据去了哪里

遇到过一个做数据分析的同学，他把处理好的结果存在容器里，然后执行了一次容器重建，数据全没了。这不是Docker丢数据，而是数据写在了容器可写层里。

容器由镜像层和容器可写层组成。镜像层是只读的，容器启动后所有写入都发生在可写层。删除容器时，如果没有显式使用数据卷，可写层会一并删除。这就是数据“消失”的真相。

验证一下很容易：启动一个容器，在里面创建一个文件，然后用docker commit把容器提交成镜像，再基于新镜像启动一个容器，文件还在。这是因为commit会把当前可写层的内容固化到镜像层里。但如果不commit直接删容器，可写层连同文件就没了。

2.2 三种数据持久化方式怎么选

Docker提供三种主要方式让数据绕过容器可写层。我按使用建议列个表：

named volume用起来很简单，直接指定volume名称：

docker run -d -v mysql_data:/var/lib/mysql mysql:8.0

mysql_data这个volume会被Docker创建并管理，宿主机上对应的实际目录在Docker的数据目录下，不指定路径就在那里。

bind mount是把宿主机绝对路径挂进容器，修改两边同步，适合放配置文件。比如Nginx的配置文件挂在宿主机目录里，改完直接生效：

docker run -d -p 80:80 -v /srv/nginx/conf:/etc/nginx/conf.d nginx:alpine

选择标准很简单：需要跨容器共享、需要长期保留的数据，用named volume或bind mount；纯临时数据随意。

2.3 不该放在容器可写层的东西

除了业务数据，有几类东西特别容易被人误放进容器可写层，导致空间膨胀或者性能受损。

SQLite数据库文件就是一个典型。SQLite每次写入都要落到磁盘，容器可写层走的是存储驱动，对频繁的随写小IO不友好。结果就是SQLite文件越大，读写越慢，容器删除后数据丢失。SQLite或者任何需要本地落盘的文件型数据库，至少用bind mount挂到宿主机目录。

日志文件也一样。容器日志默认写到宿主机上，但应用内部如果自己写日志文件到容器可写层，时间长了容器体积会明显增长。处理方式：要么把日志目录挂出来，要么让应用直接输出到stdout，由日志采集器统一收。

还有依赖安装产生的缓存文件，比如包管理器缓存、临时编译产物。这些属于典型的“写一次、永不读”的数据，留在可写层只会白白占用空间，而且没法单独清理，必须重建容器。合理做法是在镜像构建阶段就清理掉，或者挂个tmpfs让它们随容器停止而清空。

3. 镜像构建与体积：层、缓存和悬空镜像的循环死结

3.1 一条RUN带一个层：构建顺序为什么重要

有次构建一个应用镜像，Dockerfile大概有三处RUN apt-get install，每次安装的东西不一样。构建时反复拉包、反复产生新层，镜像体积也很大。

Dockerfile里每条RUN都会产生一个只读层。层越多、每层内容越大，镜像就越大。更关键的是，Docker构建时会尽量复用已有层缓存：如果某条指令没有变化且前面的层缓存命中，它就不会重新执行。

这里的坑在于：如果某条RUN指令内容有变化，它之后的层缓存全部失效。比如你先把整个源码目录COPY进镜像，再执行依赖安装，那么每次源码改动，源码层变化，后面所有依赖安装层都重新执行。依赖没有变化，却白白重建一遍。

合理顺序是把不常变化的部分放前面，常变化的部分放后面。比如Node.js应用，一般先复制package.json和锁文件，执行依赖安装，再复制源码。源码一改，依赖安装缓存仍然命中，只有后面的源码层和构建层重建。这个顺序调整对构建速度的影响非常明显。

3.2 缓存失效后如何“抢救”

构建缓存也不总是好事。有个场景是apt-get update和apt-get install分开写，第一次构建成功，后续某次因为网络问题拉包失败，重试又好了，但缓存命中的update层是旧的包索引，安装时包版本变了，就可能出现包找不到或者版本不一致。

这种“缓存有毒”的情况，最直接的办法是构建时加--no-cache强制不走缓存。但每次都加很明显不高效。更稳妥的做法是把update和install合并成一条RUN。这样缓存只在整条命令都没变化时命中，一次失效就整体重跑，不会出现“索引新、包旧”的错位。

在安装阶段用版本锁定也能极大减少这种问题。比如把精确版本号写进包名里，同一个版本在缓存有效期内必能命中，缓存失效时也不会装出个不同的版本。

3.3 清理命令与悬空镜像

悬空镜像就是<none>:<none>这种标签为空的镜像。它们不是主动创建的，大部分是重建镜像时旧版本留下的。重建一次镜像，旧镜像的标签会被新镜像拿走，旧镜像就变成悬空。悬空镜像不会自动清理，时间长了会占用不少磁盘空间。

清理命令要分清楚力度。docker image prune只删除悬空镜像，不动有标签的，相对安全。docker system prune -a会把所有未在运行的容器所依赖的镜像都清掉，包括有标签的镜像。这个命令执行后，本地没有容器使用的镜像全部消失，下次启动需要重新拉取，慎用。

我习惯的清理节奏是：每次做批量镜像重建之后，先看一眼docker images里有没有一堆<none>，有就执行docker image prune -f。磁盘空间紧张时才考虑docker system prune，并且先加-a确认要删什么。

3.4 镜像瘦身思路：多阶段构建

镜像体积问题不单是缓存造成的，最核心的还是构建方式。典型的Dockerfile里先装编译工具链，编译完再把运行时依赖装一套，工具链和源码包全留在镜像里，体积巨大。

多阶段构建的思路很直接：第一个阶段负责编译，产生编译产物；第二个阶段只拷贝需要的产物，不携带编译工具。比如一个C程序，最终镜像里只需要可执行文件，不需要gcc和头文件。Java应用可以把jdk编译阶段独立出来，运行时镜像只用精简的运行时环境。

多阶段构建对体积的改善非常可观。一个包含完整编译工具链的镜像如果接近1GB，多阶段构建后可能降到两三百MB。它同时还能减少攻击面：镜像里没有编译器和多余文件，漏洞面自然小。

4. 容器内的时区、字符集与字体：三样容易被忽略的小事

4.1 相差8小时只是开始

容器默认时区是UTC，也就是比北京时间慢8小时。如果宿主机和容器时间看起来对不上，先确认一下不是时区问题。一个非常省事的方式是直接在启动时指定时区环境变量：

docker run -d -e TZ=Asia/Shanghai nginx:alpine

很多官方镜像的启动脚本会读取这个变量并处理符号链接，容器内时间就跟北京时间一致了。某些精简版镜像不带时区数据，TZ变量可能不生效，那就需要把宿主机时区文件挂进去再设置软链接：

docker run -d \ -v /etc/localtime:/etc/localtime:ro \ -e TZ=Asia/Shanghai \ nginx:alpine

时区问题还容易引发日志和数据库时间不一致。排错的时候我发现，很多时间对不上的问题根源不是“服务器时间错了”，而是容器和宿主机用了两个时区。先统一时区配置再谈其他。

4.2 中文乱码和缺失字体的真实场景

字符集问题多出现在Java、Python应用里。有些镜像默认locale不是UTF-8，写入数据库的字符串出现乱码，或者PDF生成时中文变成方框。

乱码的常规解法是设置环境变量LANG=C.UTF-8或LANG=en_US.UTF-8，很多场景能直接解决：

docker run -d -e LANG=C.UTF-8 -e LC_ALL=C.UTF-8 应用镜像

字体缺失更隐蔽。有个做报表打印的场景，容器里没有中文字体，程序调用字体渲染时直接抛出异常或者输出一堆方块。解决办法就是在镜像里安装字体包：

FROM openjdk:11-jre-slim RUN apt-get update && apt-get install -y fonts-noto-cjk \ && rm -rf /var/lib/apt/lists/*

装了字体包之后，PDF和Excel里的中文才正常。注意有些精简镜像自带的字体非常少，不只是中文，英文也缺，遇到渲染类应用要先把字体环境列进验证清单。另一个思路是在宿主机共享字体目录到容器里，但这样镜像没有自包含性，换机器部署就得重新挂载，不推荐作为默认方案。

5. 镜像仓库与拉取体验：那层看不见的注册表配置

5.1 daemon.json里的mirror配置

在国内网络环境下，直接从默认公共仓库拉取镜像经常不稳定，表现为超时、连接重置、层下载一半就断。给Docker配置镜像加速是很常见的做法，有效但很多人的配置方式不对。

Docker守护进程读取/etc/docker/daemon.json里的registry-mirrors配置。一个典型配置是这样：

{ "registry-mirrors": ["https://某个可用的镜像加速地址"] }

配置完需要重启dockerd：

sudo systemctl restart docker

验证配置是否生效，用docker info查看Registry Mirrors部分。这一步很多人会漏，改完没重启，或者重启的不是正确服务，导致看起来没变化。

需要说明的是，镜像加速只对配置的仓库生效，并不影响所有仓库的拉取。如果你从某个第三方源直接拉镜像，它还是会走自己的网络链路加速不了。另外，不同云厂商提供的加速地址只对该云平台的网络环境优化更明显，具体效果需要实测。没有哪一个公共加速地址是永久稳定的，遇到长期拉不动，建议多换几个验证。

5.2 私有仓库与insecure-registries

公司内部一般有自己搭的仓库，很多是HTTP协议而不是HTTPS。Docker默认要求仓库走HTTPS，遇到HTTP仓库会直接拒绝连接，报错类似：

http: server gave HTTP response to HTTPS client

这时候要在daemon.json里把该仓库加入insecure-registries，告诉Docker允许对这台仓库走HTTP：

{ "insecure-registries": ["registry.internal.example.com:5000"] }

改完后同样重启dockerd，并且需要重新登录私有仓库。这里有个容易混淆的点：insecure-registries只影响仓库连接时的协议校验，并不等于免认证。私有仓库如果开启了认证，还是需要docker login。

5.3 tag滞后与latest的坑

还有一个和仓库强相关的问题：latest标签不等于最新代码。很多仓库的latest只是某个时刻的构建产物，它可能是一个月前的版本，也可能因为重新打标签覆盖了。这个坑在排查镜像行为不一致时尤其容易出现。

解决办法是：发布脚本里不依赖latest，而是为每次构建生成带唯一标识的标签，比如应用名-1.2.3或带提交号的标签。部署时手写具体标签，避免“这镜像明明更新了，跑起来还是老代码”的困惑。容器编排平台里也推荐尽量使用非浮动标签，这样回滚和排查都更清晰。

6. 权限相关的边界问题：docker组、UID错位和privileged

6.1 docker组与socket权限

新装的Docker环境里经常遇到这样一条报错：

permission denied while trying to connect to the Docker daemon socket

原因是没有权限访问/var/run/docker.sock这个Unix socket。Docker守护进程默认只允许root用户和docker组的用户访问。把自己加入docker组是常见解法：

sudo usermod -aG docker $USER

执行后需要重新登录终端让组权限生效。但这里有个值得强调的安全问题：docker组里的用户能创建特权容器读写宿主机文件系统，这实际上相当于有了宿主机root权限。把用户加进docker组要意识到这个权限边界。团队开发机里经常为了图省事全员加docker组，如果机器上有重要程度较高的数据，建议限制docker组用户范围，或者通过别的方式做权限隔离。

6.2 挂载目录的UID错位

bind mount的权限错位是特别常见的问题。假设宿主机上有个目录属于UID 1000的用户，挂进容器后容器内以root运行，root读写没问题。反过来，如果容器进程以UID 1001运行，宿主机目录属于UID 1000，那么写入文件会报Permission denied，或者生成的文件属主变成容器进程的UID，宿主机上看起来属于另一个奇怪的用户。

排查时先看容器进程以什么身份运行：

docker exec 容器名 id

如果容器进程是root，而挂载目录在宿主机上属于非root用户，解决办法是调整目录属主，或者用--user参数让容器进程以匹配的UID运行，例如让容器进程以宿主机当前用户身份执行：

docker run -d --user 1000:1000 -v /srv/data:/data 应用镜像

这里有个细节：--user后面的UID和GID是宿主机视角的数字，容器内的用户名可能不存在，但不影响进程运行。挂载文件时，宿主机和容器共享的是同一个文件系统视图，UID是同一套语义，理解这一点就基本掌握了。

6.3 privileged和capabilities

很多人在容器里跑一些需要底层权限的程序，一开始就上--privileged，报什么权限错误都用它解决。--privileged会给容器赋予几乎所有内核能力，同时也关闭了大量容器隔离限制，安全问题很明显。

实际上大部分程序只是缺少个别capability。比如修改系统时间需要SYS_TIME，抓包需要NET_RAW，绑定低端口在非root下需要NET_BIND_SERVICE。合理做法是用--cap-add只添加所需能力：

docker run -d --cap-add SYS_TIME ntpd

用--cap-drop=all然后单独--cap-add是更严格的做法，相当于默认关掉所有特权，只开必要项。我之前调试一个需要原始套接字的程序，--privileged能跑，但换成--cap-add NET_RAW也完全正常。能不开--privileged就不开，这个原则坚持下来省了很多后续麻烦。

7. 排查习惯与几个不能丢的调试命令

7.1 docker inspect比日志更早告诉你问题

很多人遇到容器异常第一反应是docker logs，但有些问题日志里根本看不到。docker inspect能拿到容器完整的配置、网络、挂载、环境变量、健康检查这些元信息，排查时往往更快定位。

举例说明，docker inspect可以查看容器的IP地址：

docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' 容器名

如果容器间需要通信但用主机名解析失败，先看它们在不在同一个Docker网络里：

docker network inspect 网络名

确认网络连接情况，再决定是补加网络还是调整服务发现。日志负责呈现应用内部发生了什么，inspect负责呈现容器本身是怎么配置出来的。两个配合，大部分问题都能定位。

7.2 容器卡死时的急救操作

有一种情况是容器状态还是Up，但里面进程已经死锁或卡死，怎么操作都没响应。直接强制停止有数据丢失风险，但必要时也得做：

docker stop -t 0 容器名

-t 0表示不等待优雅退出，直接发SIGKILL。如果容器处于无法响应调度状态，用docker rm -f强制删除。更重的场景需要重启Docker服务：

sudo systemctl restart docker

重启docker会中断所有容器，属于最后手段。不过Docker本身对异常终止的容器有自动恢复机制，如果配置了--restart策略，重启docker后容器会按策略拉起来。

在生产环境处理这类问题，我建议先docker inspect确认重启策略和挂载配置，再把容器stop、重新start，比直接rm -f更稳妥，因为保留了容器配置和挂载关系。

7.3 容器内时间和日志排查的先后顺序

前面说的时区问题，在调试时最容易伪装成“服务挂了”或“日志漏了”。有一次排一个定时任务没执行的问题，查了执行器、日志和权限都没问题，后来发现容器时区是UTC，定时配置写的是北京时间，执行时间点永远对不上。

遇到定时任务、日志时间戳、数据库写入时间异常，先统一确认时区，再继续排查业务逻辑。这一步成本很低，但经常省下大量时间。我自己排查这类问题的顺序是：先看容器时间docker exec 容器名 date，再看宿主机时间，再看应用日志时间戳，对比出来之后就知道是不是时区导致的。

在用的过程中我发现，Docker的绝大多数“灵异现象”最后都能落在几个基础机制上：分层存储、镜像仓库配置、网络访问链路、权限边界。把这些基础机制理解清楚，遇到任何新报错都能有条理地拆解，而不是靠猜和试。