/tags/jenkins/ Recent content in jenkins on Hugo -- gohugo.io en Fri, 06 Nov 2026 17:20:00 +0800 /posts/jenkins-vm-push-to-pull-deploy/ Fri, 06 Nov 2026 17:20:00 +0800 /posts/jenkins-vm-push-to-pull-deploy/ 背景 一条典型的 Jenkins 加 VM 部署链路是这样的：Jenkins 构建镜像、推到私有仓库，然后用凭据库里的一把 SSH key 登录目标 VM，把 docker-compose.yml、.env 和部署脚本拷过去，再执行 sudo docker compose up -d。每个环境有几台 VM，同一把 key 能登录这个环境的所有目标机，登录用户有免密 sudo。 这条链路好用的地方很实在：部署就是流水线的最后一个 stage，成败当场可见，回滚就是拿旧 tag 再跑一次。它的问题在信任的分布上。Jenkins 控制器同时握着源码、构建、凭据和通往每台 VM 的登录通道，能控制它的人就能以 root 身份登录所有目标机。 这篇讨论把最后一步反过来：VM 定时去拉「现在应该跑哪个镜像」，自己完成部署，Jenkins 不再登录 VM。讨论有三个前提：服务跑在 VM 上的 Docker Compose 里，短期内不迁 K8s；CI 继续用 Jenkins；目标是缩小 CI 被攻破时的影响面，构建本身是否可信只在讲验签时带到。 push 链路里，信任集中在 Jenkins 控制器 集中的地方有四处，前两处来自 Jenkins 本身，后两处来自部署脚本的常见写法。 登录凭据和解密它的 key 在同一台机器上 Jenkins 的凭据是加密存放的。按 Jenkins 开发者文档，加密用的 key 在 $JENKINS_HOME/secrets/，保护这些 key 的 master key 也在这个目录里，所以拿到控制器的文件系统，就能把凭据全部解出来。Controller Isolation 文档还提到，跑在 built-in node 上的构建对控制器文件系统的访问权限和 Jenkins 进程相同，官方建议把 built-in node 的执行器设为 0。如果构建还跑在控制器上，能改 Jenkinsfile 的人离凭据库只差一步。