上个月我帮朋友整理一台 Rocky Linux 9.3 服务器任务是把 Hermes Agent 和 Hermes-Web-UI 完整跑起来。说实话这类开源项目本身的中文文档不多官方 README 写得比较克制很多细节都要翻 issue 才能拼出来。如果你和我一样不想为了一个 Agent 服务去引入整套容器编排或者服务器配置比较紧张想用最朴素的方式在裸系统上装好这套东西这篇文章应该能帮你省不少时间。我先把结论放在前面Hermes Agent 本质上是负责会话管理和指令调度的常驻服务Hermes-Web-UI 是它的 Web 控制台。两者是两个独立进程不存在“装一个就把 UI 也带出来”的好事必须分别下载、分别配置、分别守护。文章后面的所有步骤都是围绕这条主线展开的。这套内容适合两类读者一类是已经有 Rocky Linux 基础、想搭私有 Agent 服务平台的人另一类是刚接触 Hermes、被各种术语绕晕的入门运维。我会把每一处关键的“为什么”也讲清楚你照着做能跑通也知道做砸了该去哪里查。1. 先把 Hermes Agent 和 Hermes-Web-UI 的关系理清楚1.1 Agent 是引擎Web-UI 是仪表盘我第一次看到 Hermes 这个名字时也困惑过因为官方仓库里同时出现两个项目很容易让人以为它们是同一个东西。实际用起来你会发现两者的定位差别非常大。Hermes Agent 是跑在后台的核心服务它负责维护会话状态、接收外部指令、把消息路由给对应的执行通道同时把状态变化记录到本地存储。你可以把它理解成一个“总机”所有会话进来先由它登记身份、记录上下文再决定投递给哪条线路。它本身不依赖图形界面纯 API 就能工作。Hermes-Web-UI 则是“前台分机”一个面向人的浏览器控制台。你在面板里能看到哪些会话还活着、哪些任务执行失败了、Agent 当前配置是什么甚至能直接在网页上发起一个新的会话来调试。它本身不含调度逻辑所有操作都是通过调用 Hermes Agent 暴露的 API 完成的。这带来一个很实际的好处你可以不用 Web-UI直接用脚本请求 Hermes Agent 的接口也可以把 UI 装在内网跳板机上只让它访问本机的 Agent 端口。组件解耦之后出问题时的排查边界会清晰很多。1.2 实际部署时我建议的组件拓扑一台刚刚装好的 Rocky Linux资源通常不富裕没必要把架构搞复杂。我的建议是四个组件都跑在同一台机器上组件进程监听地址对外暴露方式Hermes Agenthermes-agent127.0.0.1:7800仅本机不直接暴露公网Hermes-Web-UIhermes-web-ui127.0.0.1:8080通过 Nginx 反向代理反向代理nginx0.0.0.0:80/443对外提供 Web 访问数据目录/var/lib/hermes 等无本地磁盘定期备份坚持让 Agent 只监听 loopback 地址这是我踩过坑之后的习惯。第一次部署时我图省事把 Agent 监听在 0.0.0.0:7800结果安全扫描一上来就出现未授权访问风险。其实外面所有流量先进 Nginx再由 Nginx 转给 Web-UIWeb-UI 再去访问本机的 Agent完全够用还少暴露一个端口。2. 部署前先处理好系统环境2.1 确认系统版本并更新基础软件源Rocky Linux 从 8 到 9 的安装逻辑差别不大但软件源的仓库名有变化。建议先确认一下自己手里到底是哪个版本cat /etc/rocky-release如果是 Rocky Linux 9.x直接执行sudo dnf update -y sudo dnf install -y epel-release如果你是 8.10 或更早的 8.x 版本安装 epel 时要注意仓库地址。由于 8 系列已经步入维护周期尾声有些默认源里的 mirrorlist 可能已经返回空列表导致dnf install一直报找不到软件包。遇到这种情况不要反复折腾直接把/etc/yum.repos.d/里 Rocky 相关仓库文件中的mirrorlist注释掉换成可用的baseurl再执行sudo dnf clean all sudo dnf makecache系统源整利索了后面装依赖才不会被莫名奇妙的 GPG 错误或 404 打断。这一步看似浪费时间实际能避免一大批安装中途失败的妖魔鬼怪。2.2 设置静态 IP很多人忽略的部署前置条件Rocky Linux 默认用 DHCP 获取地址这在桌面环境没问题但跑服务时会很恶心。尤其 Hermes-Web-UI 登录后前端要拿着后端地址去做回调如果服务器 IP 在某次重启后变了浏览器里会出现“服务不可达”或“会话连接失败”。我一般拿到机器第一件事就是配静态 IP。使用 NetworkManager 的话先看当前连接名nmcli con show假设连接名是System eth0要配置成192.168.1.20/24网关192.168.1.1DNS 可以同时配国内公共 DNS 和备用 DNS执行sudo nmcli con mod System eth0 \ ipv4.method manual \ ipv4.addresses 192.168.1.20/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 223.5.5.5 1.1.1.1 sudo nmcli con up System eth0验证一下ip a ip route注意如果服务器是云厂商的 ECS千万不要在系统内部直接这样改 IP一旦控制台的弹性网卡和系统配置不一致机器可能直接失联。云上请通过控制台把私网 IP 设为固定分配。静态 IP 设好之后后面的 Web-UI 配置、Nginx 站点配置、systemd 服务检查全部可以围绕一个稳定的地址展开排查起来舒服得多。2.3 安装基础工具并创建专用运行用户安装 Hermes 不需要编译源码官方通常提供预编译二进制的 tar 包所以不需要完整的编译工具链。但下面这些工具建议提前备好sudo dnf install -y curl wget tar vim lsof sqlite3 policycoreutils-python-utilslsof和ss用于查端口sqlite3用于检查会话数据库policycoreutils-python-utils里带了semanage后面调整 SELinux 布尔值时会用到。然后创建一个专用系统用户。我不建议直接用 root 跑 Hermes一旦 Web-UI 某个上传接口有漏洞root 权限会让攻击者长驱直入。这里统一用一个hermes用户sudo useradd --system --home /var/lib/hermes --create-home --shell /usr/sbin/nologin hermes后面 Hermes Agent 和 Hermes-Web-UI 的服务我都用这个用户跑文件权限比较一致不会有“Agent 写入的目录 UI 读不了”之类的低级问题。3. 正式安装 Hermes Agent 服务端3.1 获取安装包时的几个关键检查点去 Hermes Agent 的 GitHub Releases 页面或者官网下载区找 Linux amd64 版本的安装包。你要确保三件事版本选稳定版而非 nightly、架构选对、下载后用 SHA256 校验文件完整性。下载前先确认架构uname -mx86_64 的机器对应amd64如果你用的是 ARM 的服务器则要选arm64包。下载命令大概长这样cd /tmp curl -fLO https://github.com/owner/hermes-agent/releases/download/v0.11.2/hermes-agent-linux-amd64-v0.11.2.tar.gz上面 URL 里的owner和版本号请以你打开 Release 页面时看到的实际地址为准不要盲抄。下载完立刻做校验sha256sum hermes-agent-linux-amd64-v0.11.2.tar.gz把输出的哈希值和 Release 页面公布的哈希值比对一致再继续。这一步对二进制分发的软件尤其重要既要防下载损坏也要防供应链被投毒。别嫌麻烦我身边已经有人因为跳过校验解压后运行才发现二进制被替换过。3.2 目录布局与二进制放置我不太建议把解压出来的文件直接丢在/opt/hermes-agent-0.11.2/这种带版本号的目录里。原因是后面升级时软链接和 systemd 指向要改来改去。我用的是固定路径加目录分离sudo mkdir -p /opt/hermes/bin /opt/hermes/etc sudo tar -xzf hermes-agent-linux-amd64-v0.11.2.tar.gz -C /tmp sudo cp /tmp/hermes-agent-linux-amd64-v0.11.2/hermes-agent /opt/hermes/bin/hermes-agent sudo chmod 755 /opt/hermes/bin/hermes-agent sudo chown -R hermes:hermes /opt/hermes配置放/opt/hermes/etc/数据放/var/lib/hermes/日志交给 journald 统一管理。这样升级时只需要替换/opt/hermes/bin/下的二进制配置和数据目录原封不动。3.3 第一次启动前先改好 config.ymlHermes Agent 首次运行前会要求指定配置文件。大多数发行版包里都带了一个config.example.yml先复制成正式配置再改sudo cp /tmp/hermes-agent-linux-amd64-v0.11.2/config.example.yml /opt/hermes/etc/config.yml sudo chown hermes:hermes /opt/hermes/etc/config.yml根据自己的实际情况至少要关注这几项agent: host: 127.0.0.1 port: 7800 data_dir: /var/lib/hermes session_store: sqlite session_ttl: 168h auth: token: 改成一段足够随机的字符串解释一下几个关键项为什么这样配host和port决定了 Agent 监听在哪里。127.0.0.1:7800意味着只允许本机访问这是安全基线。data_dir是会话和状态文件的存放位置。很多“会话一重启就丢”的案例就是这里没配程序退回使用了内存存储。session_store指定会话持久化方式。演示环境用默认内存没问题生产环境建议用sqlite这是一个单文件数据库备份起来非常方便。session_ttl是会话保留时长168h表示一周。如果你希望会话长期不丢可以直接改成720h甚至00通常表示不过期具体要看你用的版本语义建议保持默认再加定期备份。auth.token是 Web-UI 访问 Agent API 时要用到的凭证。别用admin、123456这种用openssl rand -hex 32生成一段openssl rand -hex 323.4 手动启动并做首次健康检查启动前先保证数据目录存在并且属主正确sudo mkdir -p /var/lib/hermes sudo chown -R hermes:hermes /var/lib/hermes sudo -u hermes /opt/hermes/bin/hermes-agent -c /opt/hermes/etc/config.yml看到类似listening on 127.0.0.1:7800的日志就说明起来了。按CtrlC先停掉因为后面我会用 systemd 托管现在只需要验证配置能正常加载。验证端口和相关目录ss -lntp | grep 7800 curl http://127.0.0.1:7800/healthz ls -l /var/lib/hermes如果 healthz 返回了包含ok的 JSON说明 Agent 服务本身没有问题。这里有一个容易踩的坑明明ss能看到端口curl却不通大概率是 Rocky Linux 自带的 firewalld 在拦但因为我们绑定的是 127.0.0.1本机 curl 不应该被拦。真遇到这种情况先检查是不是 SELinux 拦截了进程绑定端口sudo ausearch -m avc -ts recent有针对性的报错再处理不要上来就setenforce 0。4. 单独安装 Hermes-Web-UI 并接入 Agent4.1 Web-UI 和 Agent 是两个进程别在 Agent 目录里找 UI有朋友在 Agent 解压目录里找web文件夹找不到就以为装错了。实际上 Hermes-Web-UI 是一个独立发布包需要单独下载。下载方式和 Agent 类似到 Releases 页面拿hermes-web-ui-linux-amd64的 tar 包同样做 SHA256 校验。然后把它放到对应的目录cd /tmp curl -fLO https://github.com/owner/hermes-web-ui/releases/download/v0.11.2/hermes-web-ui-linux-amd64-v0.11.2.tar.gz sha256sum hermes-web-ui-linux-amd64-v0.11.2.tar.gz sudo mkdir -p /opt/hermes-web/bin sudo tar -xzf hermes-web-ui-linux-amd64-v0.11.2.tar.gz -C /tmp sudo cp /tmp/hermes-web-ui-linux-amd64-v0.11.2/hermes-web-ui /opt/hermes-web/bin/hermes-web-ui sudo chmod 755 /opt/hermes-web/bin/hermes-web-ui sudo chown -R hermes:hermes /opt/hermes-web4.2 启动参数里的接线逻辑Hermes-Web-UI 启动时要告诉它两件事监听哪个地址以及后端 Hermes Agent 在哪里。这两件事直接决定整个系统的联通性。sudo -u hermes /opt/hermes-web/bin/hermes-web-ui \ --host 127.0.0.1 \ --port 8080 \ --agent http://127.0.0.1:7800 \ --data /var/lib/hermes-web注意--data这个参数我单独建了/var/lib/hermes-web来放 Web-UI 自己的会话数据。如果不指定有些版本会把浏览器会话信息放在进程当前目录的临时文件里systemd 一重启就可能被清理表现就是“登录状态一会儿就丢”。创建目录并调整属主sudo mkdir -p /var/lib/hermes-web sudo chown -R hermes:hermes /var/lib/hermes-web启动后用ss检查端口ss -lntp | grep 80804.3 用 SSH 隧道先做一次浏览器验证现在 Web-UI 监听在 127.0.0.1:8080外部还访问不到。上线前的第一次验证我建议不要急着开防火墙端口先用 SSH 隧道把它映射到本地ssh -L 8080:127.0.0.1:8080 root你的服务器IP然后本地浏览器打开http://127.0.0.1:8080。如果你配置正确且没改过 Agent token页面应该能正常打开。这里大概率会遇到的第一个问题是首次登录。不同版本的 UI 处理方式不太一样有的是“安装时在启动日志里打印一次性初始化密码”有的是“让你在页面上设置管理员账号”。我见过很多人在这一步卡住跑过来问“是不是必须去 Hermes 官网注册账号才能登录”。其实那只是公共服务中心的逻辑。你用自建模式部署时Web-UI 和 Agent 之间只认本地配置里的auth.token不需要任何云端账号。4.4 用 Nginx 把 Web-UI 暴露到局域网或公网验证通过后就可以让 Nginx 接管流量了。先安装sudo dnf install -y nginx sudo systemctl enable --now nginx然后在/etc/nginx/conf.d/hermes.conf里写一个反向代理配置server { listen 80; server_name hermes.example.com; client_max_body_size 16m; location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 1800s; proxy_send_timeout 1800s; } }这里最容易被忽略的一段是proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade;Hermes-Web-UI 和 Agent 之间很多状态同步依赖 WebSocket 长连接如果 Nginx 没有把 Upgrade 头正确传过去浏览器和 UI 之间的长连接会在几秒内断开。表现就是页面刚打开时正常过一会儿刷新就掉线。改完配置后测试并重载sudo nginx -t sudo systemctl reload nginx接着要处理两个东西防火墙和 SELinux。防火墙只放行 80/443 即可不要直接把 8080 暴露出去sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --permanent --add-servicehttps sudo firewall-cmd --reload然后是 SELinux。如果你的系统是 Enforcing 模式Nginx 默认是不允许向本机非标准端口发起网络连接的。不处理的话浏览器会 502而 Nginx 错误日志里会有connect() to 127.0.0.1:8080 failed (13: Permission denied)。执行sudo setsebool -P httpd_can_network_connect 1-P表示持久化重启后依然生效。如果对 SELinux 不熟这一条命令能帮你绕开 90% 的反代连接问题。到这里浏览器通过服务器 IP 或域名访问http://服务器IP就能看到 Web-UI 界面了。5. 从“会话老是丢失”开始的一次完整排查5.1 我复现到的三个典型现象部署完成后没多久我朋友反馈“我的 Hermes-Web-UI 的会话老是丢失”。这几乎是新手部署 Hermes 后最集中的问题。我让他分情况描述了一下最后归纳成三个典型场景现象可能原因排查优先级每次关闭浏览器或刷新后就跳到登录页Web-UI 用了内存态 Session没有持久化高刷新页面还能保持登录但历史会话记录没了Agent 的 data_dir 未配置或指向了临时目录高页面停留一段时间后点按钮无反应刷新后报连接断开Nginx 反代没有正确转发 WebSocket 头中Agent 服务一重启所有会话全部消失session_store 使用了内存存储高对照这个表格基本能锁定方向。大部分人的问题都出在“Agent 数据没落盘”和“WebSocket 连接被 Nginx 掐断”这两类。5.2 排查链路从 UI 日志一路挖到底层数据我先教他看日志。使用 systemd 托管后日志很好查sudo journalctl -u hermes-agent -n 100 --no-pager sudo journalctl -u hermes-web-ui -n 100 --no-pager如果日志里看不到明显报错接着查 Agent 的数据目录ls -l /var/lib/hermes正常情况下这里应该有一个或多个会话存储文件比如hermes.db。如果这个目录是空的或者里面只有cache之类的临时文件那基本可以断定Agent 的会话数据根本没有落在你期望的位置。我遇到过最典型的一种情况是用户复制了默认配置但默认配置里的data_dir指向的是一个随着进程退出就会清理的临时目录。Agent 每次启动都拿到一个全新环境会话自然全丢。再往前挖一层检查 Web-UI 的会话存储方式。Hermes-Web-UI 登录后会签发一个带有过期时间的会话 Cookie。默认过期时间如果设置过短比如 10 分钟浏览器只要空闲一小会儿就会被强制登出。这类问题日志里不会报错只会静默跳转登录页。5.3 修复手段和验证方法针对 Agent 端会话丢失修改配置session_store: sqlite data_dir: /var/lib/hermes确保数据目录创建好然后重启 Agentsudo systemctl restart hermes-agent重启后连 UI创建一个新的会话再手动重启一次 Agentsudo systemctl restart hermes-agent再次打开 Web-UI如果刚才那个会话还在历史列表里说明持久化已经生效。针对 Web-UI 登录态丢失优先检查 Nginx 配置里有没有转发 WebSocket 所需的头。如果没有加上下面这段再重载proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade;然后检查 Web-UI 自身的会话过期配置。如果你的版本支持环境变量或配置文件控制会话有效期建议把默认的较短时间调整到至少 8 小时以上或者让会话在浏览器关闭后依然保留“记住我”的持久化 Cookie。5.4 Nginx 隐性丢会话问题的复盘这里有一个特别容易让人迷惑的场景Agent 和 UI 都在跑日志也没有 error但页面用着用着就断。排查到最后才发现反向代理超时时间太短。Hermes-Web-UI 的会话一旦要通过 WebSocket 保持心跳Nginx 默认 60 秒没有读写就会断开连接浏览器重连失败后 UI 会认为后端失联于是强制会话失效。修复方式就是给 location 里加长超时proxy_read_timeout 1800s; proxy_send_timeout 1800s;这不算什么高深技巧但确实困扰过很多人。只要涉及 WebSocket 反代我基本都会在配置里把这个时间和 Upgrade 头一起写上养成习惯后这类问题基本绝迹。6. systemd 服务化让 Agent 和 Web-UI 开机自启并且能自动拉起6.1 Agent 的 service 单元手动启动只能用来验证配置正式跑必须写成 systemd 服务。先创建 Agent 的服务单元# /etc/systemd/system/hermes-agent.service [Unit] DescriptionHermes Agent Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Userhermes Grouphermes ExecStart/opt/hermes/bin/hermes-agent -c /opt/hermes/etc/config.yml Restarton-failure RestartSec5 LimitNOFILE65535 NoNewPrivilegestrue ProtectSystemfull ProtectHometrue ReadWritePaths/var/lib/hermes [Install] WantedBymulti-user.target这段配置里几个点需要说明一下User和Group使用hermes避免 root 权限运行。Restarton-failure表示只有异常退出才重启手动 stop 不会被自动拉起来。NoNewPrivilegestrue是一层安全兜底防止进程通过 setuid 等方式提权。ProtectSystemfull让进程对大部分系统目录只读我再用ReadWritePaths/var/lib/hermes给它单独开放数据目录写权限。6.2 Web-UI 的 service 单元Web-UI 的单元文件要写上向后端 Agent 地址# /etc/systemd/system/hermes-web-ui.service [Unit] DescriptionHermes Web UI Afternetwork-online.target hermes-agent.service Wantsnetwork-online.target [Service] Typesimple Userhermes Grouphermes ExecStart/opt/hermes-web/bin/hermes-web-ui \ --host 127.0.0.1 \ --port 8080 \ --agent http://127.0.0.1:7800 \ --data /var/lib/hermes-web Restarton-failure RestartSec5 LimitNOFILE65535 NoNewPrivilegestrue ProtectSystemfull ProtectHometrue ReadWritePaths/var/lib/hermes-web [Install] WantedBymulti-user.target写完以后重新加载 systemd再依次启动两个服务sudo systemctl daemon-reload sudo systemctl enable --now hermes-agent sudo systemctl enable --now hermes-web-ui查看状态systemctl status hermes-agent systemctl status hermes-web-ui两个服务都变成active (running)之后建议再做一次重启验证sudo reboot重启完成后直接检查端口和进程是否自动拉起。这一步能暴露很多“手动启动没问题一配 systemd 就起不来”的隐藏问题最常见的包括路径写错、权限不对、环境变量缺失等。6.3 日志查看与常见启动失败处理服务起不来时不要慌按顺序查sudo journalctl -u hermes-agent -n 50 --no-pager sudo journalctl -u hermes-web-ui -n 50 --no-pager我在实际处理中常遇到的启动失败原因有以下几类现象常见原因ExecStart路径找不到二进制没有放到单元文件里写的路径Permission denied/opt/hermes 或 /var/lib/hermes 属主不是 hermes端口被占用之前手动启动的进程没杀掉Failed to open config fileconfig.yml 权限过严hermes 用户读不了配置读不了的问题很隐蔽因为 root 能读不代表 hermes 用户能读。如果之前用 root 执行过vim修改配置文件权限可能还是 600需要调整sudo chown hermes:hermes /opt/hermes/etc/config.yml sudo chmod 640 /opt/hermes/etc/config.yml7. 后期升级与维护时的操作顺序7.1 我的升级顺序和备份习惯Hermes 这类项目迭代速度不算慢升级属于迟早要面对的事。我给自己定了一套固定流程每次按部就班执行基本没出过岔子。先在服务器上备份当前版本和所有数据sudo systemctl stop hermes-agent hermes-web-ui sudo cp -a /opt/hermes/etc /backup/hermes-etc-$(date %F) sudo cp -a /var/lib/hermes /backup/hermes-data-$(date %F) sudo cp -a /var/lib/hermes-web /backup/hermes-web-data-$(date %F)如果数据目录里是 SQLite 数据库更稳妥的方式是用 SQLite 自身工具做在线备份避免直接拷贝正在服务的文件导致数据文件不一致sqlite3 /var/lib/hermes/hermes.db .backup /backup/hermes-hermes.db-$(date %F)然后下载新版 tar 包重复之前的 SHA256 校验流程。校验通过后只替换二进制文件配置文件和数据目录不要覆盖sudo cp /tmp/hermes-agent-linux-amd64-v0.11.3/hermes-agent /opt/hermes/bin/hermes-agent sudo cp /tmp/hermes-web-ui-linux-amd64-v0.11.3/hermes-web-ui /opt/hermes-web/bin/hermes-web-ui sudo chmod 755 /opt/hermes/bin/hermes-agent /opt/hermes-web/bin/hermes-web-ui sudo chown hermes:hermes /opt/hermes/bin/hermes-agent /opt/hermes-web/bin/hermes-web-ui再启动服务sudo systemctl start hermes-agent hermes-web-ui启动后立刻看端口和健康检查ss -lntp | grep -E 7800|8080 curl http://127.0.0.1:7800/healthz如果 healthz 没通过优先看 Agent 启动日志里的版本标记很多不兼容是在配置文件格式上升级后日志会明确提示某个字段失效。此时最忌讳的是把新版本又换回旧版强行上线而是应该按报错把配置更新到新格式。7.2 磁盘占用与日志轮转提醒Rocky Linux 默认用 journald 收集服务日志如果服务运行时间长、日志量大/var/log/journal 的体积会悄悄涨起来。给 systemd journal 设置一个上限比较重要sudo mkdir -p /etc/systemd/journald.conf.d# /etc/systemd/journald.conf.d/size.conf [Journal] SystemMaxUse500M RuntimeMaxUse200M改完重启 journaldsudo systemctl restart systemd-journald同时定期检查数据目录大小sudo du -sh /var/lib/hermes /var/lib/hermes-web会话表增长过快要考虑清理旧会话。大多数版本会按照session_ttl自动清理但也可能因为配置成0永不过期导致数据无限膨胀。我的建议是保留 30 天足够只要数据目录有每日备份无需把会话永久留存在生产库中。7.3 最后一次维护提醒把部署过程固化下来如果你一次性部署成功建议趁记忆还新鲜时把整个流程写成一个部署脚本或者至少用 Ansible 记录下关键步骤包括二进制下载地址、config.yml 的修改、两个 service 单元文件、Nginx 配置、SELinux 布尔值。这样下次新机器上再部署最多十分钟就能拉到同样状态不用重新翻文档。我在实际使用中最受益的一条经验是给所有服务目录都显式标注版本号/opt/hermes/bin/hermes-agent --version /opt/hermes-web/bin/hermes-web-ui --version每次升级后把版本号记录到一个VERSION文件里排查问题时能一眼看出当前环境是哪个版本避免在升完级之后拿着旧版本的 issue 去排查新版本问题。这个做法虽然简单但在多台服务器一起维护时省下来的时间非常可观。如果你手头正好有 Rocky Linux 服务器建议先从小规格配置开始试把 Agent、Web-UI、Nginx 三层跑通后再放开到生产流量。这套组合的安装并不复杂复杂的是运行过程中对会话持久化、WebSocket 转发和文件权限的理解只要这三块不出问题日常维护会非常省心。