1. 安装规则概述
大家好，我是老张。今天咱们聊聊安装规则这个话题。
你可能觉得，安装软件不就是双击一下、点个下一步吗？嗯，没那么简单。在企业级运维里，安装规则是整套自动化体系的基石。我见过太多因为安装规则没搞明白，导致线上环境炸锅的案例了。
1.1 什么是安装规则
说白了，安装规则就是一套「软件该怎么装、装在哪、跟谁一起装」的约束条件。它告诉系统：
- 这个包需要什么前置条件
- 它跟哪些包不能共存
- 它要装到哪个版本才安全
- 它支持什么硬件架构
举个例子，你装一个数据库，它可能要求操作系统是 CentOS 7.6 以上，内存至少 4G，而且不能跟另一个版本的 MySQL 冲突。这些条件，就是安装规则。
1.2 为什么需要安装规则
你想想看，如果没有安装规则会怎样？
我记得刚入行那会儿，在一家小公司做运维。有一次手动装了个 Nginx，结果跟系统自带的 Apache 抢端口，整个网站挂了半小时。那时候我就想，要是系统能自动告诉我「这两个不能一起装」，该多好。
安装规则解决了三个核心问题：
- 避免冲突 — 防止软件之间打架
- 保证依赖 — 确保运行环境完整
- 版本管控 — 防止装错版本导致不兼容
我个人的习惯是，在写自动化部署脚本之前，先把安装规则梳理清楚。这一步省了，后面全是坑。
1.3 安装规则的核心要素
安装规则有四个核心要素，我一个个说。
依赖（Dependency）
依赖就是「你要装我，得先装谁」。比如你要装 Python 的某个库，它可能依赖 GCC 编译器、OpenSSL 库等等。
依赖分两种：
- 运行时依赖 — 软件跑起来必须有的东西
- 构建时依赖 — 编译安装时才需要的东西
冲突（Conflict）
冲突就是「你不能跟我一起装」。常见场景：
- 两个软件监听同一个端口
- 两个软件修改同一个配置文件
- 两个软件提供相同的系统命令
举个例子，你不能同时装 Nginx 和 Apache 都监听 80 端口。安装规则里就要写明：Conflicts: httpd。
rpm -q --conflicts 检查。
版本（Version）
版本规则是最容易出问题的。你想想看，一个软件可能有几十个版本，每个版本依赖的库版本都不一样。
版本约束通常用这些符号：
| 符号 | 含义 | 示例 |
|---|---|---|
>= |
大于等于 | libfoo >= 2.0 |
<= |
小于等于 | libfoo <= 3.0 |
> |
大于 | libfoo > 1.9 |
< |
小于 | libfoo < 3.1 |
= |
精确匹配 | libfoo = 2.5 |
我个人建议，能用精确版本就别用范围。范围越大，出问题的概率越大。
架构（Architecture）
架构规则决定了软件能在什么 CPU 上跑。常见的架构有：
x86_64— 64位 Intel/AMDaarch64— 64位 ARMi686— 32位 x86
你不可能在 ARM 服务器上装 x86 编译的二进制包，对吧？这就是架构规则存在的意义。
1.4 安装规则的实际应用
说了这么多理论，咱们看看实际怎么用。以 RPM 包为例，它的安装规则写在 spec 文件里：
Name: myapp
Version: 1.0.0
Release: 1
Requires: libssl >= 1.1.1, libcrypto >= 1.1.1
Conflicts: oldapp <= 0.9.0
Arch: x86_64这段规则的意思是：
- 需要 libssl 1.1.1 以上版本
- 需要 libcrypto 1.1.1 以上版本
- 不能跟 oldapp 0.9.0 及以下版本共存
- 只能在 x86_64 架构上安装
你看，一条规则就把依赖、冲突、版本、架构全涵盖了。
rpm -qR 查看已安装包的依赖，用 rpm -q --conflicts 查看冲突。这两个命令我几乎天天用。
1.5 小结
安装规则这东西，说白了就是给软件包管理器看的「说明书」。它告诉系统：
- 装我之前，先准备好什么
- 装我的时候，别跟谁撞车
- 装我的版本，得在哪个范围内
- 我的二进制，只能在什么架构上跑
下一章，咱们会深入讲依赖管理的具体实现。到时候我会拿实际项目中的案例，带大家一步步分析。
嗯，今天就到这儿。记住一句话：安装规则写得好，运维下班早。