在当今这个软件交付速度决定竞争力的时代,我相信你一定感受到了 DevOps 实践带来的变革压力。作为一名开发者或运维工程师,我们不仅需要编写高质量的代码,更要确保这些代码能够快速、可靠地交付到用户手中。在这个过程中,持续集成和持续交付(CI/CD)流水线依然是我们的核心武器,但在 2026 年,其背后的逻辑已经发生了深刻的变化。
你可能已经熟悉了 Jenkins 的强大,也知道 Ansible 在自动化运维领域的统治地位。但你是否想过,在 AI 原生应用和边缘计算普及的今天,将这两者结合会发生什么?当我们把 Jenkins 的流程控制能力与 Ansible 的无代理部署特性结合,并融入现代安全理念时,我们就获得了一套能够自动化从基础设施到应用配置的全套解决方案。
在这篇文章中,我们将深入探讨如何在 Jenkins Pipeline 中有效地使用 Ansible。我们将超越简单的命令执行,深入探讨如何通过代码定义我们的交付流程,以及如何处理实际生产环境中可能遇到的复杂情况,特别是结合 2026 年的最新技术趋势。
目录
为什么选择 Ansible 与 Jenkins 的组合?
在开始实际操作之前,让我们先明确一下为什么这种组合在当下依然如此强大,甚至比以往更具生命力。
Ansible 以其简洁性和“无代理”架构著称。它使用 YAML 编写的 Playbook,读起来就像文档一样直观。它通过 SSH 协议与远程机器通信,这意味着你不需要在每一台目标服务器上费力地安装和维护客户端软件。在混合云和边缘计算场景日益复杂的今天,这种“轻客户端”的模式极大地降低了管理开销。
Jenkins 则是 CI/CD 领域的老兵,它拥有庞大的插件生态系统和强大的流程编排能力。通过 Jenkins Pipeline,我们可以将整个软件交付过程定义为代码,这意味着构建、测试和部署的步骤是可追溯、可版本控制的。
当我们将两者结合,Jenkins 就变成了“指挥官”,负责触发构建、管理流程阶段;而 Ansible 则是“执行者”,负责在 Jenkins 的指令下,精准地完成服务器配置和应用部署。这种组合允许我们利用 Jenkins 强大的生态系统(如与 Trivy 集成进行安全扫描)来驱动 Ansible 执行具体的变更。
核心概念回顾
在深入代码之前,让我们快速梳理一下几个核心术语,确保我们在同一个频道上。
Ansible Playbook 与 Collections
Playbook 是 Ansible 的灵魂。它是一个 YAML 文件,定义了一系列要在远程主机上执行的任务。它的最大特点是“幂等性”——这意味着无论你运行多少次 Playbook,只要目标状态没有改变,它就不会做多余的操作。在 2026 年,我们更多使用的是 Ansible Collections,这是一种打包和分发自动化内容的标准化格式,让我们可以轻松复用社区或企业内部的高级模块。
Jenkinsfile
Jenkinsfile 是 Jenkins Pipeline 的定义文件,通常使用 Groovy 语法编写。它允许我们将构建逻辑存储在项目的源代码仓库中(与应用代码一起),这就是所谓的“Pipeline as Code”。通过 Jenkinsfile,我们可以定义多个阶段,如构建、测试和部署。
实战准备:环境搭建
为了让我们能够在一个真实的环境中演练,我们将搭建两台基于 Linux 的服务器(你可以在本地使用 VirtualBox,或者在云端使用 EC2 实例)。为了模拟现代开发环境,建议使用最新的 LTS 版本操作系统。
- 节点 A (Jenkins Master):用于运行 Jenkins 服务,触发我们的构建任务。
- 节点 B (目标服务器):作为 Ansible 操作的目标,用于部署应用。
步骤 1:初始化服务器环境
首先,我们需要准备环境。让我们启动两台实例。为了确保流畅运行,建议选择配置至少为 2核 4GB 的机器。这将保证 Jenkins 和 Java 进程有足够的内存。
启动实例后,我们需要通过 SSH 连接到服务器。为了后续操作方便,建议配置好 SSH 密钥对,确保我们可以无密码登录到目标节点 B,这是 Ansible 高效工作的前提。
步骤 2:在 Jenkins 节点上安装所需软件
接下来,我们将专注于节点 A,安装 Jenkins 和 Ansible。
#### 安装 Jenkins
Jenkins 是基于 Java 的,因此我们需要先安装 Java 开发环境(建议使用 JDK 17 或 21,以保持最好的兼容性和性能)。
# 更新 yum 源并安装 Java 21
sudo yum update -y
sudo yum install java-21-openjdk-devel -y
安装完成后,验证 Java 版本:
java -version
接下来,添加 Jenkins 的官方仓库并安装。这里我们以 RPM 系统为例:
# 下载 Jenkins 仓库配置文件
sudo wget -O /etc/yum.repos.d/jenkins.repo \
https://pkg.jenkins.io/redhat-stable/jenkins.repo
# 导入 Jenkins 公钥
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key
# 安装 Jenkins
sudo yum install jenkins -y
#### 启动并访问 Jenkins
安装完成后,启动 Jenkins 服务并将其设置为开机自启:
# 启动 Jenkins
sudo systemctl start jenkins
# 设置开机自启
sudo systemctl enable jenkins
现在,我们需要获取初始管理员密码来解锁 Jenkins:
# 查看初始管理员密码
sudo cat /var/lib/jenkins/secrets/initialAdmin
复制输出的密码,然后在浏览器中访问 http://:8080。粘贴密码并按照提示完成初始化设置。
#### 安装 Ansible
在 Jenkins 节点上,我们也需要安装 Ansible。
# 使用 pip 安装最新版 Ansible(推荐方式,以便获取最新特性)
sudo yum install python3-pip -y
pip3 install ansible --user
# 将 ansible 加入 PATH (在 .bashrc 或 /etc/profile 中)
export PATH=$HOME/.local/bin:$PATH
集成实战:配置 Jenkins Pipeline
环境就绪后,让我们进入最激动人心的部分:编写 Pipeline 代码,让 Jenkins 去驱动 Ansible。
场景一:执行一个简单的系统检查
首先,我们创建一个简单的示例。假设我们要确保目标节点 B 上安装了 git,并检查系统时间。
#### 1. 准备 Ansible Playbook
在 Jenkins 工作空间或者一个 Git 仓库中,创建一个名为 check_system.yml 的文件:
---
# 这是一个简单的 Ansible Playbook 示例
- name: 检查目标服务器状态
hosts: all # 这里的 ‘all‘ 对应 Jenkins 传入的 inventory
become: yes # 提升权限执行(类似 sudo)
tasks:
- name: 确保 Git 已安装
yum:
name: git
state: present
- name: 获取当前系统时间
command: date
register: system_time
- name: 打印系统时间
debug:
msg: "当前系统时间是: {{ system_time.stdout }}"
#### 2. 编写 Jenkinsfile
在项目的根目录下创建 Jenkinsfile。我们将使用声明式 Pipeline 语法,因为它更易读且结构更清晰。
pipeline {
agent any // 让 Jenkins 在任何可用的代理节点上运行
environment {
// 定义 Ansible 的清单文件路径
ANSIBLE_INVENTORY = "ansible_inventory.ini"
}
stages {
stage(‘代码检出‘) {
steps {
echo ‘正在从 SCM 检出代码...‘
checkout scm
}
}
stage(‘Ansible 语法检查‘) {
steps {
echo ‘正在检查 Ansible Playbook 语法...‘
sh ‘ansible-playbook --syntax-check check_system.yml‘
}
}
stage(‘执行部署/配置‘) {
steps {
echo ‘正在运行 Ansible Playbook...‘
/*
* 核心步骤:使用 sh 步骤调用 ansible-playbook 命令。
* 在实际生产中,建议使用 Jenkins Credentials 绑定私钥。
*/
sh """
echo "[webservers]" > ${ANSIBLE_INVENTORY}
echo "node_B ansible_host= ansible_user=ec2-user ansible_ssh_private_key_file=/path/to/key.pem" >> ${ANSIBLE_INVENTORY}
ansible-playbook -i ${ANSIBLE_INVENTORY} check_system.yml
"""
}
}
}
post {
always {
echo ‘Pipeline 执行结束,清理工作空间...‘
}
success {
echo ‘恭喜!任务成功完成。‘
}
failure {
echo ‘糟糕!任务执行失败,请检查日志。‘
}
}
}
深入解析:Pipeline 是如何工作的?
在上述代码中,我们不仅仅是在运行命令,而是在构建一个严谨的流程。语法检查 阶段在团队协作中非常重要,它能防止因为缩进错误导致流水线崩溃。而 Inventory 管理 是关键,在 Jenkins 中,我们可以结合 withCredentials 绑定 SSH 密钥,避免将敏感信息硬编码在代码库中。
2026 视角:企业级安全与效率进阶
我们不仅要跑通流程,更要构建符合现代安全标准(DevSecOps)和高效协作的流水线。让我们思考一下这个场景:在大型企业中,SSH 密钥的轮换是一项痛苦的工作,且直接在 Playbook 中暴露路径是极大的安全隐患。
1. 安全左移:使用 Jenkins Credential 集成 SSH
我们可以利用 Jenkins 的 Credentials ID 来动态注入私钥,而不需要在文件系统中永久存储私钥文件。
优化后的 Jenkinsfile 片段:
stage(‘安全执行部署‘) {
steps {
withCredentials([sshUserPrivateKey(
credentialsId: ‘ansible-ssh-key‘,
keyFileVariable: ‘ANSIBLE_KEY_PATH‘,
usernameVariable: ‘ANSIBLE_USER‘
)]) {
sh """
# 动态生成 Inventory,使用变量填充
echo "[production]" > inventory_prod.ini
echo "node1 ansible_host=${TARGET_IP} ansible_user=${ANSIBLE_USER} ansible_ssh_private_key_file=${ANSIBLE_KEY_PATH}" >> inventory_prod.ini
# 执行 Playbook,开启幂等性验证
ansible-playbook -i inventory_prod.ini deploy.yml --check
"""
}
}
}
2. 决策避坑:何时不应使用 Ansible?
虽然 Ansible 很强大,但在我们的实际项目中,也会遇到它并不适合的场景。让我们思考一下这个场景: 如果你的应用是包含数百万个小文件的微服务容器镜像,或者是基于 Kubernetes 的动态编排环境,使用 Ansible 进行文件级别的传输可能会非常慢且难以回滚。
在这种情况下,我们建议转向 GitOps 工具(如 ArgoCD 或 Flux)。Ansible 更适合用于基础设施的预置和传统的虚拟机配置管理。对于 K8s 环境,Ansible 的 kubernetes.core 模块可以生成 Manifest,但直接应用通常不如 GitOps 控制器直接管理来得高效。
3. AI 辅助:LLM 驱动的 Playbook 生成
在 2026 年,我们编写 Playbook 的方式已经改变。我们经常使用 AI 辅助工具(如 GitHub Copilot 或 Cursor)来生成模板。
提示词技巧: 你可以输入这样的提示词:“Create an Ansible task to install Docker CE on Amazon Linux 2023, ensure the service is enabled, and handle idempotency errors.”
AI 不仅生成代码,还能解释每一个参数的作用。这大大缩短了我们编写模板的时间。但是,请注意:AI 生成的代码必须经过严格的安全审计,特别是 INLINECODE0b88f6b3 和 INLINECODEa4b9a99c 模块的使用。
性能优化与多环境并行策略
在处理大规模基础设施时,串行部署是不可接受的。Jenkins Pipeline 的并行特性结合 Ansible 的策略插件可以极大提升效率。
实战代码:并行部署多环境
stage(‘并行交付到多区域‘) {
steps {
script {
// 定义不同区域的 inventory 文件
def inventories = ["inventory_us_east.ini", "inventory_eu_west.ini"]
// 定义并行任务映射
def parallelTasks = [:]
inventories.each { inventory ->
parallelTasks["Deploy using ${inventory}"] = {
build job: ‘Ansible-Deploy-SubJob‘,
parameters: [string(name: ‘INVENTORY_FILE‘, value: inventory)]
}
}
// 并行执行
parallel parallelTasks
}
}
}
通过这种方式,我们可以同时向美国东部和欧洲西部的数据中心推送更新,且互不干扰。在我们的最近的一个项目中,这种策略将交付时间缩短了 60%。
总结
通过将 Ansible 集成到 Jenkins Pipeline 中,我们将“基础设施即代码”和“持续交付”的理念完美地融合在了一起。我们不仅简化了人工操作的繁琐,更重要的是,我们建立了一套标准化、可重复的软件交付流程。
在今天的文章中,我们从零开始搭建了环境,编写了实际的 Playbook 和 Jenkinsfile,并深入探讨了如何结合现代安全实践处理认证、如何利用并行策略提升性能,以及在 AI 时代如何更高效地编写自动化脚本。我希望这些实战经验能帮助你构建更健壮、更安全的 DevOps 流水线。
下一步,我建议你尝试在自己的项目中引入这套流程,哪怕只是从简单的日志备份开始。随着信心的增长,你可以逐步接管整个应用的生命周期,并最终探索向 GitOps 演进的可能性。让我们一起,用代码改变世界!