jenkins 通过 lockable resources plugin 实现独占部署资源控制，核心是将服务器、命名空间等抽象为带标签的可锁定实体，并在 pipeline 中用 lock 步骤声明需求，自动处理获取、等待与释放；需确保部署动作在 lock 块内执行并实际使用被锁资源，配合 timeout 或 input 防卡死。
在 Linux 环境下用 Jenkins 的 Lockable Resources Plugin 控制独占部署资源，并不依赖操作系统命令本身，而是靠插件在 Jenkins 层面对资源建模、分配与排队。核心是把“部署资源”抽象为可锁定实体（比如某台预发服务器、某个 Kubernetes 命名空间、一套数据库连接池），再通过 Pipeline 显式声明锁需求。
定义部署资源并打标签
进入 Jenkins 系统配置 → Lockable Resources Manager → Add Lockable Resource，创建一个代表独占部署能力的资源：
-
Name：例如
prod-deploy-slot-01（唯一标识） - Description：如 “生产环境灰度发布专用槽位，含 DB 切换权限和 Nginx reload 权限”
-
Labels：填
prod deploy exclusive（多个词空格分隔，便于后续按组匹配） - （可选）Reserved by：维护时填人名或 ticket 号，临时禁用该资源
如果你有多个同类部署槽位（如 slot-01 ~ slot-03），全部创建并统一打上 prod deploy 标签，后续就能用标签批量调度。
在 Pipeline 中声明资源锁定逻辑
不要用 shell 脚本手动调用 jenkins-lockable-resource acquire —— 这是过时用法，且易出错。现代推荐直接用 lock 步骤，Jenkins 自动处理获取、等待、释放全流程：
- 只锁一个确定资源：
lock('prod-deploy-slot-01') - 按标签自动分配（更灵活）：
lock(label: 'prod deploy', quantity: 1) - 需要并行部署到 3 个独立环境？
lock(label: 'prod deploy', quantity: 3)，插件会从所有带该标签的资源中挑出 3 个空闲的
锁的作用域默认覆盖整个 lock{...} 块。只要块内任务没结束（包括 input 等待人工确认），锁就一直持有。
结合部署动作确保真正独占
光加锁不够，得让部署脚本实际使用被锁定的资源。常见做法：
- 在
lock块内，用sh执行 SSH 部署到对应服务器（如ssh deploy@${RESOURCE_NAME} 'deploy.sh'），前提是资源名能映射到主机名；也可提前在资源描述里写明 IP 或别名 - 若部署目标是 Kubernetes，可在 lock 后动态设置命名空间变量：
env.DEPLOY_NS = 'prod-slot-a'，再用kubectl -n ${env.DEPLOY_NS}操作 - 避免在 lock 块外做任何影响目标环境的操作（如提前清理旧 pod、改 ConfigMap），否则仍可能引发冲突
监控与故障应对
访问 Jenkins 主页 → Lockable Resources 页面，实时看到：
- 每个资源当前是否被占用、被哪个构建（Job #ID）占用
- 哪些构建正在排队等待（Waiting for resource…）
- 点击资源名可强制释放（仅应急用，可能中断他人部署）
如果某次部署卡住（如 shell 脚本 hang 住），Jenkins 不会自动超时释放锁。建议在关键步骤加 timeout(time: 10, unit: 'MINUTES') 包裹，或用 input 加人工兜底确认。
