CI/CD

概述 用 Jenkins 的人分两派：一派在网页上填表单配任务，点几下就跑起来了，简单粗暴；另一派在代码仓库里写 Jenkinsfile，把构建流程变成代码，版本控制、评审、回滚一条龙。 前者叫 Freestyle Project（自由风格项目），后者叫 Pipeline Project（流水线项目）。 这两种风格不是"谁取代谁"的关系。很多团队两个都在用——简单的脚本任务用 Freestyle，复杂的多阶段发布用 Pipeline。但如果你刚开始搞 CI/CD，或者在犹豫要不要从 Freestyle 迁到 Pipeline，这篇文章帮你把两种风格的配置流程、核心差异、选型策略一次性捋清楚。 我先说结论：能用 Pipeline 就用 Pipeline。但别急着全盘迁移，得看场景。下面从零开始配。 Jenkins 项目到底是个什么东西 Jenkins 本身是个任务执行引擎。你给它一组指令——去哪拉代码、怎么编译、往哪部署——它照着干。这组指令的载体就是 Jenkins 项目（Jenkins 内部叫 Job）。 打个比方，Jenkins 是厨师，项目就是菜谱。菜谱写了先切菜、再炒、最后装盘，厨师按步骤做。Freestyle 和 Pipeline 就是两种不同格式的菜谱——一个是填表式，一个是代码式。 Jenkins 原生支持好几种项目类型，实际干活最常用的就两种： 项目类型 怎么配 适合谁 Freestyle Project 在网页上填表单 刚接触 Jenkins 的团队，简单构建场景 Pipeline Project 写 Jenkinsfile 代码 需要多阶段编排、长期维护的团队 还有 Maven 项目（Java Maven 专用的 Freestyle 特化版）和多配置项目（同一任务跑多套参数），用得越来越少，这里不展开。 两种风格的本质区别 先看一个直观的例子。假设要配一个"拉代码 → 编译 → 部署"的任务。 Freestyle 版本：打开 Jenkins 网页，在源码管理填 Git 地址，构建步骤填 mvn clean package，构建后操作填部署脚本。保存，点构建，跑起来了。...

概述 漏洞扫描集成 CI/CD：从依赖检查到镜像安全是SRE运维工作中的重要技能。在实际生产环境中，掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要漏洞扫描集成 CI/CD 随着系统规模的扩大和复杂度的增加，传统的运维手段已经难以满足现代分布式系统的需求。漏洞扫描集成 CI/CD能够帮助运维团队： 快速定位问题：通过系统化的工具和方法，缩短故障排查时间 提升系统可见性：建立全面的监控和可观测性体系 预防故障发生：通过主动发现和修复潜在风险，降低故障率 优化资源利用：合理分配和调度资源，提升系统性能 核心概念与原理 基础概念 漏洞扫描集成 CI/CD的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面： 数据收集与处理：从各种数据源收集指标、日志和追踪信息 分析与可视化：通过仪表盘和告警系统展示系统状态 自动化响应：基于预设规则自动执行修复操作 持续优化：根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是漏洞扫描集成 CI/CD的基础。建议使用版本控制工具管理配置文件，确保变更可追溯： # 示例：配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具： 场景 推荐工具 说明 配置管理 Ansible 无代理，适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源，社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景：生产环境故障排查 假设线上服务出现响应延迟，排查步骤如下：...

概述 Pipeline as Code 是 Jenkins 从"拖拽式配置"走向"代码化"的分水岭。把流水线定义写在 Jenkinsfile 中，纳入 Git 版本控制，意味着每次流水线变更都有 diff 可审查、有历史可追溯、有分支可回滚。从 Jenkinsfile 语法到生产级流水线设计，详细梳理 Pipeline as Code 的核心实践。 参考来源：Jenkins Pipeline 官方文档 一、Jenkinsfile 语法 1.1 声明式 vs 脚本式 Jenkins Pipeline 有两种语法风格： 维度 声明式（Declarative） 脚本式（Scripted） 语法 结构化 DSL Groovy 代码 可读性 高，接近配置文件 低，需要 Groovy 知识 灵活性 受限于 DSL 约束 完全自由 输入验证 内置 post、when 等结构 需手动实现 推荐场景 标准流水线、团队协作 复杂逻辑、条件分支多 // === 声明式 Pipeline === pipeline { agent any stages { stage('Build') { steps { sh 'make build' } } } } // === 脚本式 Pipeline === node { stage('Build') { sh 'make build' } } 实践建议：优先用声明式，仅在声明式无法表达的复杂逻辑处用 script {} 块嵌入脚本式代码。...

GitOps 核心原则 GitOps 是一种现代化的持续交付方法论，由 Weaveworks 在 2017 年提出。它将 Git 作为基础设施和应用配置的唯一可信源（Single Source of Truth），通过声明式方式实现持续部署。 根据 ArgoCD 官方文档，GitOps 遵循四大核心原则： 1. 声明式系统 基础设施和应用配置以声明式描述（YAML/Helm/Kustomize）存储在 Git 中： # Git 仓库结构示例 infra-repo/ ├── apps/ │ ├── frontend/ │ │ ├── deployment.yaml │ │ ├── service.yaml │ │ └── configmap.yaml │ └── backend/ │ ├── deployment.yaml │ └── service.yaml ├── helm/ │ └── values-production.yaml └── kustomize/ ├── base/ └── overlays/ ├── staging/ └── production/ 声明式描述的核心价值：配置即文档，Git 历史即审计日志。任何环境变更都可追溯、可回滚。 2. 版本控制 所有变更通过 Git 提交记录，天然具备：...

CI/CD 是现代软件交付的命脉。手动构建、手动部署不仅效率低下，更是事故的温床——“在我机器上能跑"的悲剧几乎都源于缺乏自动化流水线。GitHub Actions 作为 GitHub 原生的 CI/CD 平台，与代码仓库无缝集成，免费额度对开源项目友好，已成为最流行的 CI/CD 工具之一。从核心概念出发，结合 Go 项目和 Hugo 站点两个实战场景，完整讲解流水线设计。 参考来源：GitHub Actions 官方文档 一、GitHub Actions 核心概念 GitHub Actions 的架构围绕五个概念展开，理解它们的关系是设计流水线的基础： Workflow（工作流） │ ├── Job A（任务） │ ├── Step 1 → Action: checkout 代码 │ ├── Step 2 → Action: setup Go 环境 │ └── Step 3 → Shell: go test ./... │ └── Job B（任务） ├── Step 1 → Action: 下载构建产物 └── Step 2 → Shell: 部署到服务器 概念 说明 类比 Workflow 一个 ....