5.2 常用工具巡礼

5.2 常用工具巡礼

本节摘要：沿七段地图逐段认识主流工具——代码托管、CI 引擎、制品仓库、容器与编排、配置管理、监控告警、协作响应。重点不在功能罗列，而在每个工具代表的设计思想以及它在发布之旅中扮演的角色：理解了思想，工具的更替（它们一定会更替）就不再让你重新学习一遍。

读完这节你能回答

1. 说出各环节主流工具的名字、定位与设计思想
2. 解释声明式配置、控制循环、不可变分发这三个思想的普适性
3. 为一段具体需求匹配 2~3 个候选工具并说明差异

一、代码与评审段

Git 已是版本控制的事实标准（2.1 节讲过它的快照模型）。围绕 Git 的托管平台形成了两个主要生态：GitLab 提供从仓库到 CI 到部署的一体化套件，自托管成熟，适合对数据驻留有要求的组织；GitHub 以评审体验与开源生态见长，配套的 Actions 让 CI 直接内建于仓库。选择往往不是技术问题，而是"一体化便利"与"生态广度"的偏好（5.3 节展开）。

Gerrit 代表另一种评审流：每次提交即一个评审单元，适合"小提交、严评审"的工程文化，在内核级、电信级项目里常见。工具形态反映协作哲学——用合并请求流的团队天然倾向特性分支，用 Gerrit 流的团队天然倾向小步提交。

二、持续集成段

Jenkins 是这一段的活化石与常青树。它的核心是"执行器 + 插件生态"：流水线即代码（Jenkinsfile）让构建定义进入版本库受评审；两千多个插件让它几乎能对接一切——但插件互相冲突、升级艰难也是它的著名痛点。它适合异构环境（各种语言、各种构建方式的混合体）与需要极度定制的老牌组织。

GitLab CI 与 GitHub Actions 是内建于托管平台的流水线：配置文件放在仓库里，触发、执行、展示一体化，省去维护 CI 服务器本身。"CI 不再是一个需要专人维护的系统，而是仓库的一个属性"——这是它们代表的思想。

Drone、Tekton 等轻量或云原生引擎走容器化执行路线：每个步骤都是一个容器，环境完全隔离与可复现。它们代表"流水线的执行环境本身也要不可变"的思想，是 Kubernetes 原生团队的常见选择。

三、制品管理段

制品仓库（Harbor、Nexus、Artifactory 等）表面上是"存包的地方"，实际上承担四个关键职责：版本化存储（第 2 章的制品永续）、访问控制（谁能拉生产镜像）、漏洞扫描（4.2 节构建站关卡）、签名与验签（供应链防线）。容器镜像、语言包、系统包统一进仓库管理——凡是部署到任何环境的产物，必须先经过仓库，这条纪律比选哪个仓库重要得多。

四、环境与部署段

Docker 的历史性贡献是把"不可变分发"做成了工业标准：应用连同它的全部依赖打成镜像，镜像在任何能运行容器的机器上行为一致——第 3 章讲的"在我环境上是好的"幻觉，在这里得到了最彻底的解药。

Kubernetes 是容器编排的事实标准，它的核心机制值得每个 DevOps 工程师理解——声明式 API + 控制循环。你声明"我要 8 个订单服务实例、每个限 1G 内存"，控制循环持续对比实际与声明，少了补、多了删、挂了重启。这个机制与 IaC 的声明式思想同源，把"维持系统处于期望状态"从人工操作变成了系统内建的本能。

# Kubernetes 声明示例：说出期望，控制循环负责达成
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 8                    # 期望实例数
  strategy:
    rollingUpdate: {maxSurge: 2, maxUnavailable: 0}  # 滚动策略
  template:
    spec:
      containers:
        - name: order
          image: registry.internal/app:3f2a91c   # 不可变镜像引用
          resources:
            limits: {memory: "1Gi", cpu: "500m"}
          readinessProbe:        # 未就绪不接流量（金丝雀的基础）
            httpGet: {path: /healthz, port: 8080}
​

Ansible 代表配置管理的"无代理"路线：不需要在被管机器上装客户端，通过 SSH 推送声明式剧本（playbook）。适合传统主机群与网络设备的配置管理。Terraform 则是 IaC 段的通用引擎：跨云供应商声明基础设施（3.2 节的示例即此类语法），计划预览与状态管理是它的招牌能力。

五、运行与观测段

Prometheus 是指标监控的事实标准，两个设计决定了它的地位：拉取模型（监控server 主动到服务端点拉指标，服务自描述）与多维数据模型（每个指标带任意标签，按标签任意切片聚合——4.1 节告警规则里的 path、status 就是标签）。配套的 Grafana 做可视化，Alertmanager 做告警路由分组——三个名字几乎等于"开源监控三件套"。

ELK/Loki 系解决日志的采集、索引与检索；Jaeger/Tempo 系解决链路追踪的收集与展示。三者配合的关键是 4.1 节讲过的 trace_id 打通——现代观测套件正走向"一个后端存三种数据"，但排查路径（指标→追踪→日志）不变。

六、协作与响应段

Jira 一类的项目工具有人爱有人恨，但"需求切片成任务、任务在看板上流动"的能力是必需品；轻量替代（如平台内建看板）在小团队完全够用。PagerDuty/Opsgenie 一类值班调度工具把告警路由到正确的人：轮换表、升级超时、静默窗口——4.3 节值班制度的技术载体。Statuspage 一类状态页工具让对外沟通模板化、有节奏。

七、几句务实的提醒

第一，名单会过时，思想不会。今天列出的具体名字，五年后必然有几分之一被替换；但声明式、控制循环、不可变分发这三个思想会延续到下一代工具里。学思想，用工具。

第二，警惕"全都要"。每引入一个工具都有长期成本（升级、权限、培训、集成），七段地图的意义之一是帮你发现"哪段其实用不上专门工具"——十人团队用托管平台内建的看板与 CI，完全可以跑得很好。

第三，同一功能段的工具，差异往往在"运营特征"而非功能清单：并发规模、权限模型精细度、审计能力、升级方式。5.3 节的选型方法会把这些变成可打分的维度。

本节要点回顾

• 评审段：Git 托管平台两大生态；Gerrit 的提交级评审代表另一种协作哲学
• CI 段：Jenkins 插件生态异构之王；平台内建 CI 让"流水线成为仓库的属性"；容器化执行隔离可复现
• 制品段：仓库不只是存储，是版本纪律、访问控制、扫描验签的关口
• 部署段：Docker 贡献不可变分发；Kubernetes 的声明式 API 加控制循环是普适心智模型
• 观测段：Prometheus 拉取模型与多维标签；三支柱靠 trace_id 打通
• 三个会迁移的思想：声明式配置、控制循环、不可变分发