香港服务器 Docker 部署后怎么验收？镜像加速、overlay2 和容器网络逐项检查

Docker 服务启动成功、hello-world 能运行，并不代表香港服务器已经具备生产交付条件。镜像可能依然从非预期地址下载，容器写入的数据可能落在可写层，端口也可能只在服务器本机可访问。这些问题往往到第一次发布、容器重建或业务切流时才暴露，届时再调整配置，影响范围会明显扩大。

验收应分别回答三个问题：镜像能否按预期获取，存储是否采用交付要求的后端并正确保存数据，容器网络是否同时满足连通与访问边界要求。 判断依据不能混用：镜像加速看实际请求路径和拉取结果，overlay2 看驱动、底层文件系统与挂载关系，容器网络看 DNS、路由、端口映射及外部访问结果。以下按交付对象逐项核对，不把验收扩展成重新安装教程。

面向香港服务器上的网站、业务后台、数据库与容器化应用，A5数据提供香港、美国、日本、韩国、中国台湾、新加坡和马来西亚等地区的物理服务器资源，覆盖Xeon Gold、AMD EPYC、SSD/NVMe存储及不同带宽线路方案。香港产品可结合CN2与国际带宽选择，另有大内存、多IP、GPU和大容量存储系列，为镜像获取、容器运行、数据持久化及多任务部署提供相应的硬件与网络基础。

一、先核对交付基线：验收的是哪套 Docker 环境

同一台服务器上可能存在多个 Docker 上下文，也可能使用远程守护进程。若没有先确认操作对象，后面的磁盘和网络检查就可能对错机器。

本文命令以 Linux 服务器、常规 rootful Docker Engine 为主要场景。读取 Docker 信息需要相应权限；Docker 用户组权限接近宿主机管理权限，不应为了验收随意给普通账户授权。使用 rootless 模式、Docker Desktop 或托管容器平台时，数据目录、网络实现和服务管理方式应按实际环境调整。

核对项：客户端、服务端和目标服务器是否一致

docker context show
docker version
docker info
uname -r
cat /etc/os-release

重点记录服务端版本、操作系统、内核、Docker 数据目录及存储驱动，不要只留客户端版本。若 docker version 只有 Client 信息，说明客户端可以执行，但尚未证明它能够连接 Docker 服务端。

在使用 systemd 管理 Docker 的发行版上，可补充：

systemctl is-active docker
systemctl is-enabled docker

active 表示当前服务运行；enabled 表示配置了随系统启动，两者不是一回事。服务正常但未启用开机启动，不能直接签署“重启后自动恢复”这一项。非 systemd 环境则使用实际服务管理工具，不套用上述命令。

判断依据：建立能对应后续测试的交付记录

如果交付要求包括宿主机重启后的自动恢复，必须在批准的维护窗口复核，不能把“当前容器正在运行”当作替代证据。生产服务器不要为补齐验收记录临时重启。

二、镜像加速验收：配置存在，不等于下载经过加速源

香港服务器的镜像拉取表现受仓库位置、服务器出口、仓库端限流、认证及镜像大小共同影响。服务器位于香港，并不能直接推出某个镜像源一定更快；增加多个地址，也不能简单理解为多线路并行下载。

镜像加速这一项，要分开验收“配置生效”“路径符合预期”和“获取结果可用”。

核对项一：守护进程是否读取了预期配置

docker info --format '{{json .RegistryConfig.Mirrors}}'

输出应包含交付约定的镜像源地址。仅在配置文件里看到 registry-mirrors，不足以证明运行中的 Docker 已加载配置。

还应确认加速范围：

• Docker Engine 的 registry-mirrors 主要用于 Docker Hub 镜像，不会自动加速所有第三方仓库。
• 从企业私有仓库拉取镜像，应检查该仓库自身的地址、认证和网络路径。
• docker pull 正常，不代表使用独立 BuildKit 构建器时，基础镜像下载也经过同一配置；构建器需要单独验收。
• 配置地址存在，不代表该镜像源当前允许访问、具备对应镜像或不会回退到其他路径。

