Appearance

运维工具 ​

DevOps 不是某一个工具，而是一套把“写代码、构建、测试、发布、运行、监控、排障”连接起来的方法。它解决的核心问题是：应用不能只在开发电脑上跑通，还要能稳定、可重复、可追踪地交付到测试环境和生产环境。

对零基础学习者来说，可以把 DevOps 理解为“软件从代码变成线上服务的全过程”。

为什么需要 DevOps ​

如果没有规范的交付流程，项目经常会遇到这些问题：

问题典型表现DevOps 解决方式
环境不一致本地能跑，服务器不能跑用 Docker 固化运行环境
发布靠人工手动复制 jar、改配置、重启服务用 Jenkins 或流水线自动发布
回滚困难发布出问题只能临时修保留镜像版本和发布记录
不知道哪里坏了用户反馈慢、日志分散建立日志、指标、告警
多实例难管理多台机器部署复杂用 Kubernetes 编排容器

整体交付流程 ​

mermaid
flowchart TD
    A["开发提交代码"] --> B["代码仓库 Git"]
    B --> C["CI 拉取代码"]
    C --> D["编译、测试、打包"]
    D --> E["构建 Docker 镜像"]
    E --> F["推送镜像仓库"]
    F --> G["部署到测试或生产环境"]
    G --> H["健康检查"]
    H --> I["日志、监控、告警"]
    I --> J{"是否发现问题"}
    J -- "是" --> K["定位、回滚或修复"]
    J -- "否" --> L["稳定运行"]

这张图要重点理解三件事：

  1. 代码不是直接放到服务器运行，而是先经过构建、测试和打包。
  2. 部署的对象通常不是源码，而是 jar 包、前端静态文件或 Docker 镜像。
  3. 发布之后还要持续观察，发现问题要能定位和回滚。

学习地图 ​

建议先读总链路，再进入具体工具：

  1. 从零到生产级掌握
  2. 从零到精通验收清单
  3. 商业场景训练营
  4. Docker 入门路线
  5. Nginx 总览
  6. Jenkins Pipeline
  7. Kubernetes 架构原理
  8. Kubernetes 面试题
  9. DevOps 面试题
模块先学什么学到什么程度算入门
Linux目录、进程、端口、权限、日志能进入服务器查看进程、端口和日志
Docker镜像、容器、端口、挂载、网络能把一个应用打成镜像并运行
Nginx反向代理、静态资源、负载均衡能把请求转发到后端服务
JenkinsJob、Pipeline、凭据、制品能自动拉代码、打包、部署
KubernetesPod、Deployment、Service、Ingress能理解应用在集群中如何运行
监控排障日志、指标、链路、告警能根据现象找到问题方向

一个最小发布案例 ​

假设你写了一个 Spring Boot 服务，最终要上线。完整流程可以拆成下面几步：

  1. 开发在本地写代码并提交到 Git。
  2. Jenkins 收到代码变更后自动执行 mvn test package。
  3. 构建 Docker 镜像，例如 user-service:1.0.0。
  4. 把镜像推送到镜像仓库。
  5. Kubernetes 使用这个镜像创建或更新 Pod。
  6. Service 把流量转发到健康的 Pod。
  7. Ingress 或 Nginx 暴露外部访问入口。
  8. 日志系统持续收集运行日志，监控系统观察 CPU、内存、请求耗时和错误率。

常见工具分工 ​

工具主要职责不该承担的职责
Docker打包运行环境、启动容器不负责复杂集群调度
Docker Compose本地或单机编排多个容器不适合大规模生产集群
Kubernetes管理大量容器、服务发现、滚动发布不替代应用代码质量
Nginx入口代理、静态资源、负载均衡不处理复杂业务逻辑
Jenkins自动化构建、测试、部署不保存业务配置和密钥明文
Prometheus采集指标不保存完整业务日志
ELK/Loki收集和查询日志不替代指标告警

初学者容易混淆的概念 ​

构建和部署不是一回事 ​

构建是把源码变成可运行产物，例如 jar、dist 静态文件或镜像。部署是把产物放到目标环境运行。构建失败通常是代码、依赖或测试问题；部署失败通常是环境、配置、权限、网络或资源问题。

镜像和容器不是一回事 ​

镜像是模板，容器是镜像运行后的实例。一个镜像可以启动多个容器。修改容器内文件不会自动改变镜像。

监控不等于日志 ​

监控回答“系统是否健康”，日志回答“具体发生了什么”。例如错误率升高属于监控指标，某个请求的异常堆栈属于日志。

推荐学习顺序 ​

mermaid
flowchart TD
    A["Linux 基础"] --> B["Docker 单容器运行"]
    B --> C["Dockerfile 构建镜像"]
    C --> D["Docker Compose 编排依赖"]
    D --> E["Nginx 反向代理"]
    E --> F["Jenkins 自动构建"]
    F --> G["Kubernetes 部署应用"]
    G --> H["日志、监控、告警"]
    H --> I["灰度发布和回滚"]

排障思路 ​

遇到“服务不可用”时，不要一上来就改配置。按下面顺序定位：

  1. 请求是否到达入口：检查域名、Nginx、Ingress。
  2. 入口是否转发到后端：检查 upstream、Service、端口。
  3. 后端实例是否健康：检查容器状态、Pod 状态、探针。
  4. 应用是否启动成功：查看启动日志和环境变量。
  5. 依赖是否可用：检查数据库、Redis、消息队列连接。
  6. 资源是否不足：检查 CPU、内存、磁盘、连接数。

学习检查清单 ​

  • 能说清楚从提交代码到用户访问之间发生了什么。
  • 能解释 Docker 镜像和容器的区别。
  • 能用 Nginx 把 /api 请求转发到后端服务。
  • 能写一个 Jenkins Pipeline 完成拉代码、构建和归档制品。
  • 能看懂 Kubernetes 中 Pod、Deployment、Service 的关系。
  • 能根据日志和指标判断问题大概出在哪一层。

练习 ​

  1. 画出你当前项目从开发到部署的流程图，标出每一步使用的工具。
  2. 用 Docker 启动一个 Redis，再用本地程序连接它。
  3. 写一个最小 Jenkinsfile，只包含拉代码、构建、归档三个阶段。
  4. 找一个线上故障复盘，按“入口、应用、依赖、资源”四层重新梳理原因。

小结 ​

DevOps 的重点不是背命令，而是建立交付链路意识。初学时先把“代码如何变成服务”理解清楚，再逐步学习 Docker、Nginx、Jenkins、Kubernetes 和监控排障。每个工具都只负责链路中的一部分，组合起来才形成稳定的软件交付体系。

Demo：最小交付脚本 ​

下面脚本演示从打包到构建镜像的最小流程，适合理解 DevOps 链路。

bash
#!/usr/bin/env bash
set -e

APP_NAME=blog-api
VERSION=1.0.0

mvn clean package -DskipTests=false
docker build -t ${APP_NAME}:${VERSION} .
docker run -d --name ${APP_NAME} -p 8080:8080 ${APP_NAME}:${VERSION}
curl http://127.0.0.1:8080/actuator/health

真实流水线会把这些步骤拆到 Jenkins、GitHub Actions 或 GitLab CI 中，并增加测试、镜像推送、部署、回滚和通知。