Jenkins Agents — 完整 DevOps 讲座

发布: 2天前 (2026年2月7日 GMT+8 07:22)

8 分钟阅读

原文: Dev.to

Source: Dev.to

请提供您希望翻译的完整文本内容，我将按照要求将其译成简体中文并保留原有的格式、Markdown 语法以及技术术语。谢谢！

我们要解决什么问题？

在真实系统中，构建往往庞大、多样、且并行。单个 Jenkins 实例无法安全或高效地独自完成所有工作。

Agent（代理） 是 Jenkins 实现规模化、隔离化并在生产环境中可靠运行的方式。

1) 什么是 Jenkins Agent？

在 Jenkins 中，有两种角色：

Controller（控制器，原称 “master”）

UI、作业定义
调度与编排
凭证和配置

Agent（工作节点/从机）

执行实际工作：
- git clone
- npm install
- docker build
- terraform apply
- 测试、扫描、打包

关键规则： 控制器决定 运行什么；Agent 决定 在何处以及如何 运行。

2) 为什么 DevOps 需要 Jenkins Agents

原因 1 — 性能与扩展性

如果所有任务都在控制器上运行：

CPU 瞬间飙升
构建变慢
Jenkins 变得不稳定

使用 Agent 可以：

并行运行多个构建
通过增加工作节点来扩容，而不是升级单台大服务器

DevOps 原则： 横向扩展优于纵向扩展。

原因 2 — 隔离与安全

构建过程存在风险：

不可信代码
随机脚本
Docker daemon 访问
云凭证使用

Agent 的作用：

隔离故障
防止坏构建导致 Jenkins 崩溃
支持一次性（可销毁）环境

原因 3 — 多种环境

真实的流水线需要：

Linux Agent
Windows Agent
macOS Agent
ARM 与 x86
不同的工具链

Agent 让你可以： 根据作业需求选择合适的机器。

原因 4 — 安全与合规

最佳实践：

控制器 不装 Docker
控制器 不持有云管理员密钥
控制器 不直接构建制品

Agent：

只获取最小权限
可以轮换或销毁
遵循最小特权访问原则

3) 高层架构

流程：

开发者推送代码
Jenkins 控制器收到事件
控制器通过标签选择 Agent
Agent 执行流水线步骤
结果返回给控制器

4) Agent 的使用场景（真实 DevOps 场景）

场景 1 — 微服务 CI

每个服务独立构建
Agent 负责单元测试、Docker 镜像构建
多个 Agent = 更快的 CI

场景 2 — 基础设施即代码（Terraform）

Agent 安装 Terraform、AWS CLI 并具备 IAM 角色
控制器从不直接操作 AWS

场景 3 — Docker 与 Kubernetes

Docker 构建… (后续内容请继续翻译)

on Docker‑enabled agents

Kubernetes agents run inside the cluster → Kubernetes 代理在集群内部运行
Ephemeral pods for every pipeline run → 每次流水线运行使用临时 pod

Scenario 4 — Security Scanning

场景 4 — 安全扫描

Dedicated agents for:

SAST → SAST
Dependency scanning → 依赖扫描
Image scanning → 镜像扫描

Isolated from prod builds → 与生产构建隔离

Scenario 5 — Multi‑OS Testing

场景 5 — 多操作系统测试

Windows agent → .NET build → Windows 代理 → .NET 构建
Linux agent → backend services → Linux 代理 → 后端服务
macOS agent → iOS build → macOS 代理 → iOS 构建

5) Types of Jenkins Agents (DevOps View)

### 5) Jenkins 代理类型（DevOps 视角）

1️⃣ Static / Permanent Agents

#### 1️⃣ 静态/永久代理

Long‑running VMs → 长期运行的虚拟机
SSH or local connection → SSH 或本地连接

Good for: → 适用场景：

Legacy systems → 遗留系统
Stable workloads → 稳定工作负载

2️⃣ Docker Agents

#### 2️⃣ Docker 代理

Agent = container → 代理 = 容器
Created per build → 每次构建创建
Destroyed after job → 作业完成后销毁

Why DevOps loves this: → 为什么 DevOps 喜爱它：

Clean environment → 干净的环境
No dependency conflicts → 没有依赖冲突
Easy version control → 易于版本控制

3️⃣ Cloud VM Agents (EC2, GCE, Azure)

#### 3️⃣ 云 VM 代理（EC2、GCE、Azure）

Auto‑scale based on demand → 根据需求自动扩展
Shut down when idle → 空闲时关闭
Cost‑efficient → 成本高效

4️⃣ Kubernetes Agents (Modern Standard)

#### 4️⃣ Kubernetes 代理（现代标准）

Agent = Kubernetes pod → 代理 = Kubernetes pod
Dynamically provisioned per build → 每次构建动态供应
Leverages cluster scheduling & resource isolation → 利用集群调度和资源隔离

代理类型

Fully Ephemeral – 适用于微服务
Industry Standard for Large Orgs – 大型组织的行业标准

Ephemeral Agent GIF

Agent Types Diagram

Jenkins 如何选择代理

标签（最重要）

代理具有如下标签：

linux
docker
terraform
k8s
mac

流水线示例

pipeline {
  agent { label 'docker' }
  stages {
    stage('Build') {
      steps {
        sh 'docker build -t app .'
      }
    }
  }
}

翻译： “仅在能够进行 Docker 构建的代理上运行此作业。”

代理如何连接到 Jenkins

选项 A — WebSocket （推荐）

仅出站连接
无入站端口 → 防火墙友好
现代默认

使用场景： 企业网络、本地演示、位于 NAT 后的云代理。

选项 B — SSH

Jenkins 发起与代理的连接
常用于 EC2 实例

使用场景： 稳定的虚拟机、传统基础设施。

选项 C — Kubernetes 插件

Jenkins 请求一个 pod，该 pod 注册为代理
作业完成后 pod 被终止

使用场景： 云原生流水线、GitOps 环境。

代理生命周期（DevOps 思维）

类型	生命周期
静态虚拟机	始终运行
Docker 代理	每个作业
Kubernetes Pod	每个作业
云虚拟机	自动伸缩

趋势： 短暂 > 永久

DevOps 必须遵循的最佳实践

❌ 不要在控制器上运行构建
✅ 正确使用标签
✅ 优先使用短暂的代理 (Docker, Kubernetes)
✅ 将构建、测试和部署代理分离
✅ 使用后轮换或销毁代理
✅ 为每个代理授予最小权限
✅ 监控代理健康状态

常见错误（面试陷阱）

“所有内容都在 Jenkins 主节点上运行” ❌
“Agent 是可选的” ❌
“一个 Agent 就够了” ❌
“Controller 可以运行 Docker 构建” ❌

正确的思维方式： 没有 Agent 的 Jenkins 还不具备生产就绪性。

“Jenkins 代理是执行流水线步骤的工作节点。我们使用它们来扩展 CI/CD、隔离构建、支持多环境并提升安全性。在现代 DevOps 中，代理是 短暂的——通常基于 Docker 或 Kubernetes——并通过 Jenkinsfile 中的标签进行选择。”

Jenkins Agents — 完整 DevOps 讲座