跳板机不是堡垒机堡垒机也不是一个只能用来跳来跳去的工具。我第一次接触JumpServer是团队里服务器权限乱成一锅粥的时候——root密码在五六个人手里传来传去生产环境今天有人改个配置明天有人跑个脚本出了故障谁也说不清楚是谁干的。后来下定决心上堡垒机对比了一圈开源方案最后还是用Docker把JumpServer拉了起来。到今天我已经在生产环境跑了一年多中间经历过版本升级、组件故障、录像盘被塞满也帮两个朋友从零搭过完整环境。这篇文章不聊虚的直接讲清楚三件事为什么用Docker部署JumpServer、完整落地一台堡垒机的实操过程、以及我踩过的那些坑和对应的排查方法。适合刚接触堡垒机的运维、安全同学也适合已经在用但想梳理清楚原理的人。1. 为什么选JumpServer先搞清楚堡垒机到底解决了什么问题1.1 没有堡垒机的运维现场有多混乱想象一下你们公司的服务器密码管理方式可能是一个Excel表格可能是某个聊天软件置顶消息更可能是每个人脑子里记一份。开发要上服务器看日志运维要改配置外包同事要部署代码所有人都拿着生产环境的账号直接连。这个模式最大的问题不是密码泄露而是“无法追溯”。线上出了故障你问了一圈谁改过配置大概率没人承认。就算查登录日志也只能看到一堆IP和用户名同一个账号多个人用的时候根本无法定位到具体的人。还有更麻烦的——高权限操作没有审批流程删库跑路的新闻大家听得够多了。堡垒机就是解决这个问题的中间层。它不再是让你直接连服务器而是让你先连堡垒机再通过堡垒机跳转到目标服务器。所有连接都会被记录、审计高权限操作可以加审批命令可以过滤全程录像回放。说得直白点堡垒机就是一个带监控和门禁的“运维中转站”。1.2 JumpServer这个开源项目为什么能打开源堡垒机里JumpServer是我目前见过综合能力最均衡的一个。它从资产纳管、账号管理、授权控制到会话审计、命令过滤、录像回放核心功能一应俱全而且支持Linux、Windows、数据库、Kubernetes这些常见资产类型。为什么选它而不是自己基于STS写一套因为堡垒机看起来简单做起来很繁琐。你不仅要处理SSH、RDP、VNC这些协议还要做录像、命令解析、文件传输审计更别提用户权限体系和工单流程。JumpServer把这些都封装好了而且Docker镜像发布很规律版本迭代快社区活跃遇到问题基本都能搜到答案。我实际用下来的感受是中小团队直接上社区版就够用不需要一开始就买商业堡垒机。等资产规模上去了、有合规审计要求了再考虑专业版也完全来得及。1.3 为什么用Docker部署而不是源码编译JumpServer的源码部署方式需要你准备Python、Node.js、Rust等一堆编译环境还要手工处理Celery、KoKo、Lion这些子组件之间的调用关系。我第一次尝试源码安装时光编译KoKo就花了大半天中间还遇到依赖包版本冲突实在痛苦。用Docker Compose部署则完全是另一回事。官方把整个堡垒机拆分成了Web、Core、KoKo、Lion、Celery等容器一个编排文件就能全部拉起来。组件之间通过容器网络通信依赖关系由编排文件管理升级的时候只需要拉新镜像然后重启容器。这对于生产环境维护来说省下的时间不是一点半点。还有一点很多人忽略堡垒机这种系统最怕的就是“装完不敢动”。源码部署的堡垒机升级一次可能要重新编译、改配置、折腾环境而Docker部署的升级路径非常清晰备份数据目录然后拉新镜像启动就够了。我后来能持续升级小版本靠的就是Docker这套部署方式。2. 部署前的软硬件与版本选型2.1 硬件配置要多少才够先说结论再讲原因。业务规模CPU内存磁盘建议测试环境 / 少于50台资产2核4G50G最低配置生产环境 / 100-300台资产4核8G100G推荐配置大型环境 / 500台以上资产8核16G独立大容量存储建议外置MySQL/Redis我最初在一台2核4G的旧服务器上跑纳管了30多台机器日常并发连接10个以内运行很流畅。后来加到一百多台资产、并发到了三四十个内存就会明显吃紧尤其是KoKo组件处理SSH连接时CPU占用会上去。磁盘是很多人容易忽略的点。堡垒机的录像文件会持续写入磁盘会话越多录像越多。一台Linux主机的Web终端录像一天就算只有两小时会话30天累积下来也要几个GB。所以建议数据盘和系统盘分开把录像目录放到独立挂载的大容量磁盘上后面我会讲到具体配置。2.2 版本选型社区版v3的正确打开方式JumpServer现在的主流版本是v3.x系列和老的v2.x相比前端界面、API体系、工单流程都有很大变化。新部署我强烈建议直接用v3最新稳定版不要装v2。有一个关键点很多人不知道v3版本首次登录需要上传License文件。社区版License是免费的在官网用邮箱就能申请但申请时要选择对应的版本号。我第一次就是没注意版本号申请了个旧版本的License上传时提示不匹配还得重新申请。后面我会在部署实操里详细说这个流程。2.3 环境准备Docker、时区和防火墙部署之前先把基础环境准备好。我这里以CentOS 7和Ubuntu 22.04为例其他发行版同理。安装Docker和Compose插件# CentOS 7 yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # Ubuntu 22.04 apt update apt install -y docker.io docker-compose-v2装完设置开机自启systemctl enable --now docker docker --version docker compose version然后设置时区堡垒机的录像时间和日志时间依赖这个timedatectl set-timezone Asia/Shanghai防火墙放行端口。JumpServer默认用到三个关键端口80Web访问、2222SSH协议入口用来给用户通过SSH客户端连堡垒机、25011内部组件通讯端口KoKo、Lion等组件注册用。firewall-cmd --permanent --add-port80/tcp --add-port2222/tcp --add-port25011/tcp firewall-cmd --reload注意25011这个端口我一开始没放行结果页面打开正常但点“连接”之后一直转圈最后排查了半天才发现是这个端口被防火墙挡住了。3. 部署实操从拉取编排文件到完成激活3.1 目录规划与编排文件下载部署服务器上我建议创建一个固定的数据目录这样将来升级、备份、迁移都方便。我习惯用/opt/jumpserver作为根目录在这个目录下存放编排文件和持久化数据。cd /opt mkdir -p jumpserver cd jumpserver然后从JumpServer官方GitHub Release页面下载当前稳定版本的docker-compose.yml。下载地址在Release页面里能找到用curl或wget都行。# 以某个v3.x版本为例实际使用时替换为你选择的版本号 curl -sSL https://github.com/jumpserver/Dockerfile/releases/download/v3.x.x/docker-compose.yml -o docker-compose.yml下载完成先不急着启动把镜像提前拉好避免启动时超时docker compose pull这个步骤会把镜像仓库里的Core、KoKo、Lion、Celery等镜像全部拉下来第一次大概有2-3G的流量根据网络情况需要几分钟到几十分钟不等。3.2 docker-compose.yml的关键配置解读拉下来的编排文件里有几个点值得认真看一下这决定了你后面会不会踩坑。端口映射部分默认是这样的ports: - 80:80 - 2222:2222 - 443:443 - 25011:25011如果你服务器上80端口已经被Nginx占了可以把宿主机端口改掉比如8080:80。但是要注意2222端口改掉之后你通过SSH客户端连接堡垒机时的端口就变了客户端那边也要做相应修改。另外改端口映射之后页面里的“连接配置”向导显示的地址也会变需要同步更新。环境变量部分最关键的是这三个变量作用注意事项SECRET_KEY数据加密密钥绝对不能泄露丢失后无法解密数据备份时要一起备份BOOTSTRAP_TOKEN组件间认证token各组件注册到Core时依赖它VOLUME_DIR数据持久化目录对应容器内挂载路径确保宿主机目录存在如果编排文件里没有显式定义这两个值第一次启动时会自动生成生成后会被写入.env文件。我的建议是部署完成后立刻把.env文件备份一份到安全的地方。数据持久化部分编排文件会把容器内的数据目录映射到宿主机configCore和组件的配置文件data数据库文件media会话录像、文件传输记录这三个目录将来就是你的备份重点。3.3 启动与初始化环境准备好、编排文件就位后启动其实只有一条命令docker compose up -d首次启动时会先运行一个init容器它负责初始化数据库表结构、写入初始数据。初始化需要二十秒左右不用担心。启动过程中可以随时查看状态docker compose ps正常情况下你会看到core、koko、lion、celery、web、redis、mysql这些容器都处于running状态。我见过的最常见问题是首次启动时看core容器一会儿启动一会儿退出这大概率是数据库还没初始化完init容器还在跑。等一分钟再docker compose ps看看不要慌着删容器。3.4 首次登录、改密和License激活打开浏览器访问http://你的服务器IP会看到JumpServer的登录页面。默认账号是admin默认密码是admin。首次登录后会强制要求修改密码这个没什么好说的直接改。改完密码会重新跳回登录页很多人到这里以为出问题了其实是正常的用新密码登录就行。登录进去之后页面会引导你上传License文件。社区版License去官网申请填写一个能收到邮件的邮箱地址和你的组织名称然后选择版本号。这里就是前面提醒过的坑——选择的版本号必须和你部署的版本一致比如你部署的是v3.10.x就选v3.10.x。提交申请后License文件会很快发到邮箱里。下载下来上传到页面激活成功后就能看到完整的管理界面了。注意License是绑定版本号的将来升级大版本比如v3.10升到v3.11之后需要重新申请对应版本的License。不过社区版申请免费流程也不复杂提前准备好就行。4. 把第一台Linux主机纳管起来资产-账号-授权-连接4.1 “资产”到底是个什么概念JumpServer里“资产”是一个统称既可以是一台Linux/Windows服务器也可以是一个MySQL实例还可以是一台网络设备。管理入口在左侧菜单“资产管理”里。点击“创建资产”最核心的字段就几个主机名给资产起个好识别的名字建议用业务名IP的格式比如“订单中心-db-01”IP地址堡垒机能够访问到的地址协议Linux选SSHWindows选RDP端口默认SSH是22RDP是3389创建完之后页面会显示资产的连通性状态在线/离线但要注意这个在线状态是跳转组件去探测的如果探测不通先检查网络和防火墙不一定是资产管理本身有问题。4.2 账号体系特权账号与系统用户资产创建好之后下一步是往资产里填账号。JumpServer的账号体系分为两层我花了一段时间才彻底理清。第一层叫“特权账号”也常称为管理账号。它保存的是你在目标服务器上的真实账号通常是root或带sudo权限的账号堡垒机用它来登录目标机器、收集信息。点击资产的“账号”标签页添加账号时填上真实的用户名和密码或者SSH Key。第二层叫“系统用户”是JumpServer内部定义的用户它决定了用户以什么身份登录资产。系统用户可以绑定资产上的真实账号。比如你创建一个系统用户叫“ops-admin”指定它使用某台资产的root账号登录然后给团队成员授权时选择这个系统用户大家登录资产时看到的就是同一个账号身份。说得更直白点特权账号是“堡垒机替你保管的钥匙”系统用户是“你发给员工的通行证”。钥匙只有堡垒机自己有员工只接触到系统用户。4.3 授权规则与Web终端实测账号准备好后在“权限管理”里创建授权规则把“用户”和“资产”关联起来。创建授权规则时选择要授权的用户或用户组再选择资产然后设定登录账号选择前面创建的系统用户。提交之后授权即时生效不需要重启任何组件。接下来验证一下整个链路。打开“会话管理”里的“Web终端”界面上会列出当前用户有权限访问的资产列表。点击任意一台Linux主机浏览器会打开一个终端窗口这就是KoKo组件在处理SSH连接。如果配置正确你会直接进入目标机器的命令行界面。我初次验证时最“顺滑”的感受是从入口选择资产到拿到shell整个过程几秒钟跟直接SSH连过去几乎没区别。而且右侧能看到会话时长、当前登录用户这些信息在传统直连方式下是完全没有的。4.4 SSH客户端接入2222端口的玩法不是所有场景都适合开Web页面。很多老运维习惯用终端工具JumpServer也支持标准的SSH协议接入这也是2222端口存在的意义。在你的电脑上执行ssh 用户名堡垒机IP -p 2222这里填的是JumpServer上的用户账号不是目标机器的账号。回车后会进入一个交互式列表显示你有权限访问的资产输入对应的序号就能建立连接。这个方式的好处是不用装任何客户端系统自带的ssh命令就行。对用户来说体验从“记一堆服务器密码”变成了“只记一个堡垒机账号”而且所有操作照旧会被审计。5. 避坑实录我部署和用了一年踩过的坑5.1 组件状态不健康/离线怎么排查用过一段时间后在“系统状态”页面看到某个组件状态变成红色是最常见的告警。我遇到最多的是koko组件离线。第一步看容器本身是否正常docker compose ps docker compose logs koko --tail 100常见原因一是网络不通二是组件注册token不匹配。如果是升级之后出现的离线多半是BOOTSTRAP_TOKEN变了导致组件无法注册到Core。这时候需要把旧的token恢复回去或者统一更新所有组件的token。还有个容易被忽略的点如果你的服务器有过重启容器因为某种原因没有自动恢复。检查一下Docker的开机自启策略是否配置正确。5.2 Web终端连不上目标机器但直连是通的这个现象很有迷惑性你在自己的电脑上直接SSH目标机器完全正常但通过堡垒机的Web终端连接时提示超时或者连接失败。一般排查顺序是这样的确认目标机器的22端口能连通堡垒机到目标机器的网络是否通确认资产创建时填的端口没错确认用的系统用户没有绑定错误的账号确认账号有没有过期、密码有没有改过我遇到过最隐蔽的一个问题是目标机器的防火墙限制了来源IP只放行了办公网段堡垒机不在放行范围内。排查时绕了很大一圈最后在目标机器上看了防火墙日志才定位到。5.3 转圈半天打不开会话端口被防火墙挡了前面提到过25011端口是组件通讯端口。如果你页面打开正常组件状态显示在线但点“连接”之后浏览器一直转圈大概率是这个端口没放行。这种“部分功能正常”的故障最容易被忽略因为80端口通了会让你觉得服务没问题。实际上Web页面和会话连接走的是不同链路页面访问走80而会话转发要经过25011。所以部署完成后建议一次性把80、2222、25011三个端口都放行。5.4 磁盘被录像和日志塞满堡垒机跑久了最容易被忽视的就是磁盘。我有一台服务器部署时给了80G磁盘前三个月一切正常第四个月开始频繁告警一看/opt/jumpserver/media目录已经吃掉了50多G。录像文件是持续增长的这个问题只能靠“转储”和“清理”两条腿走路。我在日志轮转上做了调整同时给录像目录配了定期任务超过90天的录像归档到独立存储再定期清理更老的视频文件。如果你有合规要求需要保存更长时间就把录像目录放到专门的大容量存储上。5.5 License过期了连登录都进不去有次我帮朋友检查一套部署很久的JumpServer发现登录页面一直提示License过期导致管理员都无法进入后台。这个问题的根源是当时部署的版本太旧License到期后没有及时更新。处理办法不复杂在登录页找到License上传入口通常有“本地上传”或“离线更新”按钮把新申请的License文件传上去就行。如果连上传入口都没法显示最后的手段是进入容器内部修改License文件但不建议在不知道具体路径的情况下乱试还是优先走官方流程。5.6 升级前不备份的代价JumpServer的Docker部署做得很方便以至于有人会忽视备份。我见过一次升级翻车从v3.x的一个旧版本直接跳到新版本数据库结构变化比较大升级后部分资产数据异常最后只能恢复旧数据从头再来。任何升级之前把config、data、media三个目录完整备份一遍再顺手备份一下.env文件。用Docker跑起来的服务备份起来其实非常单纯——打包目录就行。恢复时先停掉旧容器把备份目录解压回原路径再重新启动。6. 生产化落地从“能用”到“好用”的几个关键调整6.1 把内置MySQL和Redis换成外部的Docker Compose默认会拉起内置的MySQL和Redis容器测试环境完全没问题但生产环境建议尽早切换为外部独立部署的MySQL和Redis。原因是多方面的内置数据库跟着容器生命周期走一旦容器异常数据恢复的复杂度会上升外置数据库可以单独设置备份策略和性能参数也能配合监控体系做实时告警。切换到外置时在.env文件里指定外部数据库的地址、账号、端口和库名然后重启Core相关容器即可原来的数据可以先通过工具迁移过去。MySQL的版本建议用8.xRedis建议用6.x以上。数据库账号单独建一个不要用root直接连密码强度要求高一点。6.2 会话录像放到独立存储前面讲了录像文件会膨胀生产环境更建议把media目录直接映射到NFS、NAS这类独立存储上。具体做法是在宿主机挂载NFS目录然后把docker-compose.yml里media的volume映射源改成NFS挂载点。这样有两个好处一是录像文件的增长不再占用系统盘空间二是多节点部署时各个组件的录像可以集中存储审计查询更容易。我实际改过一次需要注意NFS挂载的超时参数和并发能力。如果堡垒机的并发会话比较多NFS性能跟不上会导致录像写入延迟进而影响会话体验。所以网络存储的设备选型和链路质量要关注。6.3 备份策略与恢复演练我在生产环境的备份策略供参考每晚对MySQL数据目录进行逻辑备份保留最近7天每晚对config目录和.env文件做增量备份每周对media目录做快照归档每月做一次完整的恢复演练——真的找一台临时机器把备份目录解压启动容器验证数据可用恢复演练这件事很多人觉得麻烦实际做一次就会发现“备份了但恢复不了”的风险真实存在。我有次做演练发现备份脚本漏了.env文件导致恢复到新机器上时组件注册token对不上折腾了两个小时才解决。从那之后备份清单里就死死盯着这几个文件。6.4 上线节奏先小范围试点再全量推广如果你想在生产环境平稳落地堡垒机我个人的建议是不要一上来就强制所有人切换。先在开发环境跑通Linux资产的纳管和授权让两三个运维同事先试用收集反馈。等大家习惯了“先进堡垒机再连服务器”的流程再把Windows资产、数据库资产逐步接入最后再考虑停掉原生的SSH直连端口。我见过一个团队为了推堡垒机一刀切关停了所有直连端口结果当天就有人因为不熟悉流程影响了线上排查进度。堡垒机是管控手段但不是给运维制造障碍的节奏要缓推广过程中不断优化授权规则和会话体验效果反而最好。最后再分享一个我个人的小经验堡垒机上线之后定期去翻一翻“会话记录”和“命令记录”。我之前通过命令记录发现有个同事在测试环境执行了rm -rf高危命令虽然没造成事故但提醒我及时加上了命令过滤规则后来正式环境里类似的风险操作就被有效拦截了。堡垒机这种东西装上之后才是开始持续优化规则和流程才能真正把价值发挥出来。 
长河君 · 2026/10/21 4:15:53 · 阅读 1.2k 基于Docker部署JumpServer堡垒机的实操避坑指南
跳板机不是堡垒机堡垒机也不是一个只能用来跳来跳去的工具。我第一次接触JumpServer是团队里服务器权限乱成一锅粥的时候——root密码在五六个人手里传来传去生产环境今天有人改个配置明天有人跑个脚本出了故障谁也说不清楚是谁干的。后来下定决心上堡垒机对比了一圈开源方案最后还是用Docker把JumpServer拉了起来。到今天我已经在生产环境跑了一年多中间经历过版本升级、组件故障、录像盘被塞满也帮两个朋友从零搭过完整环境。这篇文章不聊虚的直接讲清楚三件事为什么用Docker部署JumpServer、完整落地一台堡垒机的实操过程、以及我踩过的那些坑和对应的排查方法。适合刚接触堡垒机的运维、安全同学也适合已经在用但想梳理清楚原理的人。1. 为什么选JumpServer先搞清楚堡垒机到底解决了什么问题1.1 没有堡垒机的运维现场有多混乱想象一下你们公司的服务器密码管理方式可能是一个Excel表格可能是某个聊天软件置顶消息更可能是每个人脑子里记一份。开发要上服务器看日志运维要改配置外包同事要部署代码所有人都拿着生产环境的账号直接连。这个模式最大的问题不是密码泄露而是“无法追溯”。线上出了故障你问了一圈谁改过配置大概率没人承认。就算查登录日志也只能看到一堆IP和用户名同一个账号多个人用的时候根本无法定位到具体的人。还有更麻烦的——高权限操作没有审批流程删库跑路的新闻大家听得够多了。堡垒机就是解决这个问题的中间层。它不再是让你直接连服务器而是让你先连堡垒机再通过堡垒机跳转到目标服务器。所有连接都会被记录、审计高权限操作可以加审批命令可以过滤全程录像回放。说得直白点堡垒机就是一个带监控和门禁的“运维中转站”。1.2 JumpServer这个开源项目为什么能打开源堡垒机里JumpServer是我目前见过综合能力最均衡的一个。它从资产纳管、账号管理、授权控制到会话审计、命令过滤、录像回放核心功能一应俱全而且支持Linux、Windows、数据库、Kubernetes这些常见资产类型。为什么选它而不是自己基于STS写一套因为堡垒机看起来简单做起来很繁琐。你不仅要处理SSH、RDP、VNC这些协议还要做录像、命令解析、文件传输审计更别提用户权限体系和工单流程。JumpServer把这些都封装好了而且Docker镜像发布很规律版本迭代快社区活跃遇到问题基本都能搜到答案。我实际用下来的感受是中小团队直接上社区版就够用不需要一开始就买商业堡垒机。等资产规模上去了、有合规审计要求了再考虑专业版也完全来得及。1.3 为什么用Docker部署而不是源码编译JumpServer的源码部署方式需要你准备Python、Node.js、Rust等一堆编译环境还要手工处理Celery、KoKo、Lion这些子组件之间的调用关系。我第一次尝试源码安装时光编译KoKo就花了大半天中间还遇到依赖包版本冲突实在痛苦。用Docker Compose部署则完全是另一回事。官方把整个堡垒机拆分成了Web、Core、KoKo、Lion、Celery等容器一个编排文件就能全部拉起来。组件之间通过容器网络通信依赖关系由编排文件管理升级的时候只需要拉新镜像然后重启容器。这对于生产环境维护来说省下的时间不是一点半点。还有一点很多人忽略堡垒机这种系统最怕的就是“装完不敢动”。源码部署的堡垒机升级一次可能要重新编译、改配置、折腾环境而Docker部署的升级路径非常清晰备份数据目录然后拉新镜像启动就够了。我后来能持续升级小版本靠的就是Docker这套部署方式。2. 部署前的软硬件与版本选型2.1 硬件配置要多少才够先说结论再讲原因。业务规模CPU内存磁盘建议测试环境 / 少于50台资产2核4G50G最低配置生产环境 / 100-300台资产4核8G100G推荐配置大型环境 / 500台以上资产8核16G独立大容量存储建议外置MySQL/Redis我最初在一台2核4G的旧服务器上跑纳管了30多台机器日常并发连接10个以内运行很流畅。后来加到一百多台资产、并发到了三四十个内存就会明显吃紧尤其是KoKo组件处理SSH连接时CPU占用会上去。磁盘是很多人容易忽略的点。堡垒机的录像文件会持续写入磁盘会话越多录像越多。一台Linux主机的Web终端录像一天就算只有两小时会话30天累积下来也要几个GB。所以建议数据盘和系统盘分开把录像目录放到独立挂载的大容量磁盘上后面我会讲到具体配置。2.2 版本选型社区版v3的正确打开方式JumpServer现在的主流版本是v3.x系列和老的v2.x相比前端界面、API体系、工单流程都有很大变化。新部署我强烈建议直接用v3最新稳定版不要装v2。有一个关键点很多人不知道v3版本首次登录需要上传License文件。社区版License是免费的在官网用邮箱就能申请但申请时要选择对应的版本号。我第一次就是没注意版本号申请了个旧版本的License上传时提示不匹配还得重新申请。后面我会在部署实操里详细说这个流程。2.3 环境准备Docker、时区和防火墙部署之前先把基础环境准备好。我这里以CentOS 7和Ubuntu 22.04为例其他发行版同理。安装Docker和Compose插件# CentOS 7 yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # Ubuntu 22.04 apt update apt install -y docker.io docker-compose-v2装完设置开机自启systemctl enable --now docker docker --version docker compose version然后设置时区堡垒机的录像时间和日志时间依赖这个timedatectl set-timezone Asia/Shanghai防火墙放行端口。JumpServer默认用到三个关键端口80Web访问、2222SSH协议入口用来给用户通过SSH客户端连堡垒机、25011内部组件通讯端口KoKo、Lion等组件注册用。firewall-cmd --permanent --add-port80/tcp --add-port2222/tcp --add-port25011/tcp firewall-cmd --reload注意25011这个端口我一开始没放行结果页面打开正常但点“连接”之后一直转圈最后排查了半天才发现是这个端口被防火墙挡住了。3. 部署实操从拉取编排文件到完成激活3.1 目录规划与编排文件下载部署服务器上我建议创建一个固定的数据目录这样将来升级、备份、迁移都方便。我习惯用/opt/jumpserver作为根目录在这个目录下存放编排文件和持久化数据。cd /opt mkdir -p jumpserver cd jumpserver然后从JumpServer官方GitHub Release页面下载当前稳定版本的docker-compose.yml。下载地址在Release页面里能找到用curl或wget都行。# 以某个v3.x版本为例实际使用时替换为你选择的版本号 curl -sSL https://github.com/jumpserver/Dockerfile/releases/download/v3.x.x/docker-compose.yml -o docker-compose.yml下载完成先不急着启动把镜像提前拉好避免启动时超时docker compose pull这个步骤会把镜像仓库里的Core、KoKo、Lion、Celery等镜像全部拉下来第一次大概有2-3G的流量根据网络情况需要几分钟到几十分钟不等。3.2 docker-compose.yml的关键配置解读拉下来的编排文件里有几个点值得认真看一下这决定了你后面会不会踩坑。端口映射部分默认是这样的ports: - 80:80 - 2222:2222 - 443:443 - 25011:25011如果你服务器上80端口已经被Nginx占了可以把宿主机端口改掉比如8080:80。但是要注意2222端口改掉之后你通过SSH客户端连接堡垒机时的端口就变了客户端那边也要做相应修改。另外改端口映射之后页面里的“连接配置”向导显示的地址也会变需要同步更新。环境变量部分最关键的是这三个变量作用注意事项SECRET_KEY数据加密密钥绝对不能泄露丢失后无法解密数据备份时要一起备份BOOTSTRAP_TOKEN组件间认证token各组件注册到Core时依赖它VOLUME_DIR数据持久化目录对应容器内挂载路径确保宿主机目录存在如果编排文件里没有显式定义这两个值第一次启动时会自动生成生成后会被写入.env文件。我的建议是部署完成后立刻把.env文件备份一份到安全的地方。数据持久化部分编排文件会把容器内的数据目录映射到宿主机configCore和组件的配置文件data数据库文件media会话录像、文件传输记录这三个目录将来就是你的备份重点。3.3 启动与初始化环境准备好、编排文件就位后启动其实只有一条命令docker compose up -d首次启动时会先运行一个init容器它负责初始化数据库表结构、写入初始数据。初始化需要二十秒左右不用担心。启动过程中可以随时查看状态docker compose ps正常情况下你会看到core、koko、lion、celery、web、redis、mysql这些容器都处于running状态。我见过的最常见问题是首次启动时看core容器一会儿启动一会儿退出这大概率是数据库还没初始化完init容器还在跑。等一分钟再docker compose ps看看不要慌着删容器。3.4 首次登录、改密和License激活打开浏览器访问http://你的服务器IP会看到JumpServer的登录页面。默认账号是admin默认密码是admin。首次登录后会强制要求修改密码这个没什么好说的直接改。改完密码会重新跳回登录页很多人到这里以为出问题了其实是正常的用新密码登录就行。登录进去之后页面会引导你上传License文件。社区版License去官网申请填写一个能收到邮件的邮箱地址和你的组织名称然后选择版本号。这里就是前面提醒过的坑——选择的版本号必须和你部署的版本一致比如你部署的是v3.10.x就选v3.10.x。提交申请后License文件会很快发到邮箱里。下载下来上传到页面激活成功后就能看到完整的管理界面了。注意License是绑定版本号的将来升级大版本比如v3.10升到v3.11之后需要重新申请对应版本的License。不过社区版申请免费流程也不复杂提前准备好就行。4. 把第一台Linux主机纳管起来资产-账号-授权-连接4.1 “资产”到底是个什么概念JumpServer里“资产”是一个统称既可以是一台Linux/Windows服务器也可以是一个MySQL实例还可以是一台网络设备。管理入口在左侧菜单“资产管理”里。点击“创建资产”最核心的字段就几个主机名给资产起个好识别的名字建议用业务名IP的格式比如“订单中心-db-01”IP地址堡垒机能够访问到的地址协议Linux选SSHWindows选RDP端口默认SSH是22RDP是3389创建完之后页面会显示资产的连通性状态在线/离线但要注意这个在线状态是跳转组件去探测的如果探测不通先检查网络和防火墙不一定是资产管理本身有问题。4.2 账号体系特权账号与系统用户资产创建好之后下一步是往资产里填账号。JumpServer的账号体系分为两层我花了一段时间才彻底理清。第一层叫“特权账号”也常称为管理账号。它保存的是你在目标服务器上的真实账号通常是root或带sudo权限的账号堡垒机用它来登录目标机器、收集信息。点击资产的“账号”标签页添加账号时填上真实的用户名和密码或者SSH Key。第二层叫“系统用户”是JumpServer内部定义的用户它决定了用户以什么身份登录资产。系统用户可以绑定资产上的真实账号。比如你创建一个系统用户叫“ops-admin”指定它使用某台资产的root账号登录然后给团队成员授权时选择这个系统用户大家登录资产时看到的就是同一个账号身份。说得更直白点特权账号是“堡垒机替你保管的钥匙”系统用户是“你发给员工的通行证”。钥匙只有堡垒机自己有员工只接触到系统用户。4.3 授权规则与Web终端实测账号准备好后在“权限管理”里创建授权规则把“用户”和“资产”关联起来。创建授权规则时选择要授权的用户或用户组再选择资产然后设定登录账号选择前面创建的系统用户。提交之后授权即时生效不需要重启任何组件。接下来验证一下整个链路。打开“会话管理”里的“Web终端”界面上会列出当前用户有权限访问的资产列表。点击任意一台Linux主机浏览器会打开一个终端窗口这就是KoKo组件在处理SSH连接。如果配置正确你会直接进入目标机器的命令行界面。我初次验证时最“顺滑”的感受是从入口选择资产到拿到shell整个过程几秒钟跟直接SSH连过去几乎没区别。而且右侧能看到会话时长、当前登录用户这些信息在传统直连方式下是完全没有的。4.4 SSH客户端接入2222端口的玩法不是所有场景都适合开Web页面。很多老运维习惯用终端工具JumpServer也支持标准的SSH协议接入这也是2222端口存在的意义。在你的电脑上执行ssh 用户名堡垒机IP -p 2222这里填的是JumpServer上的用户账号不是目标机器的账号。回车后会进入一个交互式列表显示你有权限访问的资产输入对应的序号就能建立连接。这个方式的好处是不用装任何客户端系统自带的ssh命令就行。对用户来说体验从“记一堆服务器密码”变成了“只记一个堡垒机账号”而且所有操作照旧会被审计。5. 避坑实录我部署和用了一年踩过的坑5.1 组件状态不健康/离线怎么排查用过一段时间后在“系统状态”页面看到某个组件状态变成红色是最常见的告警。我遇到最多的是koko组件离线。第一步看容器本身是否正常docker compose ps docker compose logs koko --tail 100常见原因一是网络不通二是组件注册token不匹配。如果是升级之后出现的离线多半是BOOTSTRAP_TOKEN变了导致组件无法注册到Core。这时候需要把旧的token恢复回去或者统一更新所有组件的token。还有个容易被忽略的点如果你的服务器有过重启容器因为某种原因没有自动恢复。检查一下Docker的开机自启策略是否配置正确。5.2 Web终端连不上目标机器但直连是通的这个现象很有迷惑性你在自己的电脑上直接SSH目标机器完全正常但通过堡垒机的Web终端连接时提示超时或者连接失败。一般排查顺序是这样的确认目标机器的22端口能连通堡垒机到目标机器的网络是否通确认资产创建时填的端口没错确认用的系统用户没有绑定错误的账号确认账号有没有过期、密码有没有改过我遇到过最隐蔽的一个问题是目标机器的防火墙限制了来源IP只放行了办公网段堡垒机不在放行范围内。排查时绕了很大一圈最后在目标机器上看了防火墙日志才定位到。5.3 转圈半天打不开会话端口被防火墙挡了前面提到过25011端口是组件通讯端口。如果你页面打开正常组件状态显示在线但点“连接”之后浏览器一直转圈大概率是这个端口没放行。这种“部分功能正常”的故障最容易被忽略因为80端口通了会让你觉得服务没问题。实际上Web页面和会话连接走的是不同链路页面访问走80而会话转发要经过25011。所以部署完成后建议一次性把80、2222、25011三个端口都放行。5.4 磁盘被录像和日志塞满堡垒机跑久了最容易被忽视的就是磁盘。我有一台服务器部署时给了80G磁盘前三个月一切正常第四个月开始频繁告警一看/opt/jumpserver/media目录已经吃掉了50多G。录像文件是持续增长的这个问题只能靠“转储”和“清理”两条腿走路。我在日志轮转上做了调整同时给录像目录配了定期任务超过90天的录像归档到独立存储再定期清理更老的视频文件。如果你有合规要求需要保存更长时间就把录像目录放到专门的大容量存储上。5.5 License过期了连登录都进不去有次我帮朋友检查一套部署很久的JumpServer发现登录页面一直提示License过期导致管理员都无法进入后台。这个问题的根源是当时部署的版本太旧License到期后没有及时更新。处理办法不复杂在登录页找到License上传入口通常有“本地上传”或“离线更新”按钮把新申请的License文件传上去就行。如果连上传入口都没法显示最后的手段是进入容器内部修改License文件但不建议在不知道具体路径的情况下乱试还是优先走官方流程。5.6 升级前不备份的代价JumpServer的Docker部署做得很方便以至于有人会忽视备份。我见过一次升级翻车从v3.x的一个旧版本直接跳到新版本数据库结构变化比较大升级后部分资产数据异常最后只能恢复旧数据从头再来。任何升级之前把config、data、media三个目录完整备份一遍再顺手备份一下.env文件。用Docker跑起来的服务备份起来其实非常单纯——打包目录就行。恢复时先停掉旧容器把备份目录解压回原路径再重新启动。6. 生产化落地从“能用”到“好用”的几个关键调整6.1 把内置MySQL和Redis换成外部的Docker Compose默认会拉起内置的MySQL和Redis容器测试环境完全没问题但生产环境建议尽早切换为外部独立部署的MySQL和Redis。原因是多方面的内置数据库跟着容器生命周期走一旦容器异常数据恢复的复杂度会上升外置数据库可以单独设置备份策略和性能参数也能配合监控体系做实时告警。切换到外置时在.env文件里指定外部数据库的地址、账号、端口和库名然后重启Core相关容器即可原来的数据可以先通过工具迁移过去。MySQL的版本建议用8.xRedis建议用6.x以上。数据库账号单独建一个不要用root直接连密码强度要求高一点。6.2 会话录像放到独立存储前面讲了录像文件会膨胀生产环境更建议把media目录直接映射到NFS、NAS这类独立存储上。具体做法是在宿主机挂载NFS目录然后把docker-compose.yml里media的volume映射源改成NFS挂载点。这样有两个好处一是录像文件的增长不再占用系统盘空间二是多节点部署时各个组件的录像可以集中存储审计查询更容易。我实际改过一次需要注意NFS挂载的超时参数和并发能力。如果堡垒机的并发会话比较多NFS性能跟不上会导致录像写入延迟进而影响会话体验。所以网络存储的设备选型和链路质量要关注。6.3 备份策略与恢复演练我在生产环境的备份策略供参考每晚对MySQL数据目录进行逻辑备份保留最近7天每晚对config目录和.env文件做增量备份每周对media目录做快照归档每月做一次完整的恢复演练——真的找一台临时机器把备份目录解压启动容器验证数据可用恢复演练这件事很多人觉得麻烦实际做一次就会发现“备份了但恢复不了”的风险真实存在。我有次做演练发现备份脚本漏了.env文件导致恢复到新机器上时组件注册token对不上折腾了两个小时才解决。从那之后备份清单里就死死盯着这几个文件。6.4 上线节奏先小范围试点再全量推广如果你想在生产环境平稳落地堡垒机我个人的建议是不要一上来就强制所有人切换。先在开发环境跑通Linux资产的纳管和授权让两三个运维同事先试用收集反馈。等大家习惯了“先进堡垒机再连服务器”的流程再把Windows资产、数据库资产逐步接入最后再考虑停掉原生的SSH直连端口。我见过一个团队为了推堡垒机一刀切关停了所有直连端口结果当天就有人因为不熟悉流程影响了线上排查进度。堡垒机是管控手段但不是给运维制造障碍的节奏要缓推广过程中不断优化授权规则和会话体验效果反而最好。最后再分享一个我个人的小经验堡垒机上线之后定期去翻一翻“会话记录”和“命令记录”。我之前通过命令记录发现有个同事在测试环境执行了rm -rf高危命令虽然没造成事故但提醒我及时加上了命令过滤规则后来正式环境里类似的风险操作就被有效拦截了。堡垒机这种东西装上之后才是开始持续优化规则和流程才能真正把价值发挥出来。