跳到主要内容

夜莺安装部署

官方 Compose 部署适合测试完整功能链路。生产环境应使用独立 MySQL、Redis、时序数据库、TLS/SSO、Secret 和备份策略，不要复用发布包中的默认账号或临时数据卷。二进制与 Compose 示例应从 夜莺官方 Releases 和当前版本的官方安装文档取得，避免跨版本复制组件名称和配置键。

1. 环境准备​

规划 n9e、MySQL、Redis 与 TSDB 的网络连通性、DNS、持久卷、备份、监控和访问入口。控制台/API 仅经 HTTPS 反向代理或内网访问，数据库和 Redis 不暴露到公网。

2. Docker Compose 部署​

官方发布包/源码通常提供 docker/compose-bridge 示例：

# 进入官方 Compose 示例目录；该目录随发行包/源码版本变化
cd docker/compose-bridge
# 后台启动 n9e 及示例依赖，首次运行会拉取镜像并创建数据卷
docker compose up -d
# 查看每个服务状态，确认不是只看到 Web 容器运行
docker compose ps
# 跟随夜莺服务日志，排查数据库初始化或依赖连接问题
docker compose logs -f nightingale

默认账号仅用于初始化，首次登录后立即修改密码。测试结束前记录数据卷位置；生产不要把 Compose 默认 MySQL、Redis 和 VictoriaMetrics 当作高可用方案。

3. 二进制部署​

二进制部署前按 Release 中对应架构的资产下载程序，校验官方提供的校验和，再确认当前发行版的组件清单、etc/config.toml 配置样例、初始化数据库步骤和 systemd 启动顺序。将配置、反向代理、systemd 文件和不含密钥的规则纳入 Git；密码、Token 和证书通过 Secret 或密钥系统提供。

不同版本可能将 Web/API、告警引擎和中心协调拆分为不同二进制，systemd 单元的 ExecStart 必须引用该版本实际提供的程序和配置文件。部署前先执行该组件的 --help 或官方健康检查，再通过 systemctl status 与 journalctl -u <service> 验证启动结果。

4. Kubernetes 部署​

Kubernetes 使用受维护的 Helm chart 或团队编排清单部署，明确 Namespace、Service、Ingress、PVC、外部 MySQL/Redis、资源限制、Secret、NetworkPolicy 和反亲和。升级先在预发验证 UI、数据源、规则和通知。

5. 初始化配置​

初始化后完成管理员凭据轮换、SSO/LDAP、团队和权限、数据源、通知组、测试规则与恢复通知验证。页面能打开不代表规则和通知链路可用。