企业官网建设流程全解析

上周刚接手一台需要部署新服务的 CentOS 7 机器，第一件事自然是先把 Docker 环境跑起来。结果yum install docker-ce敲下去，屏幕上直接刷出一大串Could not resolve host: mirrorlist.centos.org，紧接着又是Cannot retrieve repository metadata。这台机器网络是通的，域名解析也没问题，那问题只能出在 yum 源本身。顺着这条线往下查，才发现 CentOS 7 的 yum 源故障已经不是什么偶发问题了，而是一个有明确时间节点、明确迁移路径的系统性变化。

这篇文章我会把从 yum 源故障定位、根因分析，到换源修复，再到 Docker 环境完整搭建的整个过程拆开讲清楚。包括每一步为什么要这样做、有哪些坑、怎么验证，适合正在维护 CentOS 7 机器、或者打算在上面搭 Docker 的运维和开发参考。整个链路走通之后，你还会拿到一套可以抄作业的排查方法和安装命令。

1. 故障现场复盘：一条报错背后藏着两个独立问题

先说当时机器上的真实报错，这对你判断自己的情况很有帮助。执行yum install -y docker-ce后，输出大概长这样：

Loaded plugins: fastestmirror, langpacks Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was 14: curl#6 - "Could not resolve host: mirrorlist.centos.org" One of the configured repositories failed (CentOS-7 - Base),

在往下走之前，我先做了一组最基础的连通性检查，避免被带偏方向：

# 1. 确认本机网络和 DNS 本身没问题 ping -c 3 114.114.114.114 nslookup mirrorlist.centos.org # 2. 直接测试目标源域名是否还能解析、是否还有响应 curl -I --connect-timeout 5 http://mirrorlist.centos.org curl -I --connect-timeout 5 https://vault.centos.org # 3. 看当前系统启用了哪些 yum 源 yum repolist

检查结果很有意思：ping外网正常，DNS 解析mirrorlist.centos.org正常，但curl这个域名超时，完全没有任何有效响应。而vault.centos.org是可以正常访问的。这说明两个关键信息：

• 网络链路本身没问题，问题出在 yum 源所在的服务器已经不再提供 CentOS 7 仓库服务了。
• vault.centos.org这个归档域名是活的，它正是官方用来存放历史版本仓库的地址。

这里要给一个非常重要的判断经验：yum 源报错，永远先区分是"网络层"还是"配置层"的问题。很多人遇到Could not resolve host第一反应就是改 DNS、换网络，其实这一步恰恰会让问题越搞越乱。正确顺序是：先用ping+curl确认网络和 DNS 状态，再用yum repolist确认当前配置指向哪些仓库。当你发现网络完全正常、但仓库域名本身解析/访问不到时，基本就能锁定是源服务器的问题。

当时这台机器上除了CentOS-Base.repo，还有epel.repo、CentOS-Sources.repo等，后几个文件里的源地址同样指向旧域名。所以修复的时候不能只改一个文件，需要把所有仓库定义里的失效地址都换掉。这也是为什么我建议你先把/etc/yum.repos.d/目录整体备份一份再动手，后面操作起来才踏实。

2. 断源的本质：CentOS 7 生命周期结束与仓库迁移机制

CentOS 7 的 yum 源故障，根因很明确：它的生命周期已经结束，官方把仓库从原来的mirrorlist.centos.org地址迁移到了vault.centos.org归档目录。这不是一次性故障，而是永久性的下线动作。

原理解释一下：CentOS 7 在 2024 年 6 月 30 日正式停止维护。停止维护之后，官方不再针对 7 系列提供软件更新和补丁，那么继续保留mirrorlist.centos.org的实时仓库服务就没有意义了。于是官方在迁移时间点之后，把所有 7 系列的历史 RPM 包、元数据都整理到了vault.centos.org下，按照7/os/x86_64/、7/extras/x86_64/这样的目录结构归档存放。同时，原来的mirrorlist.centos.org对 7 的请求不再做任何有效回应，即使能解析出 IP，服务端也不会返回仓库列表数据。

你可以把mirrorlist理解成一个"导购员"：你告诉它"我要 CentOS 7 的 Base 仓库"，它根据你的地理位置和网络，帮你找一个最近的镜像站。而vault更像一个"仓库旧址"：它明确告诉你，这个产品线已经淘汰了，所有东西都堆在这里自取，没有实时同步，也不会再更新。

这里还要顺便提一下：很多人会把这种故障和"国内访问不了官方源"混为一谈，其实是两回事。CentOS 7 EOL 导致的源失效，是官方主动停止服务，是确定性的、永久的。而国内访问官方源慢、超时，属于网络可达性问题。所以当你看到 CentOS 7 的 yum 报错，首先要确认是不是 EOL 迁库导致的。哪怕你在国内，用国内镜像，也得注意镜像站是否同步了"不再提供 CentOS 7 实时仓库"这个事实，改用其centos-vault目录。

