JumpServer堡垒机高可用部署完整指南：三步搭建零中断的运维安全网关

JumpServer堡垒机高可用部署完整指南：三步搭建零中断的运维安全网关

【免费下载链接】jumpserverJumpServer is an open-source Privileged Access Management (PAM) platform that provides DevOps and IT teams with on-demand and secure access to SSH, RDP, Kubernetes, Database and RemoteApp endpoints through a web browser.项目地址: https://gitcode.com/GitHub_Trending/ju/jumpserver

每个稍有规模的运维团队，都经历过这样的至暗时刻：凌晨两点，线上服务器需要紧急处理，而唯一能连进去的堡垒机节点恰好宕机了。所有开发同事盯着终端，等你"重启一下"，你却连堡垒机本身都登不进去——因为这台唯一的堡垒机，既承担了登录入口，又是数据库访问的必经之路，单点故障让整个团队的运维通道瞬间瘫痪。

JumpServer 是一个开源特权访问管理（PAM）平台，也被称为开源堡垒机，它能通过网页浏览器统一接管 SSH、RDP、Kubernetes、数据库与 RemoteApp 等所有访问入口，让运维和研发人员按需获得安全、合规的访问权限。更关键的是，它支持多节点集群架构，可以从架构层面彻底消灭单点故障。本文将从单机运维的痛点出发，带你一步步完成 JumpServer 高可用部署，并给出故障切换、健康检查与日常排错的完整实操方案。

一、为什么单机堡垒机撑不起生产环境

很多人第一次部署 JumpServer 用的是"一台服务器全包"的模式：Web 服务、数据库、Redis、录像存储全挤在一台机器里。小规模试用没问题，一旦接入生产环境，三个致命问题就会暴露：

高可用集群要解决的，本质上是三个问题：无单点故障、故障自动转移、数据一致同步。JumpServer 的架构天然支持"负载均衡 + 多应用节点 + 共享存储"的横向扩展模式，这也是生产环境最主流的部署形态。

二、先看懂 JumpServer 高可用架构

在动手之前，先花两分钟理解整张架构图，后面每一步操作你都会知道"自己在搭哪一块"。

整个集群由四个层次组成，每一层都有明确职责：

• 接入层：Nginx 负责请求分发与被动健康检查，客户端永远只看到一个 VIP 或域名；
• 应用层：至少 2 个 JumpServer 节点并行运行，任一节点故障时流量自动切换到健康节点；
• 数据层：PostgreSQL 负责业务数据，Redis 承载 Celery 任务队列、WebSocket 与缓存会话；
• 存储层：共享存储（NFS/SMB）统一保存录像与配置文件，保证多节点看到的文件一致。

JumpServer 的代码组织也对应了这些层次，你可以直接翻阅源码加深理解：数据库连接与 Redis 配置集中在 apps/jumpserver/settings/base.py，健康检查接口实现在 apps/jumpserver/api/health.py，而 Celery 分布式任务的调度逻辑在 apps/ops/celery/utils.py。

三、环境规划：先算清楚要几台机器

1. 资源规划表

参考下面的配置做规划，建议至少保证 2 个应用节点与数据库主从，才能满足 99.9% 的可用性要求：

2. 系统基础配置

所有节点统一做三件事：安装 Docker、开放端口、同步时间。以 CentOS 系为例：

# 安装 Docker 及其依赖 yum install -y yum-utils device-mapper-persistent-data lvm2 yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y docker-ce docker-ce-cli containerd.io systemctl enable --now docker # 开放 JumpServer 相关端口（按实际安全策略调整） firewall-cmd --permanent --add-port=8080/tcp firewall-cmd --permanent --add-port=8070/tcp firewall-cmd --reload

如果使用源码方式构建镜像，仓库里也提供了现成的构建脚本 utils/build_docker.sh，可以一键完成镜像打包。

四、数据层先行：数据库与缓存

高可用集群的数据层必须"先上车"。生产环境推荐使用 Docker 直接拉起 PostgreSQL 主库：

docker run -d --name postgres-master \ -e POSTGRES_USER=jumpserver \ -e POSTGRES_PASSWORD='你的强密码' \ -e POSTGRES_DB=jumpserver \ -v /data/postgres:/var/lib/postgresql/data \ -p 5432:5432 \ postgres:13

从库的搭建属于标准的主从复制流程：先在从库恢复主库全量备份，再配置primary_conninfo指向主库即可。Redis 则直接使用单实例 + 持久化开启的模式，已能覆盖大多数团队规模：

docker run -d --name redis \ -v /data/redis:/data \ -p 6379:6379 \ redis:6 redis-server --appendonly yes

关于数据库和 Redis 的连接参数，JumpServer 的全部配置都收敛在仓库根目录的 config_example.yml 中，包括DB_ENGINE、DB_HOST、REDIS_HOST等关键项，多节点部署时必须保证这份配置在应用节点间完全一致。

五、应用节点部署：两台机器跑同一套服务

1. 准备共享存储

应用节点是无状态的，但它们要读写的录像文件必须全局一致。先在一台机器上部署 NFS：

# 服务端 yum install -y nfs-utils echo "/data/share 192.168.1.0/24(rw,sync,no_root_squash)" > /etc/exports systemctl enable --now nfs-server # 每个应用节点挂载 mkdir -p /data/jumpserver/share mount -t nfs 192.168.1.5:/data/share /data/jumpserver/share