验收阶段不建议直接覆盖 /etc/docker/daemon.json。如确需修正，应先备份现有配置，确认发行版、服务启动参数及配置语法，并安排变更窗口；重启 Docker 可能影响运行中的容器，回滚应恢复原配置并复核服务状态。

核对项二：代表性镜像能否完整拉取

优先选择本次交付实际需要的业务镜像。下面用小型工具镜像演示命令，它只能验证基本拉取能力，不能代表大型业务镜像的发布耗时：

time -p docker pull docker.io/library/busybox:1.36

docker image inspect docker.io/library/busybox:1.36 \
  --format 'ID={{.Id}} Digests={{json .RepoDigests}} OS={{.Os}} Arch={{.Architecture}}'

核对拉取命令是否成功退出、镜像系统和架构是否匹配，以及是否得到可记录的镜像摘要。生产发布宜记录完整镜像引用与摘要；标签可以变化，摘要更适合说明“这次实际验收的是哪一份镜像”。

遇到拉取失败时，先按错误归属判断：

核对项三：是否能证明加速路径，以及是否满足发布时限

一次成功拉取，只能证明镜像获取成功。要确认请求经过指定镜像源，优先查看可管理镜像缓存服务的访问日志，或结合 Docker 日志、网络连接记录验证目标地址。使用 systemd 的服务器可先查看已有日志：

journalctl -u docker --since "20 minutes ago" --no-pager

默认日志不一定记录每次成功请求，因此“日志没有报错”不能证明加速命中。若需要临时增加日志详细程度，应作为受控变更处理，不为验收擅自重启生产服务。提交日志时还应隐藏认证信息及敏感仓库路径。

时间对比也要排除本地缓存。若输出主要是 Already exists，本次操作更多是在验证远端元数据，并非重新下载全部镜像层。不要为了制造冷缓存在生产环境执行批量清理；应在测试节点或独立验收环境比较同一镜像摘要的拉取耗时。

例如，某次发布允许镜像准备占用 180 秒，验收就应检查代表性业务镜像能否在这一预算内完成，并记录完整耗时。这个预算属于发布流程，不是所有香港服务器的通用标准。

镜像加速的通过条件是：配置被运行中的服务读取，适用范围清楚，代表性镜像获取成功，且需要验证的请求路径有证据支持。 若只证明拉取成功，可签署“镜像获取可用”，但不应扩大为“加速源已命中”。

三、overlay2 验收：先确认后端，再核对磁盘与数据去向

overlay2 验收最容易出现的问题，是把“Docker 默认存储方式”与“当前机器实际使用方式”混为一谈。

较新的 Docker Engine 安装可能使用 containerd image store，信息中可能显示 overlayfs 及相关 snapshotter，而不是传统的 overlay2。这并不自动表示部署错误，也不能直接当作 overlay2 验收通过。如果交付合同明确要求传统 overlay2，就应核对该后端；如果只要求支持 OverlayFS 的容器存储能力，应按实际实现验收。

核对项一：存储驱动是否符合交付约定

docker info --format 'Driver={{.Driver}}'
docker info --format 'DriverStatus={{json .DriverStatus}}'
docker info --format 'DockerRootDir={{.DockerRootDir}}'

传统 overlay2 环境中，驱动应显示 overlay2。再结合完整 docker info 查看底层文件系统、Supports d_type 等信息。

若显示 containerd snapshotter 相关信息，应记录这一事实，并确认它是否符合本次交付要求。不要因为字段名称不同就现场切换后端：切换可能使原有镜像或容器在当前视图中不可见，也可能需要重新拉取和重建，必须单独规划迁移、备份与回退。

核对项二：数据目录所在文件系统是否支持、空间是否足够

确认 Docker 上下文连接的是本机后，可检查传统 Docker 数据目录：

ROOT="$(docker info --format '{{.DockerRootDir}}')"

