3、KMS 部署环境准备：操作系统、依赖库、网络规划
部署 KMS 之前，我习惯先花半小时把环境搭扎实。很多故障追到根上，其实都是操作系统版本踩坑、依赖库漏装、或者网络规划没留余地。今天我把这几块的要点捋一遍。
3.1 操作系统选择
KMS 官方支持主流 Linux 发行版和 Windows Server。我个人更偏向 Linux，尤其是 RHEL/CentOS 7/8 和 Ubuntu 20.04/22.04。为什么？因为生产环境里这些系统的维护周期长，社区踩过的坑也多，遇到问题容易搜到答案。
关键指标：
- 内核版本 ≥ 4.18（KMS 的加密模块对 newer kernel 更友好）
- glibc ≥ 2.28（不然部分依赖库会报符号找不到）
- systemd ≥ 219（用来管理 KMS 服务自启动）
我记得有一次，客户在 CentOS 6 上硬跑 KMS，结果加密密钥生成一直失败。查了半天，发现是旧内核缺少 getrandom 系统调用。所以，我建议直接上 EL8/9 或者 Ubuntu 22.04，省心很多。
| 操作系统 | 推荐版本 | 注意事项 |
|---|---|---|
| CentOS / RHEL | 7.9 / 8.4+ / 9 | 7 系列已 EOL，建议升级；8 需额外配置 BaseOS/AppStream |
| Ubuntu | 20.04 / 22.04 | 默认源里 OpenSSL 版本可能偏旧，需手动升级 |
| Windows Server | 2019 / 2022 | 需安装 VC++ 运行库，且不支持 Docker 部署 |
我的小习惯： 生产机用最小化安装，不装 GUI。KMS 纯命令行运行，多一个桌面服务就多一个攻击面。
3.2 依赖库安装
KMS 核心依赖也就几个：OpenSSL、libcurl、libxml2、SQLite。但版本卡得死——差一个小版本都可能跑不起来。
举个例子，OpenSSL 必须 ≥ 1.1.1，而且最好用系统包管理器安装，不要自己编译，否则 KMS 的 HMAC 计算会随机报段错误。我在项目中遇到过，有同事非要自己编译 OpenSSL 1.1.1u，结果编译参数少了 enable-ec_nistp_64_gcc_128，导致 EC 密钥操作崩溃。
我曾经…… 在一个 CentOS 7 上忘装 libcurl-devel，KMS 启动后网络服务正常，但 HTTPS 请求全部返回 502。原因是编译时未启用 SSL 支持。所以，请一定按以下列表逐项安装：
# CentOS / RHEL
yum install -y openssl-devel libcurl-devel libxml2-devel sqlite-devel
# Ubuntu / Debian
apt install -y libssl-dev libcurl4-openssl-dev libxml2-dev libsqlite3-dev
除了这些，KMS 还依赖一个轻量级的 JSON 解析器——jansson。这个包很多系统源里没有，需要手动下载编译。我通常这样搞：
wget https://digip.org/jansson/releases/jansson-2.14.tar.gz
tar xzf jansson-2.14.tar.gz
cd jansson-2.14
./configure --prefix=/usr/local
make
make install
装上后记得运行 ldconfig，不然 KMS 启动时会报 libjansson.so.4: cannot open shared object file。
依赖库版本速查表（建议锁定）：
| 库名 | 最低版本 | 备注 |
|---|---|---|
| OpenSSL | 1.1.1l | 推荐 3.0 LTS |
| libcurl | 7.71 | 必须支持 SSL/TLS |
| libxml2 | 2.9.10 | 无特殊要求 |
| SQLite | 3.31 | WAL 模式需此版本以上 |
| jansson | 2.14 | 必须手动装，注意路径 |
3.3 网络规划
KMS 的通信本质上就是 HTTPS + WebSocket。端口规划其实很简单，但很多人忽略负载均衡和心跳检测。
默认情况下，KMS 监听两个端口：
- 443/tcp：对外提供密钥服务
- 8080/tcp：内部健康检查和管理接口（必须限制内网访问）
你想想看，如果 8080 暴露到公网，别人直接就能调用管理接口……嗯，我见过好几个项目因为这个被人「搬走」了密钥库。
网络规划最佳实践：
- 使用独立 VLAN，防火墙只放通 443 到 KMS 集群
- 前端加一层 Nginx 反向代理做 TLS 卸载
- 如果跨机房，网络延迟务必 < 50ms，否则密钥协商会超时重试
另外，集群内部节点之间需要互相走 9090/tcp 做数据同步。这个端口也要保证互通、不走公网。我曾经在一个跨 AZ 的部署里，忘了在安全组开放 9090 端口，结果节点之间永远处于 FOLLOWER 状态，Leader 选举一直失败。排查了整整两天才定位到。
端口清单（防火墙规则）：
| 方向 | 端口 | 协议 | 说明 |
|---|---|---|---|
| 外部 → KMS | 443 | TCP | 客户端访问 |
| 运维 → KMS | 8080 | TCP | 管理/监控（限制IP） |
| KMS 节点间 | 9090 | TCP | 集群同步 |
| KMS → 后端 DB | 3306 | TCP | 如果使用外部数据库 |
最后，如果你打算用容器部署，记得把网络模式设为 host 或者做好端口映射。千万不要用默认 bridge 还不开端口——我帮人排查过好几起「容器里服务正常，外部死活连不上」的案例。
整体来看，环境准备就围绕这三块展开。操作系统选对版本，依赖库一个不落，网络把端口和延迟考虑进去，后面故障排查能少一半工作量。
一句话总结： 环境搭得好，KMS 稳如狗。