2. 拉取代码并部署

在每个应用节点上执行相同的操作。首先克隆仓库：

git clone https://gitcode.com/GitHub_Trending/ju/jumpserver cd jumpserver

接着修改 config_example.yml 中的关键配置，并重命名为config.yml：

SECRET_KEY: 你的随机密钥字符串 BOOTSTRAP_TOKEN: 你的预共享Token # 数据库与 Redis 指向集群公共地址 DB_ENGINE: postgresql DB_HOST: 192.168.1.6 DB_PORT: 5432 DB_USER: jumpserver DB_PASSWORD: 你的强密码 DB_NAME: jumpserver REDIS_HOST: 192.168.1.7 REDIS_PORT: 6379

其中SECRET_KEY与BOOTSTRAP_TOKEN必须由你手动生成并保持一致，它们是多节点互相认证的基础：

cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 49; echo

3. 启动容器

docker run -d --name jumpserver \ -v /data/jumpserver/share:/opt/jumpserver/share \ -v /data/jumpserver/config:/opt/jumpserver/config \ -p 8080:8080 \ -p 8070:8070 \ jumpserver/jumpserver:v3.10.0

启动后用浏览器访问http://你的节点IP:8080，默认账号admin、密码ChangeMe，能登录即代表该节点工作正常。第二个节点重复上面全部步骤即可。

六、接入负载均衡：让流量自动找健康的节点

1. Nginx 配置示例

upstream jumpserver_cluster { server 192.168.1.10:8080 max_fails=3 fail_timeout=30s; server 192.168.1.11:8080 max_fails=3 fail_timeout=30s; } server { listen 80; server_name jumpserver.example.com; location / { proxy_pass http://jumpserver_cluster; 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 Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }

注意 WebSocket 协议头（Upgrade/Connection）必须保留，否则网页终端会连接失败。

2. 用好内置健康检查

JumpServer 原生提供了健康检查接口/api/health/，它会同时探测数据库与 Redis 的连通性并返回 JSON 状态，这是做负载均衡主动健康检查的最佳抓手。接口实现在 apps/jumpserver/api/health.py，会返回status、db_status、redis_status三个关键字段。

除此之外，还可以配合仓库里的 utils/check_celery.sh 脚本，通过检查 Celery Worker 的心跳文件时间戳来判断后台任务是否存活：

# 心跳文件超过 20 秒未更新则视为异常 test -e /tmp/worker_heartbeat_ansible && \ test $(($(date +%s) - $(stat -c %Y /tmp/worker_heartbeat_ansible))) -lt 20

七、故障演练：把节点拔了，服务还能不能跑

集群搭完，验证才是重头戏。建议按下面三步做一次完整的故障注入测试：

第一步，验证自动切换。在任一应用节点上执行：

docker stop jumpserver

随后持续观察 Nginx 访问日志，正常情况下请求会自动全部转向另一个健康节点，用户侧几乎无感知：

tail -f /var/log/nginx/access.log

第二步，验证数据一致性。在主库插入测试数据，再到从库确认同步是否正常：

# 主库写入 psql -h 192.168.1.6 -U jumpserver -c "INSERT INTO assets_asset(name) VALUES('test-ha')" # 从库查询 psql -h 192.168.1.6 -U jumpserver -c "SELECT * FROM assets_asset WHERE name='test-ha'"

第三步，验证会话共享。通过负载均衡登录一次 JumpServer，再刷新或从另一节点进入，确认会话仍然有效——这依赖 Redis 中的 Session 数据，也是前面强调 Redis 配置必须一致的原因。

八、高频坑点与排错速查

九、生产环境优化方向

集群能跑起来只是及格线，以下几个方向决定它能跑多久、跑多稳：

• 负载均衡自身高可用：用 Keepalived 给两台 Nginx 配置 VIP 漂移，避免负载层成为新的单点；
• 数据库定期备份：使用仓库提供的 utils/backup_db.sh 脚本或 PostgreSQL 的 pg_dump 做定时全量备份，并定期演练恢复流程；
• 资源监控与告警：重点盯应用节点 CPU/内存、数据库复制延迟、Redis 内存水位四类指标，建议设置磁盘使用率告警阈值（如 90%）；
• 升级策略：采用蓝绿发布，先升级一个节点验证无异常，再滚动升级其余节点，把每次升级的停机时间压到分钟级甚至零。

十、总结与下一步

回过头看，这套方案的全部要点可以浓缩为三句话：配置统一（用共享存储和同一份 config.yml 消除节点差异）、依赖集群化（数据库与 Redis 作为公共依赖独立部署）、接入层兜底（Nginx 健康检查自动剔除故障节点）。做到这三点，JumpServer 高可用部署就已经完成了 80%。

下一步建议你先在自己的测试环境里，用两台虚拟机按本文流程完整走一遍，重点练习"停节点 + 看日志 + 验数据"这套故障演练动作。等你在生产环境跑顺了，再考虑引入 Prometheus + Grafana 对集群做更细粒度的观测——那会是另一篇值得写的故事。现在，就从克隆仓库、搭起第一个节点开始吧。

【免费下载链接】jumpserverJumpServer is an open-source Privileged Access Management (PAM) platform that provides DevOps and IT teams with on-demand and secure access to SSH, RDP, Kubernetes, Database and RemoteApp endpoints through a web browser.项目地址: https://gitcode.com/GitHub_Trending/ju/jumpserver