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% 的可用性要求节点类型数量配置建议职责负载均衡1~22C4G流量分发、健康检查、可选 Keepalived 实现 VIP 漂移应用节点24C8G运行 JumpServer 核心服务数据库1 主 1 从4C16G存储核心业务数据并同步备份Redis1 或集群2C4G缓存、会话、Celery 队列共享存储1100G录像文件与配置文件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-port8080/tcp firewall-cmd --permanent --add-port8070/tcp firewall-cmd --reload如果使用源码方式构建镜像仓库里也提供了现成的构建脚本 utils/build_docker.sh可以一键完成镜像打包。四、数据层先行数据库与缓存高可用集群的数据层必须先上车。生产环境推荐使用 Docker 直接拉起 PostgreSQL 主库docker run -d --name postgres-master \ -e POSTGRES_USERjumpserver \ -e POSTGRES_PASSWORD你的强密码 \ -e POSTGRES_DBjumpserver \ -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/share2. 拉取代码并部署在每个应用节点上执行相同的操作。首先克隆仓库git clone https://gitcode.com/GitHub_Trending/ju/jumpserver cd jumpserver接着修改 config_example.yml 中的关键配置并重命名为config.ymlSECRET_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; echo3. 启动容器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_fails3 fail_timeout30s; server 192.168.1.11:8080 max_fails3 fail_timeout30s; } 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 nametest-ha第三步验证会话共享。通过负载均衡登录一次 JumpServer再刷新或从另一节点进入确认会话仍然有效——这依赖 Redis 中的 Session 数据也是前面强调 Redis 配置必须一致的原因。八、高频坑点与排错速查症状可能原因解决办法网页终端连接失败Nginx 未转发 WebSocket 头补齐Upgrade与Connection头配置节点间配置不一致各节点手动改了 config.yml统一通过共享存储维护配置或使用配置管理工具分发Celery 任务重复执行多节点同时调度定时任务确认 Redis 锁生效参考 apps/ops/celery/utils.py 中的beat-distribute-start-lock逻辑健康检查返回异常数据库或 Redis 连接超时直接访问/api/health/查看db_status/redis_status字段定位录像文件缺失节点间存储未共享确认所有节点挂载同一份 NFS 目录九、生产环境优化方向集群能跑起来只是及格线以下几个方向决定它能跑多久、跑多稳负载均衡自身高可用用 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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% 的可用性要求节点类型数量配置建议职责负载均衡1~22C4G流量分发、健康检查、可选 Keepalived 实现 VIP 漂移应用节点24C8G运行 JumpServer 核心服务数据库1 主 1 从4C16G存储核心业务数据并同步备份Redis1 或集群2C4G缓存、会话、Celery 队列共享存储1100G录像文件与配置文件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-port8080/tcp firewall-cmd --permanent --add-port8070/tcp firewall-cmd --reload如果使用源码方式构建镜像仓库里也提供了现成的构建脚本 utils/build_docker.sh可以一键完成镜像打包。四、数据层先行数据库与缓存高可用集群的数据层必须先上车。生产环境推荐使用 Docker 直接拉起 PostgreSQL 主库docker run -d --name postgres-master \ -e POSTGRES_USERjumpserver \ -e POSTGRES_PASSWORD你的强密码 \ -e POSTGRES_DBjumpserver \ -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/share2. 拉取代码并部署在每个应用节点上执行相同的操作。首先克隆仓库git clone https://gitcode.com/GitHub_Trending/ju/jumpserver cd jumpserver接着修改 config_example.yml 中的关键配置并重命名为config.ymlSECRET_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; echo3. 启动容器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_fails3 fail_timeout30s; server 192.168.1.11:8080 max_fails3 fail_timeout30s; } 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 nametest-ha第三步验证会话共享。通过负载均衡登录一次 JumpServer再刷新或从另一节点进入确认会话仍然有效——这依赖 Redis 中的 Session 数据也是前面强调 Redis 配置必须一致的原因。八、高频坑点与排错速查症状可能原因解决办法网页终端连接失败Nginx 未转发 WebSocket 头补齐Upgrade与Connection头配置节点间配置不一致各节点手动改了 config.yml统一通过共享存储维护配置或使用配置管理工具分发Celery 任务重复执行多节点同时调度定时任务确认 Redis 锁生效参考 apps/ops/celery/utils.py 中的beat-distribute-start-lock逻辑健康检查返回异常数据库或 Redis 连接超时直接访问/api/health/查看db_status/redis_status字段定位录像文件缺失节点间存储未共享确认所有节点挂载同一份 NFS 目录九、生产环境优化方向集群能跑起来只是及格线以下几个方向决定它能跑多久、跑多稳负载均衡自身高可用用 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考