---
url: /sre/devops/foundation.md
description: DevOps 基础篇导读。沿着 Nginx、服务器、Git、Docker、流水线和 Docker Compose，建立一套从代码到生产的完整部署心智模型。
---

这不是一组互不相关的工具教程，而是一条完整的生产交付路径：**代码如何到达服务器，服务如何稳定运行，多个服务如何协作，部署动作如何被记录、复用和自动执行**。

很多人一想到 DevOps，就直接想到 Kubernetes。但对一人公司、个人项目和大多数中小型应用来说，真正需要解决的通常不是多集群调度，而是把重复、繁琐、容易出错的部署工作稳定地自动化。Kubernetes 本身也需要较高的学习、配置和运维投入，如果业务还没有达到集群化的规模，过早引入反而会增加负担。

因此，本篇先从更朴素、也更贴近多数项目的方案开始：**Docker Compose 负责单机多容器应用，GitHub Actions 负责托管式流水线**。Compose 把服务拓扑随源码提交管理；GitHub Actions 提供免费额度内的托管 Runner、声明式 YAML、丰富模板和完整的 GitHub 配套。对多数中小项目而言，这套组合已经是低成本、低复杂度且足够可靠的自动化运维起点。

本篇不追求把所有概念和术语一次讲完，也不把文章写成工具名词大全。每引入一个工具，都是因为前一步已经暴露了一个真实问题：手动部署容易漏步骤，就先用脚本固化；服务器环境难以复现，就用 Docker 封装；重复动作需要触发和记录，就引入流水线；服务数量增加，就用 Compose 管理整体拓扑。**先实践，再抽象；先解决眼前问题，再逐步升级**，是这套基础篇的阅读方法。

## 这套内容解决什么问题

从手动部署开始，问题会逐步暴露：

* 命令靠记忆，漏一步就可能发布失败；
* 服务器需要安装越来越多的运行时和构建工具；
* 版本、配置和部署步骤难以追溯；
* 服务从一个变成多个后，网络、卷和依赖关系变得复杂；
* 流水线如果承担所有细节，也会重新变成一份难以维护的脚本。

基础篇的目标，是把这些问题逐层拆开，再用合适的工具收敛：Git 管版本，Docker 管运行环境，流水线管交付触发，Compose 管单机多服务应用拓扑。

## 推荐阅读路径

| 篇目 | 解决的问题 | 关键产物 |
| --- | --- | --- |
| 01 | Nginx 如何承接静态资源 | Nginx 配置 |
| 02 | 一台生产服务器如何运行服务 | 公网服务器、SSH |
| 03 | 后端进程如何持续运行 | systemd、健康检查 |
| 04 | 源码和版本如何管理 | Git、GitHub |
| 05 | 如何隔离运行环境 | Docker Image、Container |
| 06 | 重复命令如何形成流水线 | Shell、Jenkinsfile、DAG |
| 07 | 如何使用托管式流水线 | GitHub Actions、Runner |
| 08 | 多个容器如何作为一个应用运行 | `compose.yaml` |
| 09 | 如何判断方案是否够用 | 能力地图与边界 |

建议按顺序阅读并至少完成一次最小部署。不要一开始就跳到 Kubernetes：先理解单机部署中的服务、版本、配置、拓扑和验证，再判断是否真的需要集群。

## 读完之后应该具备的能力

* 能把静态站点或后端服务部署到一台 Linux 服务器；
* 能用 Git 管理源码、配置和运维文件；
* 能用 Docker 固化运行环境，避免在服务器上散落安装依赖；
* 能区分镜像、容器、服务、流水线和 Runner 的职责；
* 能用 GitHub Actions 或 Jenkins 自动触发构建与部署；
* 能用 Compose 管理单机上的网关、应用、数据库和其他依赖；
* 能判断什么时候继续使用 Compose，什么时候进入 Kubernetes 等进阶方案。

## 先建立一个总心智模型

```text
源码与配置
    ↓ Git 管理
镜像与制品
    ↓ Docker 封装
生产变更
    ↓ Jenkins / GitHub Actions 触发
单机应用拓扑
    ↓ Docker Compose 收敛
服务运行与健康验证
```

对一人公司和大多数中小型公司来说，基础篇已经足以建立一套可落地的自动化运维方案：**源码可追溯，镜像可复用，变更可触发，拓扑可声明，结果可验证**。只有当业务规模和可靠性要求超出单机边界时，才需要继续引入更复杂的平台。