在服务器的世界里,CentOS凭借其稳定性和与Red Hat Enterprise Linux (RHEL)的亲缘关系，长久以来占据了重要的一席之地，对于每一位接触CentOS的系统管理员或开发者而言，掌握其软件的安装、管理与维护，是开启一切工作的基础，这篇内容将系统性地梳理在CentOS环境中管理软件的各种方法，从核心的包管理器到现代的容器化技术，为你构建一个清晰、完整的知识体系。
核心利器：dnf 与 yum 的前世今生
谈及CentOS软件管理,第一个绕不开的工具就是yum（Yellowdog Updater, Modified），在CentOS 7及更早版本中，yum是默认的命令行包管理器，它基于RPM包，能够自动处理软件包之间的依赖关系，极大地简化了安装过程。
随着技术的发展,yum的后继者——dnf（Dandified YUM）应运而生，从CentOS 8开始，dnf正式取代yum成为默认的包管理器。dnf在性能、内存占用和依赖解析算法上进行了全面优化，提供了更快的体验和更准确的处理能力，一个有趣的事实是，在许多新版本的系统中，为了保持用户习惯，输入yum命令实际上会被重定向到dnf。
尽管如此,理解它们的基本命令是至关重要的，以下是一张常用命令的速查表，涵盖了绝大多数日常操作场景：
| 功能 | dnf 命令 (CentOS 8+) | yum 命令 (CentOS 7) | 示例 |
|---|---|---|---|
| 安装软件包 | dnf install package_name |
yum install package_name |
dnf install nginx |
| 移除软件包 | dnf remove package_name |
yum remove package_name |
dnf remove nginx |
| 更新所有软件包 | dnf update 或 dnf upgrade |
yum update |
dnf update |
| 更新指定软件包 | dnf update package_name |
yum update package_name |
dnf update nginx |
| 搜索软件包 | dnf search keyword |
yum search keyword |
dnf search web server |
| 查看软件包信息 | dnf info package_name |
yum info package_name |
dnf info nginx |
| 列出已安装的包 | dnf list installed |
yum list installed |
dnf list installed | grep nginx |
| 列出可用的软件包 | dnf list available |
yum list available |
dnf list available |
生态基石：理解并善用软件仓库
dnf和yum的强大之处并不仅仅在于命令本身，更在于其背后庞大而有序的软件仓库生态，仓库是存放大量经过编译、配置好的RPM软件包的服务器，CentOS默认配置了几个官方仓库，其中最重要的是：
- BaseOS: 提供构成底层核心操作系统的软件包，追求稳定和长期支持。
- AppStream: 提供用户空间的应用程序、运行时环境、语言和数据库等，这种模块化的设计让用户可以更灵活地选择不同版本的软件，例如不同版本的Python或Node.js。
官方仓库为了保持稳定性,并不会包含所有软件，这时，第三方仓库就成为了重要的补充。
最著名的第三方仓库当属EPEL (Extra Packages for Enterprise Linux)，它由Fedora项目维护，为RHEL及其衍生版（如CentOS）提供了大量高质量的额外软件包，这些软件包在官方仓库中是找不到的，启用EPEL仓库非常简单：
sudo dnf install epel-release
安装完成后,dnf会自动搜索并包含EPEL仓库中的软件包，对于有特定需求的用户，例如需要最新版本PHP的开发者，还可以考虑启用Remi's Repository等专门的第三方仓库。
超越仓库：RPM文件与源码编译
尽管仓库非常方便,但在某些特定场景下，我们可能需要采用更直接的方法。
直接安装RPM文件
当你从某个软件的官方网站下载了一个.rpm文件时，可以直接使用dnf进行本地安装。dnf会尝试从当前配置的仓库中解决该RPM文件的所有依赖项，这是优于传统rpm命令的地方。
sudo dnf localinstall /path/to/your/package.rpm
如果依赖项无法在仓库中找到,dnf会报告失败，这时，你可能需要手动寻找并安装所有依赖的RPM包，这是一个繁琐且容易出错的过程，通常被称为“依赖地狱”。
源码编译
这是安装软件的“终极手段”，提供了最大的灵活性，当你需要：
- 安装一个最新、尚未被打包的软件版本。
- 对软件进行定制化的编译选项（例如启用/禁用某个特定功能）。
- 软件根本不存在于任何仓库中时。
源码编译就成了唯一的选择,其经典流程通常遵循“三步曲”：
# 1. 解压源码 tar -zxvf software-version.tar.gz cd software-version # 2. 配置编译选项 ./configure --prefix=/usr/local/software --with-some-feature # 3. 编译并安装 make sudo make install
警告：源码编译的软件脱离了包管理器的控制，后续的升级、卸载都需要手动处理，容易在系统中留下“孤儿文件”，给系统维护带来挑战，除非有明确的需求，否则应优先考虑使用仓库或RPM包。
未来趋势：容器化技术
在现代应用部署中,Docker、Podman等容器化技术正在重塑软件的交付和管理方式，它们将应用程序及其所有依赖打包到一个轻量级、可移植的容器中，实现了与宿主操作系统的隔离，这种方式完美地解决了“在我机器上能跑”的经典问题，也避免了不同应用之间的依赖冲突。
对于CentOS用户而言,安装Podman（一个无守护进程的、更安全的Docker替代品）来运行容器，已经成为部署现代Web应用、微服务的常见做法。
sudo dnf install podman # 然后就可以拉取并运行镜像了 podman pull nginx podman run -d -p 8080:80 nginx
容器化将软件管理的焦点从操作系统层面,转移到了应用层面，提供了一种更敏捷、更可靠的解决方案。
相关问答 FAQs
问题1：我的服务器是CentOS 7，我应该继续使用yum还是可以升级到dnf？
解答： 对于CentOS 7系统，强烈建议继续使用默认的yum，虽然可以手动安装dnf，但这并非官方支持的做法，可能会与系统现有的包管理逻辑产生未预期的冲突，影响系统的稳定性。yum在CentOS 7上已经非常成熟和稳定，足以胜任日常的软件管理工作。dnf是为CentOS 8及以上版本设计的，是这些系统的标准选择，在哪个系统，就用哪个系统默认的工具。
问题2：我执行sudo dnf install some-tool，但是系统提示“未找到匹配的参数: some-tool”，我该怎么办？
解答： 这是一个非常常见的问题，通常可以通过以下步骤进行排查：
- 检查拼写：首先确认你输入的软件包名称是否正确，很多软件包名和我们常用的名称有细微差别，Apache HTTP服务器在CentOS中的包名是
httpd，而不是apache。 - 使用关键词搜索：如果不确定确切的包名，可以使用
dnf search 关键词来搜索。dnf search web server可能会帮你找到httpd。 - 启用EPEL仓库：如果官方仓库中没有，它很可能在EPEL仓库里，请先执行
sudo dnf install epel-release来启用EPEL，然后再用dnf search some-tool重新搜索一次。 - 考虑软件不存在：如果以上步骤都找不到，说明该软件可能没有为 CentOS 提供预编译的RPM包，你需要去该软件的官方网站查看，是否有提供RPM下载链接（回到RPM文件安装法），或者是否提供了源码供你编译安装（回到源码编译法）。