findmnt -T "$ROOT" -o TARGET,SOURCE,FSTYPE,OPTIONS
df -h "$ROOT"
df -i "$ROOT"

判断应分别对应：

• 文件系统兼容性：传统 overlay2 常见于 ext4，以及支持目录项类型的 XFS 环境。XFS 需要核对 ftype=1；不能只看到“XFS”就签署通过。
• 容量余量：镜像层、容器可写层、日志与构建缓存会占用空间，拉取期间还可能需要临时空间。
• inode 余量：大量小文件可能先耗尽 inode，即使磁盘容量仍有剩余。
• 挂载属性：只读挂载、磁盘错误或不适合该后端的文件系统，不能靠容器偶尔启动成功排除风险。

若底层为 XFS，且系统已安装相应工具，可对前面查到的挂载点运行：

xfs_info /实际挂载点

将路径替换为真实挂载点，检查输出中的 ftype。其他文件系统不要套用该命令。

使用 containerd image store 时，还要确认 containerd 的实际数据位置；其镜像内容及快照数据可能不在 DockerRootDir 所在文件系统。不能仅检查 /var/lib/docker，就认定全部容器存储空间充足。

容量阈值应按发布方式制定。例如，验收环境当前剩余 24 GiB，而升级时新增镜像层、解包和缓存预计需要约 15 GiB，这只能说明存在约 9 GiB 的估算余量；还要扣除业务增长和日志占用。固定要求“剩余 20%”可以作为告警起点，但不能替代实际空间核算。

核对项三：业务数据是否离开容器可写层

overlay2 负责容器文件系统，不等于业务持久化方案。检查目标容器的挂载：

docker inspect 业务容器名 --format '{{json .Mounts}}'

核对 Type、Source、Destination 和读写属性，确认应用实际写入的目录，与交付约定的卷或绑定挂载一致。只创建卷、没有挂载到正确目录，仍可能把数据写进容器可写层。

这里必须区分三个动作：

持久化验收应在测试副本中，通过应用允许的方式写入一条验收记录，再按正式发布方式重建容器并读取记录。不要直接对生产数据库执行试写、删容器或替换目录。

重建前应确认备份可用、部署定义完整且不会删除卷；影响范围限于测试副本。若失败，恢复原部署定义并按备份方案恢复测试数据。通过依据是数据仍能由应用读取，而不只是宿主机目录中“还能看到文件”。

四、容器网络验收：把 DNS、出站、内部通信和入站分开

网络验收不能只运行一次 ping。ICMP 不通不一定代表业务不可用，能 ping 通也不能证明 DNS、TCP 端口、HTTP 服务或访问限制正确。

建议先检查网络配置，再验证实际连接。这样异常出现时，能够判断问题属于 Docker 网络、宿主机还是外部访问路径。

核对项一：网段是否冲突，容器是否接入正确网络

docker network ls
docker network inspect 业务网络名
ip -4 addr
ip -4 route

核对 Docker 网络子网是否与服务器已有路由、机房内网、数据库网段或企业网络重叠。冲突可能导致某些目标地址被送入本地 Docker 网桥，表现为“宿主机正常、容器访问特定地址失败”。

同时确认业务容器接入了预期网络：

docker inspect 业务容器名 \
  --format '{{json .NetworkSettings.Networks}}'

用户自定义 bridge 网络支持同网容器按名称解析；默认 bridge 不能直接套用这一判断。采用 host 网络的容器则共享宿主机网络命名空间，不应再按普通 bridge 的端口映射方式验收。

网段不应为了看起来“标准”而统一修改。若发现冲突，应先记录现有网络与部署定义，安排重建相关网络和容器的窗口；修改正在使用的网络可能中断连接，不能在验收时直接调整。

核对项二：容器 DNS 与实际出站访问是否可用

在允许创建临时诊断容器、且已准备好工具镜像的环境中，可运行：

docker run --rm --network 业务网络名 \
  docker.io/library/busybox:1.36 cat /etc/resolv.conf

