★ FEATURED ARTICLE 搞服务器的人估计都遇到过这种场景一台全新的 CentOS 7.9 装好进系统第一件事不是装环境而是先敲一句yum update结果看着进度条在那几KB几KB地跳心里那个急。官方源在国内的访问速度就是不给力这不怪机器怪网络路径太长。把 yum 源换成阿里云 repo 源是最常见也最有效的提速手段一台服务器几分钟就能改完。这篇文章就把我从第一次换源到现在踩过的坑、总结的经验捋一遍内容包括为什么换、怎么备份、怎么配置、怎么验证、以及换完以后遇到报错怎么排查。不管是刚入行的运维还是需要批量初始化服务器的同学照着做基本都能一次搞定。1. 换源这件事CentOS 7.9 绕不过去1.1 官方源慢在哪CentOS 7.9 默认的 yum 源指向的是官方镜像站这些镜像服务器大多部署在海外。国内服务器访问的时候数据要跨越大洋经过一层层骨干网络转发延迟高、带宽小高峰期还经常丢包。实际体验就是执行yum install的时候前面的依赖分析很快一到下载 RPM 包的环节就原形毕露经常一个 20MB 的包要下载好几分钟有时候直接卡住不动最后报一个超时错误。这种情况在服务器刚初始化、需要安装大量基础软件包的时候尤其明显。比如要装一个 LNMP 环境需要拉取 nginx、PHP、MySQL 以及它们的一大堆依赖如果顶着官方源硬下半小时能装完都算运气好。用生活里的话说就是从国外超市买东西快递费贵不说路上还慢国内有现成的分仓送货当然快。yum 换源本质就是把这个“收货地址”改到离自己更近的国内节点上。1.2 阿里云镜像源为什么是首选国内做 yum 镜像的服务商不少但阿里云镜像站mirrors.aliyun.com在综合体验上很能打。首先是节点多阿里云在全国有大量 CDN 和地域节点服务器能自动就近匹配下载速度通常能跑到带宽上限其次是同步频率高官方仓库更新后镜像站很快就能同步完成不会出现“官方有新版、镜像还停留在旧版”的尴尬第三是免费不需要注册账号也不需要配任何认证信息拿到 URL 直接就能用。阿里云镜像站不仅提供 CentOS 的基础仓库还包含 EPEL、docker-ce、remi 等一系列常见扩展源。这意味着不光是基础 yum 能换后面装 Docker、装新版 PHP 的时候同样可以走国内加速通道一套思路打通所有场景。1.3 什么情况下最需要换源我实际工作中遇到需要换源的情况基本是以下三类一类是全新服务器初始化。刚交付的 CentOS 7.9 机器第一件事肯定是 update 系统、装常用工具不换源的话这第一步就劝退不少人。第二类是批量部署环境比如同时开十几台机器做集群如果每台机器都从官方源慢慢拉包整个交付周期会被严重拖慢换源后配合脚本十几台机器可以并行初始化效率完全不是一个级别。第三类是容器基础镜像构建用 CentOS 7.9 做基础镜像时Dockerfile 里的yum install同样走系统 repo 配置镜像站拉取速度快了镜像构建时间能缩短一大截。2. 动源之前先把手上的东西看清楚2.1 确认系统版本和架构换源之前先确认系统是不是 CentOS 7.9以及 CPU 是什么架构。别小看这一步我见过有人在 CentOS 6 的机器上直接套用 7 的 repo 文件结果一堆依赖版本对不上装什么都不顺。先跑一下命令cat /etc/redhat-release uname -m第一条命令会输出类似CentOS Linux release 7.9.2009 (Core)看到 7.9 就没问题了。第二条命令输出x86_64表示 64 位 x86 架构如果是在 ARM 云服务器上会输出aarch64。仓库 URL 里的$basearch变量会自动展开成对应的架构名x86_64 就访问 x86_64 目录aarch64 就访问 aarch64 目录所以只要系统的架构识别正常换源时不用刻意改架构路径。2.2 检查当前yum状态顺便把老源备份了先看一眼当前 yum 源的状态yum list | head -20如果命令能正常返回结果说明现有源还能响应如果卡了很久或者直接超时那就更说明换源的必要性。接着列出 repo 目录下都有哪些文件ls -l /etc/yum.repos.d/正常情况下能看到 CentOS-Base.repo、CentOS-CR.repo、CentOS-Debuginfo.repo、CentOS-Sources.repo 等一堆文件。注意yum 只读取以.repo结尾的文件所以备份的时候把它改成.bak后缀yum 就会自动忽略不需要移到别的目录。备份这一步我强烈建议做哪怕你已经知道怎么配置了也养成习惯。实际操作中配置源出问题想回滚如果没有备份只能靠记忆把原来的内容重写一遍万一记错一个 URL 就是给自己挖坑。执行下面的命令mkdir -p /root/yum-backup cp /etc/yum.repos.d/*.repo /root/yum-backup/备份完成后再动手心里就踏实多了。之后不管配置成什么样一条命令就能回到初始状态。2.3 理解repo文件的结构你才敢改它备份只是第一步要真正弄明白自己在干什么还得看懂 repo 文件本身。拿默认的 CentOS-Base.repo 来说核心内容长这样[base] nameCentOS-$releasever - Base mirrorlisthttp://mirrorlist.centos.org/?release$releaseverarch$basearchrepoosinfra$infra baseurlhttp://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7方括号里的是仓库 ID必须唯一重复的话 yum 会报错或者互相覆盖。name只是给人看的描述信息。mirrorlist是一个动态返回可用镜像列表的接口会按地理或网络情况挑一个镜像baseurl则是直接指向一个固定的仓库地址。国内网络环境下mirrorlist返回的境外镜像地址反而更慢所以换阿里源的时候通常直接指定baseurl指向阿里镜像即可不再走 mirrorlist 逻辑。gpgcheck1表示开启 GPG 密钥校验防止 RPM 包被篡改gpgkey是指定密钥文件路径。后面我们下载阿里官方的 repo 文件这些字段会自动配好不需要自己手写。3. CentOS 7.9 换阿里源的具体操作步骤3.1 最稳妥的方式直接下载阿里官方repo文件阿里云镜像站维护者已经替我们把 CentOS 7 的 repo 文件写好了不需要自己手动改一堆字段。直接用 curl 下载覆盖本地的 CentOS-Base.repo 就行curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo注意这里用的是-o小写后面要跟着目标文件的完整路径。有些教程会用-O大写那是让 curl 自动取 URL 末尾的文件名保存不指定路径实际会存成当前目录下的Centos-7.repo这样你还是得手动把它复制到/etc/yum.repos.d/里多一步操作没必要。下载完成后cat 一下文件内容确认没问题cat /etc/yum.repos.d/CentOS-Base.repo看到baseurlhttp://mirrors.aliyun.com/centos/$releasever/os/$basearch/这样的地址就说明文件已经替换成功了。3.2 看懂并调整repo文件里的关键项阿里给的 Centos-7.repo 内容不复杂核心就是几个仓库段。我这里截取关键片段做一个说明[base] nameCentOS-$releasever - Base baseurlhttp://mirrors.aliyun.com/centos/$releasever/os/$basearch/ gpgcheck1 gpgkeyhttp://mirrors.aliyun.com/centos/RPM-GPG-KEY-CentOS-7这里面的$releasever是 yum 内置变量做系统发行版的版本号CentOS 7 上会展开为7。$basearch对应硬件架构就是刚才uname -m看到的x86_64。也就是说最终访问的地址实际上是http://mirrors.aliyun.com/centos/7/os/x86_64/。有几个点要提醒一下。第一如果你下载到的文件里没有fasttrack或centosplus这些仓库段也不用担心那些属于可选仓库默认不启用不影响日常使用。第二如果企业内部要求必须走 HTTPS可以把 URL 里的http://改成https://阿里镜像站支持 HTTPS 访问。但对于老机器来说HTTP 反而省事少一条证书链校验的路径绝大多数场景不需要强上 HTTPS。3.3 清缓存、建缓存让新源生效repo 文件已经换成阿里源了但这会儿还不能直接说配置完成。因为 yum 本地缓存里还存着旧源的 metadata 数据如果不清理yum 很可能还用缓存里的旧地址去下载甚至报错。按顺序执行下面两条命令yum clean all yum makecacheyum clean all会把/var/cache/yum/下的包缓存和 metadata 缓存全部清掉。yum makecache会根据当前 enable 状态的仓库重新下载各自的 repomd.xml 和文件列表。这个过程能直观感受到换源的差别用官方源的时候makecache 可能要等好几分钟屏幕上一直停留在一行 loading 的状态换成阿里源后通常几十秒甚至十几秒就全部完成了。如果 makecache 过程异常卡住先别急着 CtrlC可以等个一两分钟看是否完成。阿里源虽然快但首次下载全部仓库的元数据也需要一点时间。如果一直卡着不动参考后面第 5 章的排查思路。3.4 验证换源结果不只是看repolist换完源、建完缓存之后一定要验证。最简单的检查是yum repolist正常输出会看到类似下面的结果repo id repo name status base/7/x86_64 CentOS-7 - Base 10,097 extras/7/x86_64 CentOS-7 - Extras 515 updates/7/x86_64 CentOS-7 - Updates 2,315看到 base、extras、updates 这些仓库处于启用状态就说明 repo 文件本身没问题。但这只能证明“仓库可用”不代表“实际下载速度真的快”。我习惯再做一次实际安装测试yum -y install tree装完之后再看一眼终端输出会发现下载阶段的速度显示为几十 MB/s 甚至更高这时候才算是真正换源成功。还可以顺手确认一下 yum 是从哪个地址拉包的加上 verbose 参数可以看得更清楚yum -v repolist在输出里能看到每个仓库的 baseurl确认是 mirrors.aliyun.com 开头就妥了。4. EPEL源和其他常用扩展源4.1 EPEL源怎么配才干净EPEL 是一个由 Fedora 社区维护的扩展软件仓库里面的软件包覆盖面很广很多 CentOS 基础源里没有的软件都能在这里找到比如 htop、jq、python3-pip 这些常用工具。CentOS 7.9 默认不带 EPEL需要手动安装。配 EPEL 有两种常见思路我推荐第一种。第一种是直接下载阿里提供的 epel repo 文件curl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo下载完同样执行yum clean all和yum makecache然后yum repolist应该能看到epel仓库。第二种是先安装官方 epel-release 包再把源切到阿里yum -y install epel-release mv /etc/yum.repos.d/epel.repo /etc/yum.repos.d/epel.repo.bak mv /etc/yum.repos.d/epel-testing.repo /etc/yum.repos.d/epel-testing.repo.bak curl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo这套操作的问题在于先装官方 epel-release 的时候yum 会从官方源拉包如果官方源慢这一步就先卡住了。所以能直接下载阿里 repo 文件的情况就不要再绕圈子了。当然如果你的机器已经能像中国移动宽带一样飞快访问官方源那第二种方法也无所谓只是没必要。4.2 其他常用镜像源remi、docker-ce、软件源优先级除了 EPEL实际工作中我会按需添加另外几个源。remi 源主要提供各种新版本的 PHP、Redis 客户端等软件包。CentOS 7.9 自带的 PHP 版本停留在 5.4老得不能忍但通过 remi 源可以装到 PHP 5.6 到 8.x 的任意版本。remi 的阿里镜像配置类似[remi] nameRemis RPM repository for Enterprise Linux 7 - $basearch baseurlhttp://mirrors.aliyun.com/remi/enterprise/7/remi/$basearch/ enabled1 gpgcheck1 gpgkeyhttp://mirrors.aliyun.com/remi/RPM-GPG-KEY-remidocker-ce 源则是给 docker 安装用的阿里同样有镜像curl -o /etc/yum.repos.d/docker-ce.repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo这里必须提醒一句扩展源不是越多越好。源太多意味着同一个软件包可能出现在多个仓库里版本还不一样yum 解析依赖时可能做出让你意外的选择。比如在默认 base 源和 EPEL 源同时存在时某些包的版本优先级是需要谨慎对待的。如果需要精确控制可以装一个yum-plugin-priorities插件yum -y install yum-plugin-priorities然后在 repo 文件里给不同的仓库加上priorityN字段数字越小优先级越高。比如 base 源设priority1epel 源设priority2这样同一个包会优先从 base 源安装避免版本冲突。不过对大多数场景来说只要不叠加太多源这个插件不装也行。5. 换源后常见的坑和我怎么排查的5.1 repomd.xml 获取失败换源后最经典的报错长这样Cannot retrieve repository metadata (repomd.xml) for repository: base. Please verify its path and try again这个报错信息直译是“获取仓库的 repomd.xml 失败”但实际原因有好几种。我先按照下面的顺序排查curl -I http://mirrors.aliyun.com/centos/7/os/x86_64/repodata/repomd.xml这条命令能直接测试仓库元数据地址通不通。如果返回200 OK说明网络没问题问题出在 repo 文件本身回去检查baseurl是不是写错了。如果超时或者显示404那要先确认你引用的路径在阿里镜像站上是否真实存在。之前就遇到过一种情况有人顺手把 CentOS 8 的 repo 地址复制到 7 的机器上URL 里显示的是8-stream那当然拉不到元数据。另外还要检查/etc/yum.repos.d/目录下是否有残留的第三方 repo 文件比如某些云厂商自带的源文件它们可能引用了已经失效的地址。把非阿里源的文件都改成.bak后缀只保留必要文件再试一次。5.2 DNS 解析问题还有一类报错和元数据无关而是解析不了镜像站域名Could not resolve host: mirrors.aliyun.com这种问题之前在新开的服务器上遇到过几次大多是/etc/resolv.conf里没有配置有效的 DNS 服务器。排查命令很简单cat /etc/resolv.conf ping -c 4 mirrors.aliyun.com如果 ping 直接提示 unknown host说明 DNS 有路不通。可以把 DNS 临时改成公共 DNS 测试echo nameserver 223.5.5.5 /etc/resolv.conf223.5.5.5是阿里云的公共 DNS 地址在国内网络环境下解析速度和稳定性都不错。确认 DNS 恢复后再回头执行yum makecache。当然如果这台服务器所在的内网要求用内网 DNS修改完后记得把配置改回去别让 DNS 配置和公司规范打架。5.3 缓存数据库损坏有的机器在换源前多次yum install中途中断旧缓存已经处于半损坏状态。换源之后yum makecache可能报rpmdb: Thread failed in dbenv-txn_begin这是/var/lib/rpm/目录下的数据库缓存文件出了问题。处理办法是把缓存数据库文件删掉让 rpm 重新生成rm -f /var/lib/rpm/__db.00* rpm --rebuilddb然后重新执行yum clean all yum makecache这里不会丢安装记录删除的只是临时索引文件下次 yum 操作时会自动重建。如果你在云服务器上操作建议先确认没有其他 yum 进程在跑否则并发访问 rpm 数据库可能造成新的损坏。5.4 证书过期导致 HTTPS 拉取失败如果你把 baseurl 里的http改成了https某些老机器的 CA 证书链可能已经过期导致 curl 报证书错误Peers Certificate issuer is not recognized最省事的办法是把这些老机器的 yum 源统一改回 HTTP 地址。阿里镜像站同时提供 HTTP 和 HTTPSRPM 包本身带 GPG 签名校验走 HTTP 不会引入安全性问题。如果企业安全规范强制要求 HTTPS那就先更新证书库yum -y install ca-certificates装完再重新执行yum makecache。这个问题在 2020 年左右出厂、长期没更新过的 CentOS 7 机器上尤其常见。5.5 别忽略的细节repo文件残留与 $releasever最后说两个我栽过跟头的细节。一个是 repo 文件的残留。之前备份旧源的时候我在/etc/yum.repos.d/下用cp直接把原文件复制成了.bak但目录里还留着其他以.repo结尾的旧文件结果 yum 同时读到了新旧两个 base 仓库定义虽然不报错但repolist里出现了两条 base非常容易混淆实际生效的源。所以换源前最好统一操作把目录里所有非阿里源文件后缀改成.bak再放入新的 repo 文件。另一个是$releasever的意外展开。如果你在 repo 文件里手写了硬编码的7而不是用$releasever在 CentOS 7.9 上通常没问题。但一旦系统里存在/etc/yum/vars/releasever这个自定义变量文件yum 就会用里面的值替换$releasever导致 URL 变成/centos/8/...或者/centos/6/...然后就是各种 404。遇到这种诡异问题去/etc/yum/vars/里看看有没有这种自定义变量文件能看到就直接删掉。下面是常见问题速查方便以后直接对照现象可能原因处理动作repomd.xml 无法获取baseurl 写错、路径不存在、第三方源残留检查 URL、备份非阿里源文件Could not resolve hostDNS 配置异常检查 /etc/resolv.conf临时用公共 DNS 测试rpmdb: Thread failedrpm 数据库缓存损坏删除 __db.* 并执行 rpm --rebuilddb证书报错CA 证书过期切换 HTTP 或更新 ca-certificatesrepolist 出现重复仓库repo 文件残留统一将所有旧文件改为 .bak 后缀404 路径不存在releasever 变量被覆盖检查 /etc/yum/vars/ 下是否有 releasever 文件6. 换个源还有哪些地方可以顺手优化6.1 把换源过程固化成初始化脚本配置一次源只需要手动敲几条命令但如果给几十台机器初始化每台都手动敲一遍就太浪费时间了。我习惯把换源操作写成脚本放到公司内部的初始化工具里新机器交付的时候自动执行。脚本本身不长核心逻辑就是把备份、下载、清缓存、建缓存串起来#!/bin/bash # CentOS 7.9 一键换阿里源并初始化缓存 set -e echo 1. 备份原有 repo 文件 mkdir -p /root/yum-backup cp /etc/yum.repos.d/*.repo /root/yum-backup/ 2/dev/null || true echo 2. 下载阿里云 CentOS 7 repo 文件 curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo echo 3. 下载阿里云 EPEL repo 文件 curl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo echo 4. 清理 yum 缓存 yum clean all echo 5. 重建缓存 yum makecache echo 6. 确认仓库列表 yum repolist这里有几个细节。脚本里用了set -e意味着任何一条命令返回非零状态就立刻退出好处是不会在当前源出问题时继续往下跑避免二次破坏。备份那一步加了|| true是防止目录里没有.repo文件时 cp 直接让脚本退出新机器场景下这步要兼容。第 3 步下载 EPEL 源是可选的如果不需要 EPEL整行删掉就行不影响其他逻辑。如果你管理的机器网络环境比较特殊比如只有公司内网能访问外网那脚本里的 URL 可以统一换成一个镜像同步机器上的地址思路完全一样。6.2 内网环境也可以自建yum源阿里源作为公共镜像毕竟还是外网资源。有些内网环境对出网要求很严或者机器数量特别多每台都去外网拉包不现实。这种情况下我一般会在内网找一台跳板机或网关机器配好阿里源后用磁盘空间做一个小型 yum 镜像同步然后让其他机器指向它。实现方式不复杂。一台机器上装好 nginx 或者直接跑一个静态文件服务然后定期用 rsync 把阿里镜像里所需的目录同步到本地rsync -avz --delete rsync://mirrors.aliyun.com/centos/7/os/x86_64/ /data/mirrors/centos/7/os/x86_64/其他机器只需要把 repo 文件里的 baseurl 改成内网这台机器的地址比如http://192.168.0.10/centos/7/os/x86_64/。这样做的好处是内网机器访问延迟极低下载速度基本达到内网带宽上限外网中断也不影响包安装。缺点是需要维护同步任务如果内网机器只有十来台直接用阿里外网源问题不大但如果到了几十上百台自建同步源的投资回报率就很高了。我在实际环境里还有一种更轻量的做法只同步安装频率最高、体积最大的基础包目录比如 os、updates、extras其余冷门包继续走阿里外网。这种“分层源”的思路对带宽成本控制帮助不小不过不适合所有团队按实际情况取舍即可。最后再聊一点个人体会。换源这件事看起来只是几行命令的事但真正拉开运维差距的地方在于你会不会事先备份、懂不懂看 repo 文件结构、遇到报错能不能快速定位。阿里源和官方源之间的切换成本很低低到你完全可以反复实验踩过几次坑之后你对 yum 的工作机制反而会有更深的体感。我到现在给新机器配源依然会先看版本再动手不是不熟练而是这种“稳”的习惯在运维里比“快”值钱得多。
阅读完成 · 觉得有帮助？