那么在修复路径上有两种主流选择：

我在这台机器上选择的是阿里云的centos-vault，原因很简单：服务器在国内，走国内镜像的延迟和稳定性都更可控。如果你的机器在海外，直接切官方vault.centos.org反而更快。选源这件事没有绝对的"最优"，只有结合你实际网络环境的"最合适"。

3. 动手修复：备份、换源、清缓存、验证四步法

修复过程本身不复杂，但每一步都有讲究，尤其"备份"和"验证"这两步，很多人会偷懒跳过，后面大概率会再吃一次亏。

3.1 备份原始仓库配置

这一步的目的不是给你后悔药吃，而是为了排查时能对比到底改了什么。我用一条命令把整个目录打包归档：

mkdir -p /root/yum-repo-backup cp -r /etc/yum.repos.d/* /root/yum-repo-backup/

如果你手头的机器上已经有别人改过的源配置，备份下来的文件就是最好的"案发现场"。比如你可能会发现某些 repo 文件里的baseurl指向了一个早就失效的内网地址，或者 gpgcheck 被改成了 0，这些信息对后面的排查非常有帮助。

3.2 替换仓库地址

这里以CentOS-Base.repo为例。原始文件里的内容指向mirrorlist.centos.org，而mirrorlist机制在 CentOS 7 EOL 后已经不可用，所以要把mirrorlist相关行注释掉，把baseurl改成 vault 路径。修改后核心部分如下：

[base] name=CentOS-7 - Base baseurl=https://mirrors.aliyun.com/centos-vault/7/os/x86_64/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [updates] name=CentOS-7 - Updates baseurl=https://mirrors.aliyun.com/centos-vault/7/updates/x86_64/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [extras] name=CentOS-7 - Extras baseurl=https://mirrors.aliyun.com/centos-vault/7/extras/x86_64/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

你自己操作的时候，CentOS-Sources.repo、CentOS-CR.repo这些文件也看一眼。CR（Continuous Release）仓库在 CentOS 7 里其实早已废弃，直接注释掉或者不管它问题不大。重点是三个常用仓库：base、updates、extras，这三个配好，系统的基本软件安装就已经能正常工作了。

还有一种更省事的方法：直接把/etc/yum.repos.d/下所有.repo文件清空重写。适合配置很脏的机器，但我个人不建议这么做，除非你能确认这台服务器上不需要保留任何内网私有源。否则删掉别人的自定义源，后面装内部软件的时候会特别痛苦。

3.3 清理缓存并重建元数据

改完源之后，必须先清缓存，这一步非常重要。yum 会把仓库的元数据缓存在本地/var/cache/yum/下，如果不清，旧的mirrorlist失效信息会一直残留，轻则报警告，重则直接拒绝新仓库地址。

yum clean all yum makecache

执行makecache的时候，你注意观察输出里的"元数据缓存已建立"以及仓库 ID。如果是base/7/x86_64来自mirrors.aliyun.com/centos-vault，说明换源成功了。这里提一个小概率情况：如果你修改后的 repo 文件里有语法错误，比如baseurl写了两行、或者变量$releasever被滥用，makecache会直接报错，并且指向具体文件和行号，跟着提示改就行。

3.4 验证：不要只看 repolist

很多人验证到yum repolist能列出仓库就收工了，我建议再执行一次真实的软件安装来验证链路完整性。先装一个小工具，比如wget：

yum install -y wget

如果这一步能跑通，说明 GPG 密钥验证、依赖解析、软件包下载整条链路都是健康的。接着再用同样的源去装yum-utils等工具，为后面 Docker 安装做准备。

验证完了别忘了看一眼yum update是否可用。对于已经 EOL 的 CentOS 7，更新内核和基础软件包的收益有限，但如果你是为了修复某个安全漏洞，仍然可以通过 vault 源拿到最后一个版本。装完后uname -a看一眼内核，确认是否如预期变化。

4. 安装 Docker 前必须想清楚的三件事

yum 源修好之后，很多人就迫不及待yum install docker-ce了。但我建议你先停一下，把下面三点想清楚。CentOS 7 毕竟是老系统，直接装最新 Docker 很容易遇到内核不配合、存储驱动报错之类的连锁问题。

4.1 内核版本决定你能用什么存储驱动

CentOS 7 默认内核是 3.10.x。这个版本有个公开的已知问题：对 Docker 推荐的overlay2存储驱动支持不完整，某些文件系统操作会触发 bug，尤其是文件删除后空间不释放、容器层异常增长这类问题。Docker 官方很早就建议在 CentOS 7 上优先使用overlay2，但前提是内核支持d_type检查和稳定的 overlay 模块。

实践中我见过两类处理方式：

• 保守派：继续用 3.10 内核，用devicemapper存储驱动。但devicemapper现在已经被 Docker 官方标记为废弃，性能和稳定性都一般，磁盘占用也高，能不用尽量不用。
• 升级派：通过 ELRepo 仓库升级到长期维护版内核kernel-lt（目前是 4.4 或 5.4 系列），然后放心使用overlay2。

如果你不想一上来就动内核，我给你的操作建议是：先检查当前内核和文件系统是否满足overlay2的使用条件：

# 查看内核版本 uname -r # 检查 /var/lib/docker 所在文件系统是否支持 d_type（xfs 看 ftype 字段） xfs_info /var 2>/dev/null | grep ftype

如果你看到ftype=1，说明 XFS 文件系统支持 d_type，可以跑overlay2。如果是ftype=0，后续格式化分区时得加上-n ftype=1参数重新格式化，或者直接用升级内核那条路。这是很多企业机器踩过坑的地方：df -hT一看是 XFS 就以为没问题，结果容器层疯狂报错，最后发现是ftype没开。

4.2 依赖组件和 SELinux 的交互

yum 安装 Docker CE 时会自动拉取containerd.io、docker-ce-cli、docker-buildx-plugin等依赖。CentOS 7 上这些包偶尔会和系统自带的旧版本容器相关包冲突，比如你之前手动装过老版本的docker、docker-client，yum 会报package docker-ce conflicts with docker。遇到这种问题，先yum remove docker docker-client docker-common把旧的清干净再装。

另外就是 SELinux。CentOS 7 默认 SELinux 是enforcing模式，Docker 官方仓库里的docker-ce包在安装时会自动处理 SELinux 策略（会拉container-selinux），所以一般不需要关闭。如果你发现启动不了，先用getenforce看状态，再查/var/log/audit/audit.log里有没有avc: denied的记录。直接setenforce 0是治标不治本，生产环境不建议一关了之。

4.3 选稳定大版本还是最新版

Docker CE 的版本演进很快，但对 CentOS 7 的支持力度是逐步收窄的。最新大版本往往对内核和 systemd 有更苛刻的要求。所以我的建议是：别追最新，选一个稳定的中段版本锁死。比如我在这台机器上选的是docker-ce-24.0.x系列，不仅对 CentOS 7 兼容性好，和老的 docker-compose 配置兼容度也高。

你可以在安装时显式指定完整版本号，避免 yum 拉到最后更新的版本：

yum list docker-ce --showduplicates | sort -r

看到可用的版本列表后，执行：

yum install -y docker-ce-24.0.9 docker-ce-cli-24.0.9 containerd.io

这么做的另一个好处是可控：万一新版本引入的问题影响了现有服务，你在排障时能明确知道所有组件的版本，不会出现"昨天还能跑，今天全挂了"这种玄学问题。

5. Docker CE 安装的实际操作：repo 配置、依赖安装与启动管理

现在源是好的，前置条件也梳理清楚了，可以正式装 Docker。下面是我在这台 CentOS 7 上完整跑通的命令，每一步后面都说明了为什么这么做。

5.1 添加 Docker 官方仓库

用 yum-utils 自带的yum-config-manager来添加仓库是最标准的做法：

yum install -y yum-utils device-mapper-persistent-data lvm2 yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

这里注意一点：如果你直接访问download.docker.com很慢，可以把仓库地址换成国内镜像站的 docker-ce repo。例如阿里云：

yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

执行完--add-repo之后，建议用sed把 repo 里的download.docker.com全部替换成镜像地址，这样后续 yum 下载 rpm 包时都走国内镜像：

sed -i 's|download.docker.com|mirrors.aliyun.com/docker-ce|g' /etc/yum.repos.d/docker-ce.repo

替换完看一眼 repo 文件确认无误，然后yum makecache再yum repolist，确认docker-ce-stable已经出现。

5.2 安装 Docker 核心组件

这里我直接指定了版本号，避免装到当时最新但兼容性未知的版本：

yum install -y docker-ce-24.0.9 docker-ce-cli-24.0.9 containerd.io

安装完成后，先别急着systemctl start docker。先看两个地方：containerd是否正常、docker命令是否已经就位：

systemctl status containerd docker version

docker version此时可能报Cannot connect to the Docker daemon，这是正常的，因为服务还没起来。关键是确认 Client 端版本是 24.0.9，以及 Server 端还没有连接信息。

5.3 配置 daemon.json 并启动

启动前我建议先写一个/etc/docker/daemon.json。这一步不是必需的，但很实用。至少可以配置两件事：Docker 数据目录和镜像加速。

如果你的/var分区空间不大，而/data是独立的大磁盘，就要把 Docker 的数据目录挪过去：

{ "data-root": "/data/docker", "exec-opts": ["native.cgroupdriver=systemd"], "storage-driver": "overlay2" }

然后启动并设置开机自启：

systemctl start docker systemctl enable docker systemctl status docker

看到Active: active (running)说明服务起来了。如果状态是failed，先journalctl -u docker --no-pager -n 50看日志，这一步能定位 90% 的问题。常见原因无非是daemon.json语法错误、>groupadd docker usermod -aG docker your_username newgrp docker

这里要注意一个细节：newgrp docker只对当前终端会话生效。你重新登录服务器之后，组关系才会完全刷新。如果加入组后依然报permission denied while trying to connect to the Docker daemon socket，极大概率是当前会话没有重新加载组关系，注销重登就好。

6. 踩坑清单：docker 启动失败与 hello-world 拉不下来的常见原因

到了这一步，理论上你的 Docker 已经能用了。但我在多台机器上实际部署的过程中，几乎每次都会遇到至少一两个下面的坑。我把它们按出现频率排个序，附带快速验证命令，方便你对照排查。

6.1 容器启动报错或 Docker 服务反复崩溃

服务能起来，但一启动容器就报Error response from daemon,常见原因集中在存储驱动和 cgroup 上。先说 cgroup：CentOS 7 默认 systemd 管理 cgroup，所以daemon.json里我特别加了"exec-opts": ["native.cgroupdriver=systemd"]。如果你没加，容器运行久了可能出现"内存 cgroup 不释放"等诡异问题。

再说存储驱动。如果你用overlay2但容器启动时大量报failed to mount overlay，优先检查两处：

# 内核模块有没有加载 lsmod | grep overlay # 文件系统是否开启 d_type，again xfs_info /data 2>/dev/null | grep ftype

如果模块没有加载，modprobe overlay先加载再说。如果ftype=0，要么换文件系统，要么先退回vfs驱动应急，生产环境建议直接升级内核。

6.2 拉取镜像超时或无法解析镜像仓库域名

docker pull hello-world如果卡死在Head https://registry-1.docker.io/...，大概率是网络问题。国内服务器访问 Docker Hub 官方仓库经常不稳定，解决办法是配置镜像加速器。修改/etc/docker/daemon.json：

{ "registry-mirrors": [ "https://docker.m.daocloud.io" ] }

改完重启 Docker：

systemctl daemon-reload systemctl restart docker

然后重新docker pull hello-world。如果你公司内部有自建的 Harbor 或其它镜像仓库，也可以把它加到这个数组里，优先级按数组顺序排列。

6.3 请求被拒绝：Permission denied

报错信息通常长这样：

docker: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

出现这个，先确认当前用户是不是在docker组里：

groups your_username id your_username

如果已经在新组里，执行newgrp docker或重新登录一次，然后再试docker ps。

这里我多说一句：把普通用户加进docker组，其实相当于把 root 权限拱手相让。Docker 守护进程默认以 root 身份运行，能操作 Docker 的用户基本都能间接拿到 root 权限。所以在生产环境，这个组里最好只放信任的运维人员，别图省事把一堆业务账号都扔进去。

6.4 iptables / 网络转发导致的容器互通问题

容器之间网络通，但容器访问外网不通，或者宿主机和容器互相 ping 不通。优先检查内核的 IP 转发和 iptables 规则。CentOS 7 上 Docker 默认会操作 iptables 的FORWARD链。当你装了 firewalld，或者有别的程序在管理 iptables，很容易出现规则冲突。

快速验证和修复：

# 检查内核转发 sysctl net.ipv4.ip_forward # 临时打开，生产环境建议写进 /etc/sysctl.conf echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf sysctl -p # 重启 docker 让 iptables 规则重新生成 systemctl restart docker

如果你遇到的是 firewalld 和 Docker 的端口映射互相干扰，最简单的思路是先确认 firewalld 是否在运行：systemctl status firewalld。如果业务上没有强依赖，我一般建议保留 firewalld，然后让 Docker 管理自己的规则，不要两边同时去操作同一条链，否则会出现"端口映射不生效"这类非常隐蔽的问题。

实际测试下来，上面这套从 yum 源修复到 Docker 环境跑通的流程，耗时大约在 15 到 20 分钟。最耗时的环节通常不是安装，而是我在daemon.json和内核参数上反复确认的过程。在这台 CentOS 7 上最终跑通后，docker run hello-world一次通过，docker info里的 Storage Driver 显示为overlay2，Cgroup Driver 显示为systemd。这个组合是 CentOS 7 上我目前最推荐的稳定形态。

如果你手头的机器也出现类似 yum 源报错，别急着重装系统或者频繁修改 DNS。先把仓库地址切到 vault，验证能正常安装基础软件，再考虑 Docker 环境。很多时候，看似无解的服务器故障，根源只是仓库地址变了。把这套流程走一遍，你基本也能成为团队里专门负责"救火"的那个人。