docker run --rm --network 业务网络名 \
  docker.io/library/busybox:1.36 nslookup example.com

替换为真实网络名称；第二条命令中的域名也宜替换为业务实际访问的域名。命令会创建临时容器，--rm 仅在退出后清理该诊断容器，本例不挂载业务数据，也不修改网络配置。

用户自定义网络里看到 127.0.0.11，通常是 Docker 内嵌 DNS 的正常表现，不是解析异常。反过来，将宿主机本地解析器的 127.0.0.53 直接配置进容器，并不等于容器可以使用宿主机解析服务，因为容器有自己的回环地址空间。

DNS 成功后，还应通过业务镜像内的工具或获准的诊断镜像，访问实际依赖的协议和端口，例如 HTTPS API、数据库或缓存。判断依据应是连接建立、证书校验和应用响应，而不是只解析出 IP。

若小请求正常、大响应传输频繁超时，需要进一步检查链路 MTU、路径 MTU 发现及中间网络设备；不要未经验证就统一下调所有 Docker 网络的 MTU。

核对项三：容器间通信是否符合设计

在同一用户自定义网络内，应分别验证：

• 服务名能否解析到正确容器。
• 目标应用是否监听预期端口。
• 连接后是否返回预期协议响应。
• 不应直接互通的服务，是否仍保持隔离。

服务名解析成功只是 DNS 通过。如果应用只监听容器内的 127.0.0.1，其他容器仍无法访问。反之，如果两个本应隔离的服务能够互访，也不能把它计为“网络表现良好”。

不要依赖临时容器 IP 作为稳定服务地址；容器重建后地址可能变化，验收应尽量使用正式部署采用的服务名和网络关系。

核对项四：发布端口是否从正确位置可达

docker port 业务容器名

docker inspect 业务容器名 \
  --format '{{json .HostConfig.PortBindings}}'

检查宿主机地址、宿主机端口与容器端口的对应关系。绑定到 127.0.0.1 通常适合仅供本机 Nginx 等组件访问；绑定到所有地址时，则必须进一步核对外部防火墙与访问限制。

若业务提供 HTTP 服务，可分别从宿主机和获准的外部测试机请求实际入口：

curl --connect-timeout 5 --max-time 15 \
  -o /dev/null -sS \
  -w 'code=%{http_code} connect=%{time_connect}s total=%{time_total}s\n' \
  'http://实际入口地址:实际端口/健康检查路径'

5 秒连接超时、15 秒总超时只是诊断参数，不是统一验收指标。健康检查路径应确认能代表服务就绪；某些首页返回 200，并不能证明数据库等关键依赖正常。

本机成功、外部失败时，应依次核对监听地址、端口发布、宿主机转发规则、云平台安全组或机房防火墙。若公网入口经过 Nginx，还需验证从入口到容器的完整链路。

端口映射成功不等于访问边界正确。 Docker 发布端口可能与宿主机防火墙工具的规则路径存在差异，不应只看防火墙界面就认定端口已被限制。应从允许与不允许的来源实际验证；双栈环境还要分别检查 IPv4、IPv6。验收阶段不直接清空或重写防火墙规则。

五、按对象签署结果，不用“全部正常”代替证据

交付记录可以精简，但每项都要明确“验证了什么、没有验证什么”。以下状态适合直接用于验收单：

留证时保留测试时间、服务器标识、Docker 服务端版本、镜像摘要、关键命令输出及外部测试位置即可。不要把完整环境变量、仓库凭据或未经脱敏的配置作为附件。

若镜像获取通过但加速路径证据不足，下一步只补路径核验；若实际存储后端与合同不同，先确认可接受性再安排迁移；若网络只有外部入口失败，就沿端口与防火墙链路复核，不必重装 Docker。验收的目的，是明确这台香港服务器是否达到约定条件，以及剩余风险落在哪个对象上，而不是用一个“部署成功”掩盖尚未验证的环节。