1. 项目概述与前期决策“部署 DNF 仓库及 NFS 共享服务”这个题目的分量做过 Linux 运维的人一眼就能掂出来。它不只是一个软件安装过程而是内网服务器管理的基础设施工程。DNF 仓库解决的是“软件从哪来、怎么统一分发”的问题NFS 共享解决的是“数据怎么在多台机器之间透明流动”的问题。两者搭配起来基本就是一套小型 IDC 或实验室服务器集群的雏形。我这次落地这套环境背景很直接某项目组内部有十几台 CentOS 服务器之前每台机器各自联网用默认源装软件。看似没什么大问题但实际运维的痛点非常明显——外网带宽不稳定、包版本五花八门、新机器装机要等半天、内网环境又要求离线交付。于是决定自建一套内网 DNF 仓库把常用 RPM 包全部同步到本地再用 NFS 把仓库目录共享给所有内网机器使用。先说结论这套方案跑通后新服务器从裸机到能装任意软件包时间从小时级压缩到分钟级而且全程不依赖外网。下面我把整个部署过程、原理、踩坑点全部拆开讲。1.1 核心需求拆解做任何项目之前先别急着敲命令把需求拆清楚。这个项目表面是两个服务实际拆开看是四层需求第一层包管理源统一化。内网所有机器必须能通过 DNF 安装软件并且包来源必须是受控的内部源不能偷偷从外网拉取更不能出现同一软件在不同机器上版本不一致的情况。第二层离线可运行。机房环境常有断网或隔离要求全部走内网自建源可以保证服务在完全离线状态下正常交付不受外网抖动影响。第三层存储共享透明化。仓库目录如果只是放在某一台服务器本地其他机器要么手动拷贝要么各自维护一份非常低效。通过 NFS 导出仓库目录所有客户端直接 mount 到本地路径对应用程序来说就是本地文件透明访问。第四层后续可扩展。今天的仓库可能只同步 CentOS 基础源明天可能要加 EPEL、Docker 源、Python 本地源、Nginx 源等等。目录结构和共享方式必须从一开始就考虑到扩展性不能做成一锤子买卖。这四层需求决定了后面所有技术选型。比如仓库服务器我选了单独一台磁盘较大的机器来做而不是在已有业务机器上凑合NFS 版本选 4.x 而不是 3.x原因后面详细讲同步工具选 reposync 而不是直接 rsync 整个镜像站也是因为性能和灵活性上的考虑。1.2 为什么“DNF NFS”是这需求的最优组合有同事问过我既然 DNF 本身支持远程仓库直接在每台机器的 repo 文件里写http://服务器路径不就行了为什么还要多此一举做 NFS 共享这个问题问得好。单纯用 HTTP 协议确实可以访问远程仓库但 NFS 方案在特定场景下明显更优尤其是在内网集群里一是仓库目录复用的灵活性。用 HTTP 只能让机器通过固定 URL 拉包但有时候我们需要直接在服务器上操作仓库里的文件比如临时拷贝某个 RPM 出来手动安装、查看依赖关系、或者把自定义的离线包目录直接挂进来。NFS 把整个仓库变成一块“网络硬盘”所有读操作就像在本地文件系统上进行一样自然。二是权限模型更贴近本地使用习惯。NFS 通过 export 配置可以精确控制只读、只写、root squash 等权限配合客户端 IP 网段限制比 HTTP 服务还要好控制。三是性能开销可控。DNF 拉包时本质上是在读文件走 NFS 和走本地磁盘在吞吐上没有明显差距尤其是在千兆内网环境下。而且 NFS 对大量小文件的读取做了缓存优化RPM 仓库这种海量小文件的场景恰恰是它的强项。当然如果你只有三五台机器直接用 nginx 或者 python3 -m http.server 提供一个 HTTP 源就够了没必要上 NFS。但当客户端数量上来或者需要维护多个仓库目录、多个发行版版本时NFS 这套集中式共享方案的管理成本会明显更低。2. 环境准备与仓库服务器选型2.1 硬件与系统规划仓库服务器我用了项目组里的一台闲置物理机配置不高的那种双核 CPU、8GB 内存、两块 1TB 机械盘做 RAID1。跑仓库服务完全够用真正需要注意的只有磁盘容量。我做过一个比较保守的容量估算CentOS 7 的 Base 源大约 4GBPlus 源约 1GBExtras 源约 500MBEPEL 源大约 7GB再加上 Updates 增量不算镜像站的话整体占用大概在 20GB 左右。如果后续还要同步 AppStream、PowerTools 或者其他第三方源按每个源 5~10GB 往上加。所以我建议数据盘至少 100GB 起步有条件直接上 500GB给未来留足余量。系统版本这块需要特别注意兼容性。仓库服务器和客户端最好保持一致的大版本。比如我这边所有机器都是 CentOS 8或 Rocky Linux 8那么仓库服务器也用同版本系统这样 reposync 出来的 RPM 包才能被客户端正确识别。想从一个统一平台同时给 CentOS 7 和 8 提供源目录结构要分区规划不是不能做但初期不建议搞这么复杂先把单一版本跑通畅再说。2.2 软件包清单少装很多不必要的依赖仓库服务器上需要装的软件很少但每一项都别漏createrepo_c用于生成 RPM 仓库的元数据索引repodata目录下的文件。这是 DNF 客户端识别仓库的关键没有它客户端根本不知道目录里有什么包。dnf-utils提供reposync和dnf reposync等命令用来把远程仓库的 RPM 包批量同步到本地目录。nfs-utils提供 NFS 服务的核心程序包括exportfs、mount.nfs等。rsync备用同步工具后面讲增量同步时会用到。一个容易忽略的点在 Rocky Linux 8 / CentOS 8 上reposync相关的包组依赖可能比较多。我建议别用最小化安装直接dnf install createrepo_c dnf-utils nfs-utils rsync一下搞定实测不会引入一堆无关服务比你缺一个子命令再回头补装要省心。安装命令如下当前系统是 Rocky Linux 8dnf install -y createrepo_c dnf-utils nfs-utils rsync装好之后确认一下版本rpm -qa | grep -E createrepo_c|dnf-utils|nfs-utils|rsync个人比较建议把createrepo_c和dnf-utils的版本信息在笔记里记一笔后面排障时用得上。3. 核心细节解析与仓库搭建实操过程3.1 仓库目录结构设计目录规划是整个仓库系统里最值得花心思的地方。我最终采用的方案是这样的/opt/repo/ ├── centos8/ │ ├── baseos/ │ ├── appstream/ │ ├── epel/ │ └── extras/ ├── custom/ │ └── local-rpms/ └── scripts/ ├── sync-repo.sh └── create-repo.sh把这个结构重点说一下。/opt/repo是仓库根目录下面按发行版和源名称分开。centos8/baseos、centos8/appstream对应 CentOS 8 的官方仓库分类这是 Rocky/Alma/CentOS 8 系列特有的拆分方式和 CentOS 7 时期把一切塞进base完全不一个逻辑。custom/local-rpms用来放项目组自己打的 RPM 包比如内部封装的 Java 环境、数据库配置文件等等。这么设计的用意很明确基础源和自定义源必须严格分离。基础源是自动同步的任何时刻都可能被更新覆盖自定义源是手工维护的绝对不能被同步脚本误删或覆盖。二者如果混在同一个目录某次手滑全盘清理时损失不可估量。3.2 reposync 同步与 createrepo_c 建索引核心同步逻辑我用一个脚本管理内容如下#!/bin/bash # sync-repo.sh 定时同步 CentOS 8 / EPEL 仓库 set -euo pipefail REPO_ROOT/opt/repo/centos8 LOG_FILE/var/log/repo-sync.log log() { echo $(date %Y-%m-%d %H:%M:%S) $* $LOG_FILE } sync_repo() { local repo_name$1 local local_path$2 local repo_file$3 mkdir -p $local_path log 开始同步仓库: $repo_name dnf reposync \ --repoid$repo_name \ --download-path$local_path \ --download-metadata \ --newest-only \ --delete \ --releasever8 if [ $? -eq 0 ]; then createrepo_c --update $local_path log 仓库同步完成: $repo_name else log 仓库同步失败: $repo_name return 1 fi } sync_repo baseos $REPO_ROOT/baseos /etc/yum.repos.d/CentOS-Base.repo sync_repo appstream $REPO_ROOT/appstream /etc/yum.repos.d/CentOS-Base.repo sync_repo extras $REPO_ROOT/extras /etc/yum.repos.d/CentOS-Base.repo sync_repo epel $REPO_ROOT/epel /etc/yum.repos.d/epel.repo这个脚本有几个关键点值得展开讲。第一--newest-only参数。它的含义是只同步每个软件包的最新版本不同步历史版本。这样仓库体积会小很多而且客户端永远只会看到最新版避免了多版本共存时的依赖选择问题。代价是如果你需要做版本回退仓库里没有旧版可用。对于一般的内网生产环境--newest-only是合理的默认选择。第二--delete参数。它会在同步时删除远端已经下架的包。刚开始用的时候你会觉得这个参数危险但它其实是保证仓库清爽的关键。如果没有--delete本地仓库会慢慢积累大量已经废弃的 RPM 文件元数据越来越大客户端解析速度越来越慢。第三--download-metadata。同步时把远程的元数据一起拉下来这样可以在同步完后直接用createrepo_c基于现有元数据做增量更新比从零扫描全量文件快得多。实测下来对一个 5GB 左右的仓库做增量更新耗时从十几分钟降到十几秒。第四关于--releasever8。这个参数我强烈建议显式指定。CentOS 8 / Rocky 8 的仓库 URL 里包含 release 版本信息如果不指定reposync 会尝试读取系统自身的版本信息。但仓库服务器本身如果跑的是其他版本或者你想用同一台服务器同步不同版本的仓库不显式指定就会出错或同步到奇怪的路径。同步完后必须执行createrepo_c这一步是生成仓库元数据DNF 客户端才能识别目录结构createrepo_c --update $REPO_ROOT/baseos--update表示在已有元数据基础上增量更新比全量重建快得多。首次同步时不需要--update直接从零生成。脚本里统一加了--update实测即使首次执行也能正确完成只是第一次慢一些。3.3 本地 repo 文件与客户端配置仓库服务器自产自销时也要把默认官方源指向本地。在/etc/yum.repos.d/下新建一个local.repo[local-baseos] nameLocal BaseOS baseurlfile:///opt/repo/centos8/baseos gpgcheck0 enabled1 [local-appstream] nameLocal AppStream baseurlfile:///opt/repo/centos8/appstream gpgcheck0 enabled1 [local-extras] nameLocal Extras baseurlfile:///opt/repo/centos8/extras gpgcheck0 enabled1 [local-epel] nameLocal EPEL baseurlfile:///opt/repo/centos8/epel gpgcheck0 enabled1这里先把gpgcheck0注释说明一下。内网仓库我们自认为是可信的且同步来的 RPM 包里本身可能还带原厂的签名但 createrepo_c 在本地生成的 repodata 里不会自动携带原厂 GPG 签名信息。如果你硬要开gpgcheck1客户端会在校验元数据时因找不到有效签名而报错反而卡住安装流程。中小规模内网环境gpgcheck0是务实选择。如果你比较严谨可以后续对仓库做独立 GPG 签名那是进阶玩法这里不展开。客户端上的配置更简单把默认源全部禁用只留内网源mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak然后新建一个指向服务器的inner.repo[inner-baseos] nameInner BaseOS baseurlhttp://repo-server-ip/centos8/baseos gpgcheck0 enabled1 # 如果走 NFS 挂载方案则改为 baseurlfile:///mnt/repo/centos8/baseos这里涉及一个决策点客户端到底走 HTTP 还是走 NFS。我的建议是如果客户端机器已经把 NFS 挂载到固定路径就优先走file://因为 DNF 本地解析速度比 HTTP 快不少且不占用 web 服务连接如果某些客户端因为权限或网络策略挂不了 NFS就走 HTTP。二者可以共存不冲突。4. NFS 共享服务部署与调优4.1 NFS 服务端配置仓库目录就绪后下一步是用 NFS 把它共享给所有客户端。编辑/etc/exportsvi /etc/exports写入如下内容/opt/repo 10.0.20.0/24(rw,sync,no_root_squash,no_subtree_check)这里逐项解释每个选项因为这里几乎是 NFS 配置里踩坑最多的地方。10.0.20.0/24是允许访问的内网网段。严格限定网段是非常必要的安全措施不要写*或0.0.0.0/0否则任何能路由到你服务器的机器都能挂载你的整个仓库文件系统。rw设的是读写权限。仓库目录本身业务上只需要只读但 sync 脚本又需要往里面写数据所以服务端这里给了rw。客户端挂载时可以用ro强制只读双保险。sync表示服务端在写入操作时同步刷盘。NFS 默认是同步的这个参数主要强调一下防止有人改成async后数据丢失。仓库数据同步频率本来就不高完全不需要为了性能牺牲一致性。no_root_squash允许客户端 root 用户以 root 身份操作共享目录。对被共享的是仓库这种基础设施目录来说这是必要的因为同步脚本和管理操作都是用 root 跑的。但这里需要你理解一个风险no_root_squash一旦配置错客户端拥有 root 权限就等于服务端拥有 root 权限所以只能在内网可信环境使用。no_subtree_check是性能优化参数。对外层目录做子目录校验非常消耗性能而仓库目录结构固定、变更不频繁关闭校验能明显提升并发读性能。配置完后执行exportfs -r systemctl start nfs-server rpcbind systemctl enable nfs-server rpcbind用showmount -e验证导出状态showmount -e localhost正常输出类似Export list for localhost: /opt/repo 10.0.20.0/24还有一个比较容易漏掉的点放行 NFS 相关服务端口。如果服务器上有 firewalld 开启需要放行 nfs、rpc-bind、mountd 相关服务firewall-cmd --permanent --add-servicenfs firewall-cmd --permanent --add-servicerpc-bind firewall-cmd --permanent --add-servicemountd firewall-cmd --reload如果你用的是 iptables 或者其他安全组策略记得把 2049nfs和 20048mountd以及 rpcbind 111 端口都放通。这个坑我踩过一次NFS 服务端明明正常客户端 mount 却一直超时查了半天才发现是防火墙没放行 mountd。4.2 NFS 客户端挂载与自动恢复客户端操作分三步走。安装 NFS 工具包dnf install -y nfs-utils创建挂载点并手动挂载测试mkdir -p /mnt/repo mount -t nfs4 10.0.20.10:/opt/repo /mnt/repo注意这里我写的是 NFSv4后面调优章节会细说原因。挂载成功后验证df -h /mnt/repo | tail -1 ls /mnt/repo/centos8能看到仓库目录树说明挂载成功。要开机自动挂载编辑/etc/fstab10.0.20.10:/opt/repo /mnt/repo nfs4 defaults,_netdev,noatime 0 0解释一下这条 fstab 记录里的三个关键选项_netdev让系统在网络就绪后才执行挂载。没有它开机时网络接口可能还没起来NFS 挂载会失败然后触发紧急模式启动。这个问题在带 NFS 的服务器上很常见几乎每次都遇到。noatime挂载访问时间不更新。仓库目录是纯读取场景更新访问时间没有任何价值关闭后可以减少大量写 IO。0 0表示不对该挂载点做 dump 备份和 fsck 检查。NFS 远端文件系统本来就不应该由本机 fsck。改完 fstab 后一定要现场验证配置合法性mount -a多执行一次别等到重启后再发现 fstab 写错了那就要进紧急模式手动修了。4.3 NFSv4 与 NFSv3 的选型对比项目初始化阶段我特意查过NFS 到底用 v3 还是 v4。两者差异不仅仅是版本号维度NFSv3NFSv4端口依赖需要 rpcbind、mountd 等多个端口服务端固定监察 2049 端口少量辅助端口防火墙配置端口多配置繁琐相对简单安全认证依赖传统 AUTH_SYS控制薄弱支持 RPCSEC_GSS安全性更高锁机制需要单独的网络锁管理器集成状态协议稳定命令兼容mount -t nfsmount -t nfs4 或 mount -t nfs 自动协商实际使用中在内网可信环境里 v3 和 v4 性能差异不大但我还是推荐 v4核心原因是防火墙和安全组配置省心很多。v3 的 mountd 是随机端口你必须在防火墙里猜它落到哪个端口或者复杂配置固定端口而 v4 固定 2049规则一写就完事。省下来的排查时间是真金白银。4.4 仓库文件同步与 NFS 缓存一致性仓库同步脚本和 NFS 服务共存时有个容易忽略的问题如果同步工具在 NFS 共享目录上做文件替换客户端可能短暂读到目录不一致的状态。我的处理方式是让同步脚本先写好文件再对仓库目录执行一次createrepo_c --update。createrepo_c 更新元数据是原子性的客户端重新刷新缓存后能拿到新元数据。另外避免直接用 rsync 覆盖repodata目录因为 repodata 里带有完整索引和哈希只要内容没更新就不应该动它。还有一个实操细节createrepo_c 生成 repodata 后会指示客户端如何通过哈希校验文件完整性。但如果你的 NFS 挂了noatime或页面缓存策略客户端从 NFS 读到的文件哈希可能和元数据里记录的不完全一致。遇到这种报错不要慌先让客户端卸载重挂或者重启 dnf-makecache 服务基本都能解决。5. 客户端 DNF 使用与效果验证5.1 生产机全流程体验搭建完成后拿一台全新机器实测整个链路。客户端安装完系统、配置好 IP 后按顺序执行dnf install -y nfs-utils mkdir -p /mnt/repo echo 10.0.20.10:/opt/repo /mnt/repo nfs4 defaults,_netdev,noatime 0 0 /etc/fstab mount -a cat /etc/yum.repos.d/inner.repo EOF [inner-baseos] nameInner BaseOS baseurlfile:///mnt/repo/centos8/baseos gpgcheck0 enabled1 [inner-appstream] nameInner AppStream baseurlfile:///mnt/repo/centos8/appstream gpgcheck0 enabled1 [inner-extras] nameInner Extras baseurlfile:///mnt/repo/centos8/extras gpgcheck0 enabled1 [inner-epel] nameInner EPEL baseurlfile:///mnt/repo/centos8/epel gpgcheck0 enabled1 EOF dnf clean all dnf makecachemakecache是验证仓库是否正常的试金石。如果仓库元数据和路径都正确它会迅速生成缓存并显示类似Metadata cache created的输出。如果某个仓库配置错误或有网络问题它会明确报出是哪个 repo 失败方便定位。然后随便找一个依赖多的包实测dnf install -y nginx如果 nginx 及其一大串依赖都能秒装完成说明仓库和 NFS 链路是通的。再试几个冷门包或头文件包dnf install -y gcc-c openssl-devel zlib-devel这些包依赖链比较长能顺利装完基本可以宣布这套仓库系统可用了。5.2 自定义 RPM 包的入库与使用仓库系统的另一个价值是承载项目组自定义 RPM 包。这里有一套标准流程。打好的 RPM 包拷贝到仓库服务器的/opt/repo/custom/local-rpms/目录然后重新生成元数据createrepo_c --update /opt/repo/custom/local-rpms/客户端 repo 文件里加一段[inner-custom] nameInner Custom RPMs baseurlfile:///mnt/repo/custom/local-rpms gpgcheck0 enabled1更新缓存后就能直接用 DNF 安装内部包dnf clean all dnf makecache dnf install -y company-internal-java8这个流程一旦跑通再也不用手工rpm -ivh分发 RPM 文件了所有机器的包来源、版本、依赖关系全部可追踪。有两点提醒一是自定义包的命名规范。强烈建议统一前缀比如company-xxx这样dnf list | grep company一眼就能看出哪些包是内部包也方便后续脚本批量处理。二是自定义包必须有明确的版本号规则。DNF 对 RPM 版本号格式敏感不规范的版本号可能导致安装时被意外降级或冲突。实测中最常见的错误是把版本写成20190101这种纯数字正确的做法应该是1.0.0或1.0.0-1.el8这种标准格式。5.3 客户端缓存刷新的经验DNF 客户端默认会缓存仓库元数据一段时间通常数小时。如果你在服务端刚同步完一批新包客户端立刻执行dnf install newpkg有概率提示找不到包或包不存在。这不是仓库坏了而是客户端本地缓存太旧。处理方式很简单强制刷新dnf clean all dnf makecache如果你希望客户端每次安装都实时读取最新元数据可以在 repo 配置里加一行metadata_expire60单位是秒设置成 60 秒表示元数据 1 分钟后过期客户端会强制重新拉取。对于包更新频率较低的企业内网环境这个配置会让“服务端同步完包客户端马上就能装”成为常态体验提升明显。缺点是会略微增加每次 dnf 命令的元数据读取时间但内网环境下这点延迟完全可以接受。还有个小技巧DNF 支持minimal和default两种元数据下载模式。默认是default会下载完整的文件列表信息。如果客户端多、网络一般可以在主配置/etc/dnf/dnf.conf里设置[main] metadata_expire90同时把 repo 文件里可选的metadata_expire省略让所有仓库统一走主配置。这样后期调整一个文件就可以影响全局省事不少。6. 常见问题与排查技巧实录6.1 客户端挂载 NFS 超时这是出现频率最高的故障。现象是客户端执行mount后长时间卡住最后报mount.nfs: Connection timed out。排查步骤按顺序来先确认网络通不通ping 服务端IP。确认服务端 NFS 服务是否启动systemctl status nfs-server。本机验证导出列表showmount -e 服务端IP。如果这一步超时问题很可能在防火墙或 rpcbind 服务。检查服务端防火墙是否放行 nfs、rpc-bind、mountdfirewall-cmd --list-services。检查安全组或 iptables 中端口 2049、111、20048 的放行情况。如果上面都已确认无误但仍然挂载超时重点检查/etc/exports里的网段写法。比如你写成10.0.20.0/24但客户端实际 IP 是10.0.21.5那就是授权范围不匹配。exportfs -v可以查看实际生效的导出规则。还有一种容易被忽略的情况服务端开启了rpcbind但是 nfs-server 因为某种原因独占了端口导致 rpcbind 查询失败。这时重启相关服务systemctl restart rpcbind nfs-server exportfs -r6.2 客户端 dnf 报错 “创建缓存失败”客户端挂载成功但dnf makecache报错Errors during downloading metadata for repository inner-baseos: - Status: 13 Permission denied这种问题十有八九是 NFS 挂载权限问题。检查挂载点的权限ls -lZ /mnt/repo/centos8/baseos/repodata/如果显示????或属主异常先确认服务端/opt/repo目录属主和权限chown -R root:root /opt/repo chmod -R 755 /opt/repo客户端这边如果挂载参数里手贱加了uidxxx或gidxxx也可能导致 DNF 进程以 root 身份运行无法读取。标准内网场景应该避免在 fstab 里加 uid/gid 参数让 NFS 的权限模型自己工作。还有一个隐藏坑客户端如果同时挂载了多个 NFS 共享且其中某个挂载点失效dnf在扫描本地仓库时会尝试访问所有挂载点导致超时。检查一下/etc/mtab里所有 NFS 挂载是否都健康。6.3 createrepo_c 生成失败或索引不匹配createrepo_c 生成时如果报Error: Could not open /opt/repo/centos8/baseos/repodata/xxx.xml通常是因为 repodata 目录被部分写入或权限异常。先清理残留在 repodata 下的临时文件再重新生成cd /opt/repo/centos8/baseos rm -rf repodata createrepo_c .如果同步脚本总是失败可以在脚本里加一行du -sh $local_path记录每次同步后的仓库大小这样下次出问题时能判断是哪个仓库没有成功更新。我个人的经验是自动化任务里凡是有set -euo pipefail的脚本失败时会很快暴露问题。但如果你是在交互式 shell 里手动执行命令一定要留意每条命令的返回码。shell 的$?是最简单也最容易忽略的调试工具。6.4 常见问题速查表故障现象可能原因处理方式NFS 挂载超时防火墙未放行 2049/111/20048放行对应端口或服务挂载成功但dnf makecache权限错误服务端目录权限异常重新 chown/chmod 仓库目录客户端提示 repo 元数据缺失服务端未执行 createrepo_c执行createrepo_c --update新上传的自定义 RPM 客户端找不到客户端元数据缓存过期dnf clean all dnf makecache客户端显示包版本不一致服务端仓库未做增量同步运行同步脚本后刷新客户端缓存showmount -e超时rpcbind 服务故障或防火墙拦截检查 rpcbind 状态和端口同步后的仓库体积异常增大--delete参数没加加--delete并重新同步还有一个容易踩的坑藏在 NFS 的 IO 等待问题里。当仓库同步大量文件时服务端磁盘 IO 可能飙高导致同一时间段内客户端 NFS 读取延迟增大。如果你们有自动化脚本在固定时间点批量安装包要和仓库同步的 cron 时间错开。通常我把仓库同步放在凌晨 2 点到 4 点之间这会避开业务高峰和大多数定时任务。7. 同步策略与后续扩展建议7.1 定时同步的合理周期既然仓库是基础设施它就得有规律地更新。我这里配置了三条 crontab 任务# 每天凌晨 2:30 自动同步基础仓库 30 2 * * * /opt/repo/scripts/sync-repo.sh /var/log/repo-cron.log 21 # 每周末凌晨 3:00 清理客户端本地 dnf 缓存 0 3 * * 0 for host in $(cat /opt/scripts/client-list.txt); do ssh $host dnf clean all; done # 每月 1 号凌晨 4:00 生成仓库使用统计报表 0 4 1 * * /opt/repo/scripts/repo-report.sh同步周期怎么定如果只要求内网包版本稳定一周一次足够如果你们跟着上游安全更新走建议每 24 小时同步一次。同步本身不产生业务影响唯一要关注的就是耗时和磁盘 IO。根据仓库大小同步加建索引通常在 10~30 分钟以内放在凌晨完全无感。需要提醒的是定时同步应加锁防止两个同步任务同时执行。我的脚本开头就用了flockexec 9/var/lock/repo-sync.lock flock -n 9 || exit 1没有锁的话某次同步卡住导致任务堆积可能会出现两个 reposync 进程同时操作同一目录轻则文件冲突重则元数据损坏。7.2 扩展到多仓库、多版本、多架构这套架构的可扩展性是我很满意的一点。当项目组需要增加 Docker 官方源时只需要在/opt/repo下新建目录docker-ce/。在仓库服务器上添加 Docker 的 repo 文件。用 reposync 同步到本地。客户端 repo 文件里加一段baseurlfile:///mnt/repo/docker-ce/...dnf makecache即可。同理如果需要支持 CentOS 7 和 CentOS 8 共存按上面的结构增加一个centos7/目录reposync 时用--releasever7即可。客户端根据自己的系统版本选择对应的 baseurl互不干扰。架构上再进一步你甚至可以把仓库做成分级缓存核心仓库服务器作为源各子网再放一台缓存节点。节点通过 NFS 或 HTTP 从源拉取客户端再访问节点。对于客户端数量上百的组织这种层级结构能有效分担主仓库服务器压力。7.3 仓库健康检查与监控基础设施总得有监控配套。我现在在服务端放了一个简单的健康检查脚本每分钟检测一次仓库目录和 NFS 服务状态#!/bin/bash REPO_DIR/opt/repo if [ ! -d $REPO_DIR/centos8/baseos/repodata ]; then echo $(date) repo metadata missing /var/log/repo-health.log fi if ! systemctl is-active nfs-server /dev/null 21; then echo $(date) nfs-server down /var/log/repo-health.log fi对于客户端重点监控dnf makecache的执行时长。如果某台机器突然耗时暴涨多半是网络链路出问题或者服务端 NFS 性能下降。可以设计一个定时任务跑time dnf makecache把耗时记录到日志超过阈值就告警。这一整套下来整个内网软件分发和共享存储的基础设施就比较完整了。从源码到 RPM从仓库同步到 NFS 挂载从客户端配置到故障排查每个环节都有据可查。最后分享我个人的一点体会做完这套环境后最明显的感受不是“装机变快了”而是“出问题时不再慌了”。以前新机器到货装个 JDK 都要从外网现拉慢不说还时不时失败。现在只要声网卡一插、IP 一配仓库自动可用自定义包一键装上整套动作行云流水。如果你也在管理一批内网服务器非常建议把这个组合用起来。过程中踩的坑无非集中在防火墙、目录权限、缓存一致性这几处前面写的排查思路基本都能覆盖到。
